3

Using the simplest code possible to test the library:

#include <Wire.h>

void setup()
{

  Wire.begin(); // join i2c bus

  Wire.beginTransmission(44); // transmit to device #44 (0x2c)
                              // device address is specified in datasheet

  Wire.write(0xA);             // sends value byte  
  Wire.write(0xA);             // sends value byte  
  Wire.write(0xA);             // sends value byte  

  Wire.endTransmission();     // stop transmitting  
}

But my data (three test byte of 0xA) is not getting sent. See image. As you can see, I get start bit, address, and then the stop bit. No data. Where am I going wrong?

Scope Trace

Improve this question
3
  • 1
    Are you sure you've got ACK? The beginTransmission expects unshifted device address (it might need address 22 instead of 44). (It's the address without R/W bit)
    – KIIV
    Feb 27, 2017 at 21:00
  • I'm trying it without a device attached to check the data first. Does the ACK need to be present in order to send the remaining data? That is a NACK on the 9th bit.
    – witch359
    Feb 27, 2017 at 21:05
  • 2
    Without an ACK from a device at that address the transfer will abort. It's not like SPI - it's a SEND-ACK-SEND-ACK-SEND-ACK protocol.
    – Majenko
    Feb 27, 2017 at 21:17

3 Answers 3

Reset to default
2

According to the captured communication NACK was received (confirmed in comments) and according to the Wire library twi_stop will be called (and sent) in this fault scenario.

case TW_MT_SLA_NACK:  // address sent, nack received
  twi_error = TW_MT_SLA_NACK;
  twi_stop();
  break;
Improve this answer
2
  • You can also test the return code from Wire.endTransmission(). arduino.cc/en/Reference/WireEndTransmission
    – 6v6gt
    Feb 27, 2017 at 22:11
  • This is good information. I'll try putting the device on the bus and see if that makes a difference. Thank you!
    – witch359
    Feb 28, 2017 at 13:22
2

It looks like you have code for an I2C master. Sending to a slave involves sending the slave address, and waiting for an ACK from the slave (that is, the addressed slave pulls the data bus low).

You can see that in a graphic from my page about I2C:

I2C protocol

At the 100 µs mark you can see that the slave pulls SDA low, which is an ACK. Thus the master knows that the addressed slave exists. Without that, the slave is not there, and there is no point in sending any further data.

Improve this answer
2

OK, I figured out what was going on...

An example program that I downloaded to test the hardware was sending a "self address" command to the chip, which was causing the address to get set to 0x03 and I didn't notice this. This new address stays in memory. So, when I went back to test the library code, I was sending 0x00 (default from factory) instead of the new address (0x03). The NACK after the address byte should have been a clue, but hey, live and learn.

Thanks for all the responses. Hopefully my pain will help someone else.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.