Hello, I have a rough design of the reboot log ready along with the code. It consists of logging the timestamp, reboot count, image version and reason.
Possible reasons: Soft reboot: Reboot issued by the developer/user Hard reboot: Reboot caused by loss in battery power, pulling off the plug, etc. Basically any reboot caused by an unknown reason. Gen core: Reboot caused by core generated either by an assert or a core generate command manually by a developer/user(Future use) Storage mechanism: Current: Flash using fcb backend Advantages: - Has an interface already, so easy to implement Disadvantages: - The entire sector of the flash needs to be erased when it gets full which would clear the reboot log. - Different MCUs have different sector sizes which might/might not be available for use. Eg: Depending on the availability reserving 64k in the flash map for the system log itself sounds like a waste of flash space. - We cannot break the flash space into smaller chunks to be used by the fcb. - The flash sectors that would be used would have to be specified for each BSP(Hard coded). Possible solutions: 1. Flash using config backend Advantages: - Has an interface as well, somewhat easy. - Entire sector would not be needed for reserving for reboot/system log. Disadvantages or work needed: - New functions supporting reading old config entries(15-20) and keeping them around. - A bit unusual to think about (hacky). 2. Fcb could somehow be more intelligent about underlying sectors. Advantages: - Not too hacky and could be used by anyone who uses fcb. Disadvantages: - The way fcb is currently implemented, it takes care of very specific functions at a sector level and hence supports read/write/erase at a sector level. If we add this, it would do something more than just these basic functions. I am open for both ideas. Any more ideas are welcome. Regards, Vipul Rahane
