I2C woes... only sending command byte? (what am I missing)

Per the topic, I’m trying to send a 4-byte I2C command in master mode to a TI DAC43608. For reasons unbeknownst, the code appears to be writing the first byte only.

The loop() section iterates at 1Hz and things seem to indicate the write() calls are buffering data. Oddly as well, the endTransmission() call returns a code 3 (end of address transmission timeout).

And for other background, v0.6.3 Dev OS on a Photon, and I have called Wire.begin() in setup(). The variable output_ADC is uint_8 type that’s incremented by 1 for each loop() iteration.

I know I’m overlooking something but stumped as to what it might be? I’ve got production SPI interfaces run at scale, but this is my first stab @ I2C.

Thanks in advance for any advice.

Here’s the master broadcast code snippet:

// DAC address (A0 = AGND) Table 3

// COMMAND Byte (DACA_DATA) Table 4
Serial.printlnf("Command = %d", Wire.write(0x08));

// HI ADC data nibble in low nibble (left aligned MSB)
Serial.printlnf("Hi Data = %d", Wire.write((uint8_t)(output_ADC & 0xF0) >> 4));    

// LO ADC data nibble in high nibble (left aligned MSB)
Serial.printlnf("Lo Data = %d", Wire.write((uint8_t)(output_ADC & 0x0F) << 4));    

Serial.printlnf("End TX  = %d", Wire.endTransmission(TRUE));

Here’s a snip from the serial debug stream output

Command = 1
Hi Data = 1
Lo Data = 1
End TX = 3
ADC output level = 84 / MSDB = 5 / LSDB = 40

Lastly, here’s the SDA/SCL line capture:

1 Like

Hey @jimini

According to the documentation, an error code of 3 indicates an end of address timeout, which I think means that the I2C slave is not replying with ACK when it is addressed by the host. This might be because you’ve got the wrong address, or perhaps you don’t have pull-up resistors on SDA and SCL.

I think this description from SparkFun is useful…

Address Frame

The address frame is always first in any new communication sequence. For a 7-bit address, the address is clocked out most significant bit (MSB) first, followed by a R/W bit indicating whether this is a read (1) or write (0) operation.

The 9th bit of the frame is the NACK/ACK bit. This is the case for all frames (data or address). Once the first 8 bits of the frame are sent, the receiving device is given control over SDA. If the receiving device does not pull the SDA line low before the 9th clock pulse, it can be inferred that the receiving device either did not receive the data or did not know how to parse the message. In that case, the exchange halts, and it’s up to the master of the system to decide how to proceed.


Also, from the datasheet it doesn’t look like 0x50 is a valid address. Apparently whatever you have A0 tied to will set the slave address.

Also, v0.6.3 is a pretty old release. I’d recommend upgrading to a newer version of deviceOS.

I see that you mentioned DAC address (A0 = AGND) Table 3. I think you should use 0x48, not 0x50.


Aha @nrobinson2000! Good catch on the device address (a6:a0) and not (a7:a1).

I also had it in my head the I2C master would broadcast unconditionally, however, it appears that the lack of an ack from the device is preempting the balance of the remaining message.

I appreciate the sanity check, thank you.

1 Like