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
Wire.beginTransmission(0x50);
// 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
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.
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.