I2C Bus Issues - NT3H2211

Showing results for 
Search instead for 
Did you mean: 

I2C Bus Issues - NT3H2211

NXP Employee
NXP Employee

Have a customer who is seeing the following:

a) Some of their NT3H2211 units are suffering from the I2C bus seizing up and the MCU cannot communicate with it. It goes into an unresponsive state.

b) In their application, to conserve power, they have several power subsystems. They keep the NT3H2211 off until the need to write to it or when it receives an NFC signal and tells the MCU that a field is present. Then they power up the NT3H2211 and have a wait time for 5ms before they communicate via NFC. What is the setup time they should have before attempting to write or read via I2C?

c) Some additional notes from their experiments. When they keep the NT3H2211 powered on all the times, they do not suffer from the I2C lockup on any of the parts.

d) Some of the offending lock-up parts, when locked-up, cannot be reset. They try to kill the power to the supply rail for 1ms but the locked-up part does not recover. 


Bottom line, is there a setup time they should use when powering up the NT3H2211 and then writing/reading from I2C? Is it possible that there is a batch difference between units to cause some units to lock up?

This is a critical issue with the customer, please let us know your inputs.

Labels (1)
1 Reply

NXP Employee
NXP Employee

Hello Michael,

The typical wait time is at least 500 us before sending commands to the NT3H2211 once power is applied. I see you mentioned 5 ms, so it is strange. Please provide us more details:

- What is the applied VDD?

- What are the values of the pull-ups?

- Are there other devices connected to the I2C bus?

- Do you have some scopes of the I2C frames?

- If possible please share the schematics.

For the locked ICs, it might be that the slave address was changed inadvertently by a command. Try with different addresses (e.g. 0x00) to see if the IC responds.

Looking forward to your reply.


Jorge Gonzalez