How to make LittleFS_Program NOT persistent across programming cycles on MicroMod

Blackaddr

Well-known member
My Teensy MicroMod took a bootloader update from using the latest Teensyduino and now some functionality I was relying on seems to no longer be the case.

I have some data I need stored across reboots, but I DO need it wiped when reprogramming the board. That seemed to be the behavior with the Teensyduino 1.54 bootloader but now after building something with 1.56 it looks like the LittleFS_Program area is no longer getting wiped, it's preserved, and this also is stated in the 1.56 release notes if I'm interpreting correctly.

Okay, so anybody have some ideas now on how I can detect if this is the first boot after programming? My tricking of detecting if the LittleFS_Program area was clean or dirty seems to be off the table. It would be nice if this was an option I could pass to the bootloader from teensy_loader_cli tool.
 
A few different ideas:

a) if the LittleFS storage is big enough, such that it starts off in certain areas of storage it will not be preserved. I don't remember what the starting point is on MMOD that is preserved....

b) Have a revision number, stored somewhere either in EEPROM or littleFS and if it does not match your current one, it clears itself and updates the revision stored...

c) like b) but use something like the date/time the program was compiled... Like some of my debug prints out at startup:
DBGSerial.println("\n" __FILE__ " " __DATE__ " " __TIME__);

would need to convert to string or the like...
 
You could compute a CRC of the flash memory (maybe using Frank's FastCRC library) check it against a copy stored it in eeprom. If it doesn't match, call the LittleFS format() function, and write the new CRC.
 
Thanks everyone for the great suggestions. In the end I went with a variation of KurtE's third suggestion. I'm using the __TIME__ macro which returns an 8 character timestamp as an identifier which is compared to one stored in the last 8 bytes of the simulated EEPROM. The timestamp is not guarenteed to be as unique as a checksum, but in a practical sense it will be sufficient.

Thanks for the quick replies, tool. I'm already behind schedule getting to this product ready for NAMM in June and been working way too long hours and my brain is melting at this point.
 
Nice idea KurtE like:
Code:
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  char szTD[128];
[B]  sprintf(szTD, "\n%s%s%s", __FILE__,__DATE__,__TIME__);
  Serial.println(szTD);
[/B]

Gives:
Code:
C:\T_Drive\tCode\Interrupts\CountTrack\CountTrack.ino Mar 12 2022 13:01:34

[B]C:\T_Drive\tCode\Interrupts\CountTrack\CountTrack.inoMar 12 202213:01:34[/B]

Could just do the CRC (to store and compare) on that "char szTD" to catch any change in File, Date, or Time.
Example in : {local install}\hardware\teensy\avr\libraries\FastCRC\examples\FastCRC_CRC32\FastCRC_CRC32.ino
 
Back
Top