Skip to main content
A
ASpen
Visitor II
November 13, 2020
Solved

I2C lockup in M24SR02-Y

  • November 13, 2020
  • 1 reply
  • 646 views

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.)

    This topic has been closed for replies.
    Best answer by JP Miller

    ​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

    1 reply

    J
    JP MillerAnswer
    ST Employee
    November 26, 2020

    ​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

    Terms & ConditionsAccessibility statement