user31382: 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?


user23841: 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;


user10794: 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:

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.

user31382: 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.

31382: <p>Using the simplest code possible to test the library:</p>

<pre><code>#include &lt;Wire.h&gt;

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  
}
</code></pre>

<p>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?</p>

<p><a href="https://i.stack.imgur.com/dkCUC.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/dkCUC.jpg" alt="Scope Trace"></a></p>
 23841: <p>According to the captured communication <code>NACK</code> was received (confirmed in comments) and according to the <code>Wire</code> library <code>twi_stop</code> will be called (and sent) in this fault scenario.</p>

<pre class="lang-cpp prettyprint-override"><code>case TW_MT_SLA_NACK:  // address sent, nack received
  twi_error = TW_MT_SLA_NACK;
  twi_stop();
  break;
</code></pre>
 10794: <p>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).</p>

<p>You can see that in a graphic from <a href="http://www.gammon.com.au/i2c" rel="nofollow noreferrer">my page about I2C</a>:</p>

<p><a href="https://i.stack.imgur.com/1nG2b.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/1nG2b.png" alt="I2C protocol"></a></p>

<p>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.</p>
 31382: <p>OK, I figured out what was going on...</p>

<p>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.</p>

<p>Thanks for all the responses. Hopefully my pain will help someone else.</p>
