• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 79 subscribers
  • Views 594 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Problems with I2C Slave

Roy Deabill
Expert 1595 points

Other Parts Discussed in Thread: MSP430F247

HI,

I am having a problem with running an I2C slave on the MSP430F247.

The master initially writes data to the slave which contains a Command byte and some data. It then starts a read sequence to read back data dependant on the command byte.

The receive ISR detects the command byte in the frame and then fills the transmit buffer ready for the read from the master. This means that the ISR for the command byte reception does not complete until partway through, the actual reception of the third data byte. Normally this causes minor SCL stretching between the seventh and eighth SWCL pulse on the third byte. Then the ISR for the second and third byte run with a very short delay in between. Usually this operates very well, but at least once every 24 hours the I2C system hangs up with SCL held low.

I have managed to trap exactly what happens unis a scope and it seems that the error is caused by the fact that the MSP430 does not acknowledge the third data byte but sends a NAK. Consequently the Rx ISR is only called for the first and second bytes, and not the third byte. The effect of the NAK is that the master generates a STOP condition, which is detected and causes the expected interrupt.

I have attached a file which shows the srennshots from the scope and explains this in more detail.

Any help on reasons why the USCI would send a NACK would be appreciated

 

 

I2C_Error.docx
  • 0
    Guru 227245 points

    It is normal I2C protcol that the master will acknowledge the last byte of a transmission with a NAK before sending either a stop or a repeated start condition.
    The slave, when receiving data, will either do an ACK or a NAK, depending on what happens. ACK will let the master continue, NAK will tell the master that the slave is unavailable (after the address byte) or an operation cannot be performed, a buffer is filled or whatever, depending on the special data protocol between master and slave.

    Anyway, the USCI slave will never send a NAK to a data byte on its own.

    Note that the bus is NOT stalled even if RXBUF is not read when this NAK is sent. That's not the problem. It is possible that for some reason a clock cycle isn't detected (I don't know why' and the 'NAK' is rather a 'I wait for the last bit'. But then teh next clock cycly must pass undetected too or else the RXIRQ would be triggered anyway (with a wrong LSB and no more clock cycle for the ACK). It' spossible that the nice digital pulses on your analyzer look rather distorted if read with an analog channel.

    Once the cycle is incomplete, the slave software should detect the incomplete addressing and the next read attempt should fail. It should be possible to reply to the next (write) addressing with a NAK rather than sending a byte. The master should detect this and restart the whole protocol. If setting UCTXNAK doe snot work, reset the SPI completely.

    My guess is that your software won't start transmitting anything unless the former command sequence has been finished properly.

    What if the master sends an unsupported command? What if the master has otehr problems with the implementation of the protocol? (e.g. sends just 1 instead of two bytes after the command) or whatever? Your software should detect this and react accordingly. Looks like it always assumes a clean run. Yet there is one tha tis not so clean and the whole application stalls.

    The problem is not (only) that a NAK is transmitted for some unknown reason, the main problem is that your slave software does not address any errors in the protocol and causes a lockup if sonething isn't as expected. You can simulate this by omitting the send of the last byte by the master. Once your software can cope with protocol errors, you can go and look for the reason of the erroneous NAK. It might be  noisy line, power fluctuations, whatever. Be sure that you look with an analog scope channel or you'll miss it.

    To verify that my guesses are right, or what else might be wrong, I'll need to look into your ISRs.

**Attention** This is a public forum