ChibiOS Free Embedded RTOS

HI, I'm saving a few parameters in flash (in this case normally only updated once when being installed in the field).

Then I encountered this Heisenbug. With debugging enabled it worked, when disabled it didn't. Turns out its that one delay that does the trick... (the debug code is if (debug) {chprintf (...); chThdsleepmilliseconds (30); /* allow the debug info to flush*/ } )

Does anybody know what I'm doing wrong? According my interpretation of the datasheet, I think that waiting for the flash to be not-busy should be enough to continue with "erase done, clear the PER bit"...

The symptom is that the store of the parameters results in "0" in the flash. I'm guessing that it would do this when not properly erased.

(I'm using 64 bits of flash memory, while in fact I need 2-3 bits for one parameter (stored as 32 bits) and about 10 bits for the other (also stored as 32bits). So "option bytes" would also be possible for this one application, but this whole structure is copied from other projects, so way less hassle to do it like this).

On a slightly related note...

On older chips, you could program an already-programmed word to something that was bitwise smaller. So for example you could do 0xffff -> 0xfff3 -> 0xfff0 -> 0xff00 -> 0xf000 -> 0x0000. On these chips the specs say that the only allowed "reprogramming" is to value of 0.

I now understand why: each 64-bit word has an 8 bit checksum to do single-error-correct, double-error-detect bit errors. When I try to program 0xfff3-> 0xfff0, it is quite likely that there will be ECC bits that go from 0 -> 1 so the new word cannot be programmed without an erase.

But if there is a 64-bit word that I've programmed with say 60 bits still high, then I can lower a single bit and... it is guaranteed that this will be detected: the ECC word will be different. I can lower another bit and we're in the double-error-detect area: It is guaranteed that the ECC word is different and something checks out "wrong" i.e. it can't be corrected. Change another bit and the ECC word is guaranteed to be wrong, but it would possibly be corrected to a different dataword. Change 4 bits and you're in the territory where you might get a valid word again. Now if my word starts out with 60 bits "1" there are 60*59*58*57/4*3*2*1 possible ways of doing that. I'm betting that about 1/256 of these 487635 (about 1900) have precisely the SAME checksum as the original word. So from a physical point of view, it would be possible to reprogram to one of those 1900 different datawords with the same ECC code.

Now I understand the nightmare that ST would open itself up to if it would specify the ECC code in the datasheet and then publish that it can be done. So I understand the "can't be done" in the datasheet... But would the hardware allow it? My "erase didn't work" always resulted in precisely "0" in the flash location. That would hint at the hardware trying to program it, and if it didn't work (i.e. simply try to program and compare the resulting dataword with the "requested value"), continue to program the new value "0".

If it would compare the current value in flash with the requested new value and error out if there are any 0-> 1 transitions, then I'd find the old value in memory. It looks as if they simply use the "check if programming worked" hardware to forbid the "illegal" transactions. This would mean that it might be possible to reprogram a few times as opposed to what the datasheet says...

Does anybody know the ECC code they use? (I'm guessing they would REALLY like it if 0xffffffffffffffff has ECC 0xff and that 0x0 has ECC 0x0. Not sure if that's possible).

Are any error bits in FLASH->SR set when the failure happens (after erase or program)?

Is STRT still set in CR when you clear the PER bit? RM says it clears on transition of BSY1 to 0, but maybe it is delayed a (peripheral) cycle or 2? Test with FLASH->CR = 0 instead. (A reach, but maybe it doesn't like a non-zero page number without the PER bit set).


Regarding the flash ECC, it seems the chip handles a blank word different from programmed with 0xffffffffffffffff. This likely means the ECC doesn't need to equal 0xff for an all ones set bit. See the errata sheet ES0486, section 2.2.5:

I do recall some chip (maybe an STM32) that had flash ECC and allowed multiple programs. It just disabled ECC for that flash word on the second program.