How ''true'' is true EEPROM on STM32L1xxx devices

[mmensch]

Posted on July 01, 2014 at 17:11

Hi,

I am looking for a device with ''true'' internal EEPROM and found that STM32L1xxx promise to have it. Now I took a closer look at the data sheet and things turned out to be not so simple as I wished they were. What I want is a set of registers in which I write an address, a (number of) data bytes and a command which then starts a self timed erase, write, read, whatever I want. In a busy register I can read if the operation has finished. And while operation is running any other code not accessing the EEPROM can be executed. That is what I would call a true EEPROM. If code execution is or must be halted or is restricted, well it means you have to beware of possible side effects. That seems to be the case with the STM32L1xxx. Please can someone from ST give some clearing words. Thanks a lot Martin

[Tesla DeLorean]

Posted on July 01, 2014 at 17:36

ST has a pretty low participation level here.

The L1 series parts are targeted at constant battery power, have you considered just using NVRAM? I suspect the lack of EEPROM tends to go to process/geometry issue, and testing. Consider using an external EEPROM that actually meets your functional requirements.

[mmensch]

Posted on July 02, 2014 at 09:44

Thank you Clive,

we don't have a battery powered system here, so NVRAM is not an option. I became aware of the L series because they promised ''true'' EEPROM. My (small) experience with STM32s is all with F051. I connected an SPI EEPROM to it. But we plan to do our future projects with ARM Cortex-Mx and it would be great to choose a family that is compatible in itself, especially concerning hardware related software. As much as I saw, that is not the case when going from F051 to L1 series. Maybe we should start with F1 series? Some suggestions here are welcome. Thanks a lot Martin

[os_kopernika]

Posted on July 02, 2014 at 22:19

''That seems to be the case with the STM32L1xxx.''

Any reference?

[mmensch]

Posted on July 03, 2014 at 09:06

Hi Brutte,

I refer to STM32L1xx reference manual RM0038. Page 53 says: During a write/erase operation to the NVM (except Half Page programming or Double-word erase/write), any attempt to read the same bank of NVM stalls the bus. The read operation is executed correctly once the programming operation is completed. This means that code or data fetches cannot be performed while a write/erase operation is ongoing in the same bank. There are closer explanations following page 63. As much as I understand it the given exceptions generate a bus error (whatever happens then). Stalling the bus lasts between 3 and 4 msec which I found in STM32L15x and STM32L100 data sheets. For a system using interrupts I think this is generally too much. There is a possibility to work with Cat4 and Cat5 devices, which are the ones with very large memory (page 40). But what I desire would lead to leaving half the program memory empty just to have EEPROM memory in a seperate bank. I hope I got that right, maybe Clive can show a thumb up or down on this. Martin

[waclawek.jan]

Posted on July 03, 2014 at 11:56

> There are closer explanations following page 63. As much as I understand it the given exceptions generate a bus error (whatever happens then).

No; stall means that the processor will wait until the FLASH is ready to serve data again.

> For a system using interrupts I think this is generally too much.

There is an option to place the critical parts of code - mainly interrups - into RAM and run them from there during FLASH programming. > But what I desire would lead to leaving half the program memory empty just to have EEPROM memory in a seperate bank. I'd say, given enough incentive (expressed usually in Mpcs) ST will be happy to provide you with a chip like that. OTOH, if you have that purchasing power, it's not likely you ask here... :| JW