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.

LP-MSPM0G3507: I2C manual NACK causes Bus Hang low

Part Number: LP-MSPM0G3507

Hi MSP Team,

I am using the MSPM0G launch pad as a peripheral I2C device. I want the M0 to send a NACK when the controller device reads/writes an "out of bounds" register address. Below is the timing structure for a read operation sent to the M0.

The register address, sent by the controller, can be any value, but the M0 must parse whether that value is a valid address, and send an ACK or NACK. I think the only way to achieve this is enabling TargetACKOverride.

Because this condition is rare, I only want to enable the override, when the address is invalid. I am doing this with the following code:

DL_I2C_enableTargetACKOverride(I2C_target_INST); //Override ACK
DL_I2C_setTargetACKOverrideValue(I2C_target_INST, DL_I2C_TARGET_RESPONSE_OVERRIDE_VALUE_NACK); // set the ACK value to 0 (NACK)
DL_I2C_disableTargetACKOverride(I2C_target_INST);

However, when I implement this, the bus line hangs.

Below is an the Controller writing valid Reg Address 0x00 and then reading 1 bytes:

 

However, reading an invalid address, such as 0x21 causes still sends an ACK, but causes the bus line to hang low forever.

Then, the bus line continuously hangs low and the M0 must be power cycled.

Is there a preferred way to implement manual ACK/NACK, or is there any example code?

Thanks!

  • Nishka,

    You should be able to recover the I2C interface just with an I2C peripheral reset. Mind you would have needed put that in your code. In order to do this manual NACK, you would need to have it enabled when the controller sends the write command. You will also make sure I2C clock stretching is enabled and valid for your controller. You must make your determination when the write command comes in, so the NACK can be sent to the controller, before it moves on the the read command. 

    What's happening here is the MSPM0 is still determining if the write command is valid, while your controller has moved on; thus the I2C transaction gets out of sync.