m95m04-dr read write timing

[astrosumit]

as per data sheet

below is the timing details for read write operations for m95m04-dr:

• Write time
  • Byte write within 5 ms
  • Page write within 5 ms

can we operate or perform operations in 1microsecond or so? if yes what about write/read data integrity?

Regards,

Sumit

[Peter BENSCH]

Welcome @astrosumit, to the community!

The M95M04-DR has an SPI interface with a maximum clock frequency of f = 10MHz.
A write access requires at least n = 40 clock cycles.

Let's do the maths: transferring a single byte therefore takes at least 1/f * n = 4µs. However, this does not take into account the time required by the internal state machine to actually write to the EEPROM cells. Typically, this time is significantly less than 5ms, but is heavily dependent on e.gg. the number of write cycles and the chip temperature. In order to ensure successful writing under all the environmental conditions specified in the data sheet, the maximum time specified there is therefore 5ms (BTW 10ms for the LID instruction).

For which application do you need such short write times on NVM memory?

Regards
/Peter

[astrosumit]

Thanks @Peter BENSCH ,

We are having requirement wherein we have bytes of read operations(less than 512bytes) and pages read operations.

actually we are storing data on to eeprom which would contain values of many variables to be initialized at specified time from specified location on eeprom.

variable size varies so while reading the variable values we have to perform byte/page read operations. which is taking huge time to initialize all variables(half minute) as we are keeping 5ms delay between each SPI frames(read command and data frame).

we are keeping 5ms delay between each read command frame and data frames. hence while read a byte/or page we are having 10ms(5ms command frame + 5ms data frame) delay.

we need to reduce this timing(variables(kilobytes) read) to as minimal as possible.(few second or milliseconds)

so what should be the acceptable time between SPI read command/data frames? shall we remove this delay of 5ms or keep minimal delay of few microseconds? 

here we are more concerned towards reducing read time and accuracy of the data.

writing time onto eeprom is not a concern. we have time to write on to eeprom well before the operation where we would read these data and load variables with value.

but these data from eeprom shall be read back later, which should be performed in minimal time for initializing variable with values.

considering 4us time for 1 byte, we would be needing 512*1024*4 = 2097.152ms = 2.097 seconds to write on complete memory. 

would be it be same for read operation?

lets say we are operating on 5MHz and up to 60-70 degree centigrade, also we would be having multiple read cycles. Say, 1000 read cycles one(read command + data read clock) for each variable to be loaded with value from eeprom.

[Peter BENSCH · Accepted solution]

In your calculation, you are ignoring the fact that there is not only byte-by-byte access.

When reading, in extreme cases you can read the entire EEPROM area with a single READ command (see description in the data sheet, section 6.5).

When writing, you can write a page of 512 bytes in one go, i.e. up to 512 consecutive bytes. You only address the first byte of the page and can then let the rest follow in the same write cycle, so you do not need to wait for a complete write cycle each time.

Incidentally, although the 5ms are specified as the maximum time for writing, it does not make sense to simply wait 5ms, but is much better to query the bit WIP in the status register (data sheet, section 6.3).

Regards
/Peter

[astrosumit]

Dear @Peter BENSCH , Thanks again for the response.

in the code we wrote we are performing both byte and page read write operation whenever required.

also we are checking WIP bit after every operation, we are polling this bit. once it is zero then only are proceeding with the next operation.

just as it is mentioned in the data sheet for safer side we kept 5ms intentional delay.

thank you for the discussion, it gave good clarity and confidence.

Regards,

Sumit