M95P32 EEPROM stops responding

[perencia-wc]

Hi everyone,

We're using the M95P32 page EEPROM and have encountered an issue where some devices stop responding after a period of normal operation. Initially, they function as expected, but after some time, communication fails.

Specifically, after power-up, the first command we send is the JEDEC ID request. In the failing devices, this command consistently returns all zeros. We've also attempted to read the configuration and safety registers, but those return zeros as well. A software reset before sending the JEDEC command has no effect.

This is an example of a failing JEDEC ID request (blue is MOSI, green is MISO and purple is CS)

Interestingly, we discovered by chance that performing a quick power cycle—shutting down and immediately powering back up without allowing Vcc to fully drop to 0V—restores normal operation.

This is an example of successful power up, you can see how the EEPROM responds in the green line.

However, if Vcc is allowed to fully discharge before powering up again, the device remains unresponsive.

In both cases, Vcc is 3V3 more than a second before the JEDEC id request starts.

Our questions are:

• Does this behavior indicate that the chip is damaged?

• If so, what could be the likely cause?

• Is there a known recovery method aside from the specific power cycling technique we've found?

Any insights would be greatly appreciated.

Best regards.

[perencia-wc]

Anybody with any idea? It seems concerning because the memory cannot be recovered under normal circumstances.

[Tesla DeLorean]

Consider opening an online support request  https://ols.st.com/s/

Diagram your circuit showing pull-ups, etc.

[perencia-wc]

Thanks for the suggestion! The problem appears to be fixed following @bmckenney’s hint.

[bmckenney]

I haven't seen this behavior with my (one) M95P32. 

Is there any chance /HOLD is floating?

[perencia-wc]

Hi @bmckenney 

Yes, the /HOLD line is floating. I can confirm that pulling it high resolves the issue, while pulling it low reproduces it— which aligns perfectly with /HOLD’s intended function :smiling_face_with_smiling_eyes:

That said, beyond the necessary rework, I’m trying to understand why this issue suddenly appeared. I’m not an electronic engineer, so it’s puzzling to me that only this particular board is affected, even though all the others share the same design—and this one worked fine until recently. I get that leaving the line floating could lead to inconsistent behavior due to small physical variations, and that most boards might still function correctly by chance. What I find harder to grasp is why the affected board has suddenly become much more prone to failure.