How to write a time counter in internal flash of STM32WB(55RG)

[PATRICK COMBETTE]

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

[Uwe Bonnes]

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.

[PATRICK COMBETTE]

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

[Uwe Bonnes]

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

[PATRICK COMBETTE]

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 :

• ECC bits are not included in the 64 bits word mapping. Am I right ?
• ECC bits are not visible with CUbeProgrammer or STLinkUtility tools. Right ?
• As I already take care of changing unprogrammed bits, why the PROGERR occurs when I do the following with both two utilities ? :
  • Full sector 18 (start @ 0x08012000) is erased (contains "FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ...")
  • I write "00000000 xxxxxxxx 00000000 xxxxxxxx ...." (xxxxxxxx means I don't write this cells) => In this case all is OK and there is no error
  • But if I write "00000000 00000000 xxxxxxxx xxxxxxxx" and then "xxxxxxxx xxxxxxxx xxxxxxxx 00000000 " => the PROGERR occurs
  • I think the rules are respected but still don't understand what is the problem ?
  • With STM32 tools it is only possible to write by 32 bits words
• What do tyou mean by " the ECC bits are not in your hand. So you will get an ECC error with rewrite" ? I don't rewrite, I just set from '1' to '0' the unprogrammed bits.

THank you.