See the following post (in this same thread) for firmware that fixes this issue:
https://forum.librepilot.org/index.php?topic=4912.msg32933#msg32933New user
eighttram sent me a CC3D that exhibited the problem and I tracked it down. I will be posting a few fixed firmwares for popular versions of LP in this thread.
I have attached the one changed source file if you want to build it yourself.
flight/pios/inc/pios_flash_jedec_catalog.h
I have attached a picture of a CC3D with a Winbond flash chip and with an ST flash chip. The flash chip is the one of the 3 big chips that only has 8 legs. Note that the ST chip ST insignia is kind of "reverse video".
In the next post I intend to post patched CC3D firmwares for at least 16.09 and some recent nexts. You can use this thread to request patched firmwares for various LP versions if you need something different. It only takes 5 minutes to make another version.
With Winbond flash ram chips the Firmware page "FlightTime" starts counting at about the number 6 after pressing OK to Erase Settings. The more typical ST flash ram chips start at about 23. In several threads it was discussed that 3 seconds was bad and 23 seconds was good. It looks like the Winbond chips are a lot faster to erase. Note that these numbers do not affect flight at all. It just takes a little longer to erase an ST chip.
Technical notes (simplified):
The CC3D settings are stored in a flash ram chip. Flash ram chips can tell you their brand and model. This is important because different ones are organized a little differently. This "bad" CC3D has a brand of chip that was coded for, but was not the original production chip brand, so it had not been tested as much. LP is coded to use 64k sectors in the flash chip. The sector_erase command was coded as 0x20 for this brand/model of flash chip. 0x20 is a 4k sector erase command. The correct command is 0xD8, which is a 64k sector erase command. When erasing, the code would iterate through all the 64k sectors, but the 4k erase command would only erase the first 4k of each sector. This left garbage behind, and the code would refuse to use what looked like bad flash memory with garbage in it when it should be clean.
Technical notes (full):
flashfs_m25p_cfg hard codes CC3D to use 64k erase sectors (the erase size), 64k arenas (like a disk partition), and 256 byte slots (like a disk file). The code iterates through all the sectors in an arena (there is only one) and sends the erase sector command. The wrong erase sector command was used, so only the first 4k (16 slots) of each arena was erased. Later, when checking the validity of the arena, like before mounting it, the code would find erased slots, then used slots, then more erased slots, which should not happen and would violate code assumptions. It would fail the mount, erase the whole thing and retry, and the retry would fail too. Once the correct erase sector command is coded, it self heals and mounts correctly at the next boot, with no further code changes needed.