2021-07-16 10:59 PM
Hello everyone,
For my application, I need to record a time counter in flash memory, with a resolution of 1/10 of hour (eg. 6 minutes).
Here is what I do :
As I know there is a limitation for flash lifetime (10000 erase cycles), I built an algorithm which only write zeros in one flash sector (I'm using the 18th sector for that and tried with others). The idea was to write zeros because this normally don't needs to erase before writting (the number of 0s is equal to the number of 1/10 hour elapsed). I saw that there is an other constraint which is to write only dwords (64 bits) from FF to 00, and built my algorythm thaking that into account (using full dword table values set from FFFFFFFFFFFFFFFF to 0000000000000000).
The problem encountered :
My algorithm is Ok as I coded, and I could test the general principle, but I encounter a HAL_ERROR status returned by the HAL write function "HAL_FLASH_Program". I have investigate much deeper and could see the "FLASH_WaitForLastOperation" function found the PROGERR bit set in the SR register of the flash.
My tests and investigations :
I made many tests and trials to check if it was not because of a protection or alignment problem, but all seems to be OK on theese points.
I finally tested both with STM32CubeProgrammer and ST-LINKUtility, and obtain a similar results when I change FLASH memory cells values from FFFFFFFF to 00000000 . In fact, while I write 32 bits at non consecutive adresses, all wrtites are performed correctly and with no rrors. But if I write 00000000 at two consecutive adresses, then the next following writes return with the write error...
Do someone could give me explanations about what would be the origin of the problem ? if needed I can post my code (functions used for write operation), just let me know.
I hope someone will be able to help me, I'm workig on that point for more than 2 full days !
With by best regards, I wish a nice day to all.
Patrick
2021-07-17 03:11 AM
Overwrite ECC protected flash is no good idea. Either have the RTC battery backups and use battery RAM for your purpose, or implement a power failure interrupt and transfer the battery ram value to flash on pending power failure or accumlate runtime in RAM and write is perhaps once a day or week to flash.
2021-07-17 11:03 PM
Thank you for your reply.
In fact, my final product will not have a battery, it is an equipment whiche is supplied directly by the mains 230Vac + 5V power supply.
My customer don't want to have a battery.
For me, a flash memory is made for parameters backup, and such parameters may be changed by an administrator or maintenance operator, so in case of change they are written in ths flash.
Why are you talking about ECC protected flash area ?
There is always limitations due to erase lifetime, this is normal, but I don't understand why rewrite doesn't work after write at two consecutive adress ?
Is it in relation to ECC data bits ?
THanks again.
Patrick
2021-07-18 03:36 AM
The WL5 flash is written in blocks of 64 bits with 8 ECC bits. As for normal flash, you can only change unprogrammed bits to programmed bits. For the payload, you can select a pattern that fits this need. But the ECC bits are not in your hand. So you will get an ECC error with rewrite
2021-07-19 11:27 PM
hello again,
I'm OK with the mapping of 64 bits with 8 ECC bits. I already take care of changing unprogrammed bits, meaninf '1' bits set to '0' only.
However, my questions remains :
THank you.
2024-07-16 06:51 AM
Hello Patrick,
Although, time has passed, do you remember conclusions for your issue?
Did you manage writing successive addresses in flash with no error?
Did you manage to change '1' bits to '0' without EEC issue?
Thank you,
Ari