Be aware: 0x00 or 0xFF thats the question?

[Kjelt]

Just want to share a work related incident, maybe someone else can benefit. I have written in the past a library that on first bootup had to check if some part of the flash memory was empty (factory programming  writes some stuff but sometimes this failed).
This library worked on STM32F 32 bits micros which had 0xFF value when erased.
For five years this went flawlessly on more then thirty products.
Last month error reports were dropping in , the library was at fault.
I did a checkup and some of the new st microcontroller from the low power series have the value 0x00 when erased.

It does present me with a question, is the value after erasure flash technology based or can the manufacturer choose this? Any other values then 0x00 and 0xFF known to exist after erasure?

[asgard20032]

Any other values then 0x00 and 0xFF known to exist after erasure?

Yes, there is 0x0000 and 0xFFFF, but also 0x00000000 and 0xFFFFFFFF...

[Kjelt]

  you know what I mean 

[AndyC_772]

It's fairly common to write a specific value to a known location as part of the programming process, then to test for that instead.

You can be fairly sure that the memory isn't going to initialise to (say) 0xDEADBEEF at every location. So, in your start up code, check for that unique signature, and if it's not there, program the default configuration.

Flash technology may always erase to the same state, but there's no rule that says the data actually stored can't be inverted, if it's convenient for whatever reason. Erasing to 0xff is usual, but 0 doesn't surprise me. In theory there's no reason why it couldn't erase to any other pattern (ie. some bits inverted, others not), though it's usual to have a rule which says bits can always be cleared (or set) without the need to erase a sector first, and that wouldn't be possible if the bits weren't all physically stored with the same sense.

As an aside: I was caught out a while ago writing a boot loader for a PIC, which has error corrected Flash memory. On these devices you cannot write any Flash location more than once without an erase, because there are hidden check bits that get calculated and stored on each write. If you write to the same location twice, the check bits end up as the logical AND of the two possible values, and so they don't match the data that ends up written to the Flash.

The result? Write a block of data, reserve a few bytes with 0xff, then go back and fill in a checksum within the same sector, and the CPU will crash when it tries to read the checksum to verify it. Took a while to find that one, given that there's absolutely nothing whatsoever wrong with the code doing the read.

[helius]

The logical interpretation of physical states is always in some sense a convention. Floating-gate memory cells are programmed by injecting a charge that remains in the floating gate, and erased by clearing away any charge. The industry standard is to represent the charged state as '0' and the cleared state as '1', but this is just a convention. In MLC devices there are multiple levels of charging to store more than 1 bit per cell, so the cleared state could be '3' with 0-2 being charged states (for a 2-bit cell). The more bits stored per cell, the more possibilities for assigning logical values to charge states. Another possibility is that an error-correction code may be applied to the values in the actual cells, so that sequences of bits stored into the memory undergo coding gain and become  different, longer bit sequences when actually stored into the flash. This would frustrate the practice of overwriting flash bits without first erasing them.

[dgtl]

I'm using a magic value and CRC to detect missing factory information. If the block is unprogrammed, the magic values is invalid and CRC does not match and the device boots into factory init and test mode. The factory data block (serial number, MAC addresses, calibration etc) is in uc internal flash, so if for some reason the device needs to be fully erased (unlock) and re-flashed (during the manufacturing and repair procedures it might be), the factory block is erased with the fw and the init&test system tools have to be re-run to re-program it.
If larger factory data is needed, this can be in external flash, that will be erased and re-programmed by the init&test system. But always the unique information is in uc flash to avoid users tampering with it and to guarantee the entry to the factory test code after erase and re-flash.

[Kjelt]

In our case it is a huge block of freshly generated random data so there is no way of knowing what it is.