• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 608 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.

MSP430I2041: I2C issues NAK to master

manish
Prodigy 60 points

Part Number: MSP430I2041

Tool/software:

To migrate from UART to I2C, changes were made to code generated by EMDC as outlined in this thread:

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/809952/msp430i2040-interfacing-the-msp430i2040s-sub-metering-evm-on-i2c/2998095

The issue is that sometimes, the I2C master transactions work fine and other times, the slave device issues NAK. It can happen anywhere - on the address byte itself, or midway into a master write, or even anywhere in a master read phase. 

Example of successful I2C Master Read transaction with command 0x04 to read the "mode" of the HMI state machine is in waveform below. 

Example of failed I2C master read transaction for command 0x04 to read the HMI state is in the waveform below. 

When same read command 0x04 is issued in a loop, then the I2C slave give NAK for 15 read/write transactions, and then works for four read/write transactions. And this pattern continues consistently, for as long as the master issues the I2C commands. In this test, there is no signal given on SD24 interfaces, which are configured in EMDC generated code to measure a single phase (one voltage, one current channel).

The double bars in the waveform above are shown with more detail in the waveform below. 

Each 0x04 write command has 0x0A, 0x55, 0xAA, 0x06, 0x04, 0x01, 0x00, 0x00, 0x05, 0x00 on I2C sent by master. For read, master sends 0x0A (I2C address + Read) followed by enough SCL cycles to read 15 bytes from I2C slave.

Can you please help understand what could cause the NAKs generated by the MSP430I2041 I2C slave on the I2C bus?

Some possibilities that are likely:

1. I2C (eUSCI-B) is disabled when I2041 is busy with other things. And the I2C / eUSCI is just telling master it can't be served. 

2. Some tight loop in EMDC code takes too long and I2C is disabled during that busy time. 

3. Interrupts are not configured right..

There is little to no change made to EMDC output - only changes are as outlined in the other E2E thread referred to above. Please see if you can offer any insights. 

  • 0
    Guru 26155 points

    An I2C NAK is simply the slave not pulling the data line low. It can't happen because the I2C master is busy. In fact it can't happen until the rising edge of the clock and the master will stall with the clock held low if it doesn't have data available in TXBUF. Or for a read the data in RXBUF hasn't been read.

  • 0
    Prodigy 60 points

    Hi David, yes, this is the slave issuing NAK. It is doing so even at the first byte from master, which is the I2C address. Is there something in EMDC generated code that disables eUSCI when the ADC processing is in progress? There is no data in my understanding in the RXBUF that has not been read. If you see the waveforms, some transactions work fine, and then i2041 (i2c slave) issues NAK for several i2c address phases initiated by the master. Really need help on this. Thanks. 

  • 0 in reply to manish
    Guru 26155 points

    I see now that the MSP430 is running as an I2C slave. Which is quite a different thing. But once set up the I2C port is going to keep doing its thing. It can hold SCL (clock) low if data isn't available in TXBUF or read from RXBUF. So if the code is slow in doing those things you will see stretched clocks for the ACK/NAK.

    A failure to acknowledge the address would be because the I2C port wasn't running or misconfigured. I can't see other code disabling serial ports but it is easy enough to check. Look at the binary file (I would run it through msp430-elf-objdump -S, but that is a GCC thing.) for references to the I2C port address.

    If you don't find that, then it has to be your code.

  • 0 in reply to David Schultz
    Prodigy 60 points

    The issue is resolved. For the benefits of anyone else running into this, the NAKs were because the slave was getting reset repeatedly. It takes some time for the slave to reset and initialise I2C again, and in the interim, the SDA is not pulled low by the slave. It was getting reset due to grounding issues in the board. Once the ground on the voltage and current AFEs were connected together, the i2041 I2C slave reset issue was gone and the transactions started to work fine.

**Attention** This is a public forum