cancel
Showing results for 
Search instead for 
Did you mean: 

M24LR64E NACK on I2C write in a noise enviroment

BMace.881
Associate II

Hi!

I use M24LR64E supplied with 3V3 and communicating with PIC microcontroller.

I am facing a big and urgent problem: I2C writes are working really fine according to manual specification until the memory is subjected to EMI.

After that, any I2C write returns NACK.

How can I work around?

1 ACCEPTED SOLUTION

Accepted Solutions
JL. Lebon
ST Employee

​Hello,

If I2C bus is dead locked, there is a way to restart it from the microcontroller by sending a special series of start/stop commands. This workaround is explained in the application note AN1471, that you can find here: https://www.st.com/content/ccc/resource/technical/document/application_note/3a/cf/22/13/7a/3d/44/9e/CD00004295.pdf/files/CD00004295.pdf/jcr:content/translations/en.CD00004295.pdf

This may help you workaround your issue in case you can't reduce the noise on antenna.

Best regads.

View solution in original post

8 REPLIES 8
Ozone
Lead

> I am facing a big and urgent problem: I2C writes are working really fine according to manual specification until the memory is subjected to EMI.

Either redesign, or trying to recover in software.

I2C means IIC means Inter-IC bus. It was intended for short PCB traces, and low to medium communication requirements on-board.

Perhaps trying a smaller pull-up resistor (increase current, improve signal-to-noise ratio).

Thanks for replying.

I am using 2K2 for pull-ups and the signal on SCL and SDA respects specifications.

After many tests, It seems noise "goes in" through the antenna and blocks I2C side. If I cease the noise generator, the I2C side remains blocked. When I put the smartphone with NFC close, the I2C communication is recovered.

It seems noise is being received by RF side as a command.

What can I do, knowing I cannot power off memory by the microcontroller?

JL. Lebon
ST Employee

​Hello,

If I2C bus is dead locked, there is a way to restart it from the microcontroller by sending a special series of start/stop commands. This workaround is explained in the application note AN1471, that you can find here: https://www.st.com/content/ccc/resource/technical/document/application_note/3a/cf/22/13/7a/3d/44/9e/CD00004295.pdf/files/CD00004295.pdf/jcr:content/translations/en.CD00004295.pdf

This may help you workaround your issue in case you can't reduce the noise on antenna.

Best regads.

I'd say, improve noise immunity by optimizing the PCB layout.

Expected EMI during "normal" operation should not interfere with the device's operation - like I2C.

For standard burst/surge testing, the device is allowed to require a power cycle after the test.

This method could help if the slave blocks the SDA line, i.e. keeps it down.

BMace.881
Associate II

Hi!

Thanks for prompt reply.

I am already using the 9 Start + 1 Stop procedure, but communication cannot be recovered.

When the communication is blocked, SDA line goes to right state (1), I2C master correctly tries to start a new read, for example, but the answer is always NACK to device select.

The only way to recover it is forcing noise again, having a NFC reader close to antenna or powering down VCC.

By the way, how can I get an answer from ST. I send many questions through support request form, but I cannot get reply.

Bruno

> I am already using the 9 Start + 1 Stop procedure, but communication cannot be recovered.

Which is not so surprising, IMHO.

The M24LR64 is a complex I2C device, with several different states and I2C access sequences. With random noise EMI, you don't know wher it got stuck.

As mentioned, I would see a hardware redesign (PCB) as most promising.

And/or, you could try to reduce the pull-up resistors to the smallest amount your hardware is working with. Higher currents would decrease noise sensitivity.

> By the way, how can I get an answer from ST. I send many questions through support request form, but I cannot get reply.

Perhaps try to contact your local distributor, to contact ST on your behalf.

In certain technical aspects like this, ST is chronically under-represented on this forum.

JL. Lebon
ST Employee

​Dear Bruno,

In order to help you , I need to better understand your application and how to make it fail.

-> I am facing a big and urgent problem: I2C writes are working really fine according to manual specification until the memory is subjected to EMI.

Can you please explain how you inject EMI noise on the memory, and what kind of EMI noise it is ?

-> If I cease the noise generator, the I2C side remains blocked. When I put the smartphone with NFC close, the I2C communication is recovered.

Does this mean that the NCF phone has been removed from the tag antenna ?

When phone is put back, is it with or without noise generation ?

Is Vcc maintained ON during the complete operation ?

-> The only way to recover it is forcing noise again, having a NFC reader close to antenna or powering down VCC.

Do you mean you have to generate noise + having the NFC phone close to the antenna ?

By the way, I am an ST employee, so, yes, ST is represented on this forum 😉

Best regards.