Inquire about initial behavior of M95M01-A125, M95M01-A145

[HKim.4]

I have a problem with M95M01-A125, M95M01-A145.

When I read first data from EEPROM, I always get 0 from EEPROM.

According to user's manual, when EEPROM state is in WIP(Write In Progress) a read command is ignored.

In my case, first read command is not working properly, but second read command is working well. In terms of this result, I assume that sending dummy data via SPI communication to read data correctly from EEPROM at first.

My question is that my thought is right or not. if my thought is wrong, how I handle this issue?

Thank you in advance.

[Peter BENSCH]

Dear HKim.4,

please be so kind and use the common language English while using this forum, thank you.

Best regards,

/Peter

[Peter BENSCH]

It is not a good idea to send a dummy byte to compensate the time for the WIP, as this time might vary. It is definitely recommended to use the proposal mentioned in the datasheet of the EEPROM: "During a Write cycle, reading continuously the WIP bit allows to detect when the device becomes ready (WIP=0) to decode a new command."

Does it answer your question?

/Peter

[HKim.4]

Sorry, I didn't make that quite clear.

What I mean is, even if EEPROM state is not in WIP, I am not able to read data from EERPOM​ at first after MCU wake-up.

I don't want to compensate the the for the WIP.

I didn't get the correct data from EEPROM throughout READ command at first, but after that I am able to read data from EEPROM.

So, I think that EEPROM ignores a first read command.

I was wondering my assumption is correct or not.

Best regards,

HC Kim

[Peter BENSCH]

Thank you for clarifying the question.

It is definitely not the usual way to do a dummy read to get a successful communication. You might double-check the programming of the device talking to the EEPROM, as well as use a logic analyzer to check communication on the SPI bus.

Best regards,

/Peter

[HKim.4]

​Thank you for prompt reply.

I already double-check what you said. but there is no problem.

Do you have any other recommendations for this issue?

Best regards,

HC Kim

[Peter BENSCH]

Well, the EEPROM is made in billions and works perfectly. So the issue must be the program flow driving the SPI.

Did you observe datasheet, section 3.4.1, describing the protocol control?

Short extract:

The Chip Select (S) input offers a built-in safety feature, as the S input is edge-sensitive as well as level-sensitive: after power-up, the device is not selected until a falling edge has first been detected on Chip Select (S). This ensures that Chip Select (S) must have been high prior to going low, in order to start the first operation.

...and additionally:

To execute Read commands (READ, RDSR, RDID, RDLS), the device must decode:

• a falling edge and a low level on Chip Select (S) during the whole command

Are you really having a HI level at /S before starting the read sequence?

Please let us know the result.

/Peter

[HKim.4]

​I followed the instructions in the manual 3.4.1.

In my case, even if Chip Select(S) has high level before starting the read sequence, it doesn't work.

Any Recommandations?

Best regards,

HC Kim

[Peter BENSCH]

Unfortunately not, any further recommendation would require a deeper look into the programming sequence of your controller.

Best regards,

/Peter

[HKim.4]

​Thank you for your support.

I'll check more the programming sequence.

Best regards,

HC Kim.