I am writing I2C master and slave code for an MSP430F2418. The slave won't acknowledge its address, and seems to be holding both SDA and SCL lines low. I'm using the USCI in I2C mode on B0 channel. The master code seems to start a bus cycle correctly, but the slave appears to be stalling the cycle.
I've verified the following issues that could potentially be causing this:
For development testing, I'm using the same MSP430F2418 for both the master and slave, on two identical experimenter boards. Previous testing of SPI code shows that the B0 channel works just fine on both processors, so the hardware is known to be working. There is also a tie between the GND of each board.
After reset, before the master writes to the slave, the SDA/SCL lines are high as expected. But an oscilloscope shot shows that the slave doesn't ACK the SLA+W(slave-address, bus-write), and the SDA and SCL lines are both being held low after SLA+W. When I remove the slave from the bus (leaving the pullups), and perform another bus write, the SDA and SCL lines both return high after SLA+W, and of course, there is no slave ACK.
The datasheet in I2C Slave Receiver Mode mentions several things that will cause the slave to hold SCL low, but nothing should hold SDA low. I've followed the recommended setup procedures from the datasheet USCI Initialization and Reset, and verified with the FET debugger that the code writes the correct values to the correct registers.
Do you know of any issues that I may have overlooked? It seems the I2C peripheral is fairly intelligent, and should at least ACK the address automatically with no program interaction until the data starts to come over the bus.
Raymond Dunnthe slave appears to be stalling the cycle.
A typical mistake is using the wrong slave address. The USCI needs only the upper 7 bits of the slave address (most datasheets give an 8-bit read and write address), right-aligned. Teh 8th R/W bit will be added depending on the UCTR bit when the start condition is invoked.
So if you use the 8-bit write-address form the datasheet, the slave won't respond.
However, in your case you're using the same MSP code on both sides, so when you use the same slave address on both sides (on the intended slave, it must go into the 'own address' register), this is no issue (double-bug-elimination)
Raymond DunnThe datasheet in I2C Slave Receiver Mode mentions several things that will cause the slave to hold SCL low, but nothing should hold SDA low.
But there is another possible condition that might stall the bus: If you don't write data to TXBUF of the master transmitter.If the address is sent, the master will hold SCL low at start of the ACK cycle until you write something to send into TXBUF. While the slave is holding SDA low for its ACK.You can write to TXBUF as soon as you set UCTXSTT. If the slave doesn't ACK, this byte will be discarded and UCNACKIFG is set.
Raymond Dunn It seems the I2C peripheral is fairly intelligent, and should at least ACK the address automatically with no program interaction until the data starts to come over the bus.
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
thanks Jens-Michael,
I wasn't writing the TXBUF soon enough in the cycle. The I2C Transmitter Mode diagram was confusing regarding writing the TXBUF, The way it is drawn, I thought that bus-stalled/TXBUF note referred to the repeated start condition, but I see it clearly now. I have it working now. It looks like I can write the TXBUF immediately after setting UCTXSTT, since the hardware sets UCBxTXIFG automatically when UCTXSTT is set. If this is not true, please correct me.
I have a further question regarding error handling in polled operation. While writing the data bytes, when is the best time to check if the slave has NAK'd data? My loop writes to the TXBUF, and then spins (with a breakout), waiting for the UCBxTXIFG to signal ready for the next data byte. I have code that examines the I2C status after this spin loop; would this be a good place to catch any slave NAK? From the I2C Transmitter Mode diagram, if the slave NAKs a data byte, it looks like the UCBxTXIFG will never be set, the UCBxTXIFG spin-loop breakout will occur, which is where I can check the status to see the UCNACKIFG. Is this robust enough?
-Ray
Raymond DunnIt looks like I can write the TXBUF immediately after setting UCTXSTT, since the hardware sets UCBxTXIFG automatically when UCTXSTT is set. If this is not true, please correct me.
Raymond DunnMy loop writes to the TXBUF, and then spins (with a breakout), waiting for the UCBxTXIFG to signal ready for the next data byte.
However, since a NACK comes when you already wrote the next byte to TXBUF, you're always sending one byte too much (whcih is ignored by the slave). And it doesn't really matter whether you check for NACKIFG inside the TXIFG waiting loop or first wait the loop to end and then check for NACKIFG. Just ensure that you exit the TXIFG waiting loop with a timeout if it isn't set anymore for any reason.However, checking inside the loop lets your code continue faster, saving CPU time for other things.