cancel
Showing results for 
Search instead for 
Did you mean: 

I2C lockup in M24SR02-Y

ASpen
Associate II

Our usage of the M24SR02-Y results in spurious lock-ups of the I2C (no ACK being received). The interface can be run with continuous swapping between RF and I²C sessions for anything between a few minutes and a few hours before lock-up happens.

We have the recommended decoupling capacitors in place on the Vcc, and the chip is over a ground-plane, to the side of the coil. Any advice on what to examine to find this error?

(We are investigating simply powering the chip from a microcontroller I/O pin, and cycling power if the I²C stops responding.)

1 ACCEPTED SOLUTION

Accepted Solutions
JP Miller
Senior

​Dear Customer,

This type of spurious lock up could indeed come from electrical problems. We recommend the VCC is stable, no overlap between the coil and the I2C circuitry, and make sure the I2C bus line pull-up resistor and capacitor match the allowed values depending on the I2C bus frequency in chapter 'I2C timing measurement condition ' of the datasheet. The ground plane definitely helps.

Could you please specify on which byte (Device Select code or other bytes of the I2C transfer), the noack happens?

If this is on the Device Address, it could mean an RF session is not properly terminated for some reason and in this case a KillRFsession might help for . If it is on another byte after the Device Select code, it could be the M24SR is still processing an internal process and the response is not ready for example. The transaction needs to be retried.

Hoping this will help you figuring out the issue.

Regards

View solution in original post

1 REPLY 1
JP Miller
Senior

​Dear Customer,

This type of spurious lock up could indeed come from electrical problems. We recommend the VCC is stable, no overlap between the coil and the I2C circuitry, and make sure the I2C bus line pull-up resistor and capacitor match the allowed values depending on the I2C bus frequency in chapter 'I2C timing measurement condition ' of the datasheet. The ground plane definitely helps.

Could you please specify on which byte (Device Select code or other bytes of the I2C transfer), the noack happens?

If this is on the Device Address, it could mean an RF session is not properly terminated for some reason and in this case a KillRFsession might help for . If it is on another byte after the Device Select code, it could be the M24SR is still processing an internal process and the response is not ready for example. The transaction needs to be retried.

Hoping this will help you figuring out the issue.

Regards