• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 3537 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430 not ACK slave address

Raymond Dunn
Prodigy 190 points
Other Parts Discussed in Thread: MSP430F2418

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:

  1. port 3 pins are setup for primary peripheral function to enable UCB0SDA and UCB0SCL (P3SEL = 0x06)
  2. the pullup resistors on SDA/SCL are 4.7k, bit rate is 50kHz
  3. USCI_B0 is initialized as I2C operation, with UCMST=0 for slave mode, and UCTXNACK=0 to ACK the address
  4. UCB0I2COA is initialized with the (non-shifted) slave address, and the oscilloscope I2C decode confirms the correct address is sent on the bus
  5. the bus state-change interrupts are enabled with UCB0I2CIE = (BYTE)(UCNACKIE + UCSTPIE + UCSTTIE);
  6. the TX and RX interrupts are also enabled with IE2 |= (BYTE)(UCB0RXIE + UCB0TXIE);
  7. the slave executes the interrupt (bus state-change) for START, and correctly decodes a bus-write (slave read), but then nothing further happens

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.

  • 0
    Guru 227245 points

    Raymond Dunn said:
    the slave appears to be stalling the cycle.

    Does it stall the bus (holding SCL low) or does it just not ACK to the start command (stalling the software progress due to incorrect or non-existent error handling)

    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 Dunn said:
    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. 

    Well, there is wone thing: if the slave wants to send an ACK (SDA low), but holds SCL low because it waits for the software. However, this is no condition that should happen with the USCI, as the slave will immediately ACK and receive the first byte. It will stall the bus on the 7th bit of the second received byte if the first one wasn't read fro RXBUF.

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

    Yep. If data comes :)

  • 0 in reply to Jens-Michael Gross
    Prodigy 190 points

    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

  • 0 in reply to Raymond Dunn
    Guru 227245 points

    Raymond Dunn said:
    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.

    No, that's totally correct. So keep in mind that a TX ISR is called long before the slave has acked its existence. So the code must be able to deal with a slave not showing up even though the first byte was already pu tinto TXBUF.

    Raymond Dunn said:
    My loop writes to the TXBUF, and then spins (with a breakout), waiting for the UCBxTXIFG to signal ready for the next data byte.

    In this waiting loop you can check for NACKIFG and bail out if it comes.

    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.

**Attention** This is a public forum