This does sound the way I was thinking about it. I do have a concern with this approach though: since the log entry gets stored in the flash, we need a way to mark an entry which increases the amount of space needed on the flash.
As an alternative, I was thinking in the direction of keeping most recent N number of entries. All this would need is a marker/flag in the log structure and nothing on the flash. Of-course, there would still be a callback to do that. Regards, Vipul Rahane > On May 19, 2016, at 11:50 AM, marko kiiskila <[email protected]> wrote: > > 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 >
