For FCB option: You could add a callback to FCB backend for logging, which would call you when it’s ready to erase a sector. Maybe call it for every entry, and then in the end when it’s finished with erase.
In this callback you could then decide whether you want to keep that log entry, or toss it. If you want to keep it, you’d write it back once erase has taken place (and there is more space available). Of course, you should toss some things away. > On May 18, 2016, at 12:39 PM, Vipul Rahane <[email protected]> wrote: > > 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
