The title explain almost everything.
Long version:
For my application I need to store some values (12 numbers: some integers and some floats) to some non-volatile memory. 32 numbers mean 128bytes if I use single precision or int32 notation, which is fine for me. For this reason I decided that the internal EEPROM (6kb in total) is more than enough for such purpose. These numbers will change once in several weeks, so no problem of wear down.
Before you ask, I already spent days trying to understand how to do it using mbed OS.
What I tried/checked:
- LittleFileSystem => build complete, but I got a non documented error at runtime (
Error Status: 0x80FF0144 Code: 324 Module: 255
Error Message: Assertion failed: block < lfs->cfg->block_count
Location: 0x8026EA1
File: lfs.c+18
Error Value: 0x0
)
2. FlashIAPBlockDevice => seems to not be enabled for my board (file not found error)
3. Flash_api => not really documented, and the fact that the MCU specific file define NUM_PAGES_IN_SECTOR make me worry about compatibility with the EEPROM memory (which does not have pages)
4. Access directly the registers (ST M0367 Reference manual) => not really clear how to read the register. And it seems a bit weird to me to really mess with the registers for such a simple and common operation
5. KVStore => while running the example file “as-is” I’ve got a HardFault error at runtime (during the part where dummy keys are removed) and even before the exit status code for all the functions are 265 instead of “0 if success, negative if error”
Unfortunately, I don’t believe that Mbed supports STMicro’s internal EEPROM out of the box, you’d have to use the STMicro HAL functions.
For your target, it looks like those functions are in stm32l0xx_hal_flash_ex.h. I’ve not used it, but this looks like a decent tutorial for how to use those functions: https://m0agx.eu/2018/04/15/using-the-internal-eeprom-of-stm32l/
If you want to use LittleFileSystem or KVStore, it probably wouldn’t be too hard to make something that implements BlockDevice and calls through to the STMicro HAL functions. Then, Mbed sould see the EEPROM just like an external EEPROM or internal flash.
Thanks for the tip, but after one day working on it, what I understood is that to access the memory he use the memcpy function to copy the data between RAM and EEPROM.
The rest of the code is just some CRC to check that data have been written correctly.
Unfortunately I still got another HardFault error. I will do some other test next week, but I don’t have much hopes…
I don’t think you want to use memcpy, I think you want to call DATA_EEPROM_ProgramWord(). You will probably get a HardFault if you try to memcpy to EEPROM, because it’s not writeable through normal means.
The function DATA_EEPROM_ProgramWord() is not recognised as a valid function (probably is not defined anywhere in my mbedOS/HAL version).
Looking at STM32 UM1749 User Manual - Description of STM32L0 HAL and Low Layer drivers I have found that the Extend Flash driver define the function HAL_FLASHEx_DATAEEPROM_Program() to program a single 32bit word (optionally also a byte or a half word), however I always get the same HardFault mbedOS error code: 0x80FF013D (the same I have when I’m using memcpy, so it’s not that one the problem) which is quite generic.
If I understood correctly how to read the entry point, then it should point to the file:
Base Addr Size Type Attr Idx E Section Name Object
0x0801aad4 0x0000001c Code RO 1194 .text.mbed_start BUILD/NUCLEO_L073RZ/ARMC6/mbed-os/cmsis/device/rtos/source/mbed_boot.o
Other notes:
- I have unlocked the EEPROM for writing operations using both the functions
HAL_FLASH_Unlock() and HAL_FLASHEx_DATAEEPROM_Unlock()
- In any case, this should not be an EEPROM blocked problem since the FLASH base driver define several soft error (section 19.3.1, page 202 of the above manual)
- The same error occur while trying to erase a word (HAL function)
