Yes I only noticed a problem when I had something other than valid reboot_log_sector data, i.e. the first time I programmed and ran the image over top of something else. The idea of course is to retain the log across reboots so we would need to do some kind of sanity check on the log data prior to erasing the sector if the system is to automatically erase the Flash.
One possibility might be for the system to maintain a parameter byte in Flash that is only cleared to 00h after the reboot log is first erased. This would allow first time reboots to do things. I always like to refer to this as a 'factory fresh' state for the system. It allows the system to revert any non-volatile parameter settings back to a known state. It would be easy if the 'factory fresh' flag byte and other parameters were stored in an actual EEPROM. In the past I've actually gone to the effort of emulating an EEPROM with a 512byte size, signature field and checksum in the Flash. The 512byte block gets written in a circular fashion and thus moves around in a sector of the Flash, like a kind of mini file system. That works ok as long as you are not modifying parameters too 'often', which is typically the case for configuration parameters. Perhaps there is already a mechanism in MyNewt to persist system parameters other than a full blown Flash File System? ALan -----Original Message----- From: Vipul Rahane [mailto:[email protected]] Sent: Wednesday, March 15, 2017 11:08 PM To: [email protected] Subject: Re: slinky with REBOOT_LOG_FCB, inside log_reboot_pkg_init error Yes, that is correct. You will get an error if you don’t erase it because you have some corrupt data in that sector. If you erase the flash using opened+gdb, it should fix your issue. Another way is the way I mentioned earlier: in fcb_init() when the initialization of reboot_log fails, erase the sector. Regards, Vipul Rahane > On Mar 15, 2017, at 10:19 PM, Louie Lu <[email protected]> wrote: > > Hi Vipul, > > I encounter a problem that is, I'll need to use openocd + gdb to > manual erase the reboot log sector first, then the program will thus > run correctly. But if I didn't do it, it will get error when doing fcb_init. > > Should I fix via the way you suggest? > > Thanks, > Louie. > > 2017-03-16 12:22 GMT+08:00 Vipul Rahane <[email protected]>: > >> Hello Louie, >> >> I think erasing the the reboot_log sector while booting up is not a >> good option. This is because you might want to persist the reboot_log >> across reboots to show you when the device rebooted and how many >> times it rebooted with the reboot reason. The way I would deal with >> this is read the reboot log and if it is not valid try to erase the >> sector. Hope this answers your question. >> >> Regards, >> Vipul Rahane >>> On Mar 15, 2017, at 9:15 PM, Louie Lu <[email protected]> wrote: >>> >>> Hi Alan, >>> >>> I have a question, that when does the kernel need to erase reboot >>> log sector? If I erase the sector when booting via >>> startup_stm32f429.s, is >> this >>> correct? >>> >>> Thanks, >>> Louie. >>> >>> 2017-03-10 2:47 GMT+08:00 Alan Graves <[email protected]>: >>> >>>> Hi Louie, >>>> >>>> I have a slightly different STM chip in my port, but If you are >>>> running gdb/openocd for your debugging you should be able to do the >>>> erasing of >> the >>>> reboot log sector as follows: >>>> >>>> (gdb) mon flash banks >>>> #0 : stm32f4x.flash (stm32f2x) at 0x08000000, size 0x00100000, >>>> buswidth >> 0, >>>> chipwidth 0 >>>> #0 : stm32f4x.flash (stm32f2x) at 0x08000000, size 0x00100000, >>>> buswidth >> 0, >>>> chipwidth 0 >>>> (gdb) mon flash list >>>> {name stm32f2x base 134217728 size 1048576 bus_width 0 chip_width >> 0}{name >>>> stm32f2x base 134217728 size 1048576 bus_width 0 chip_width 0} >>>> >>>> (gdb) x/16xb 0x8004000 >>>> 0x8004000: 0xdf 0xba 0xad 0x7e 0x02 0xff 0x00 >>>> 0x00 >>>> 0x8004008: 0x2a 0xb8 0x0b 0x00 0x00 0x00 0x00 >>>> 0x00 >>>> (gdb) mon flash erase_address 0x8004000 0x4000 erased address >>>> 0x08004000 (length 16384) in 0.373558s (42.831 KiB/s) erased >>>> address 0x08004000 (length 16384) in 0.373558s (42.831 KiB/s) >>>> (gdb) x/16xb 0x8004000 >>>> 0x8004000: 0xff 0xff 0xff 0xff 0xff 0xff 0xff >>>> 0xff >>>> 0x8004008: 0xff 0xff 0xff 0xff 0xff 0xff 0xff >>>> 0xff >>>> (gdb) >>>> >>>> I hear your frustration and I too got bit by this, however I you >>>> have to expect a bit of a learning curve with embedded systems. >>>> MyNewt OS isn't different in that respect, but the guys answering >>>> questions on this dev support are very helpful and quick to >>>> respond. :) >>>> >>>> ALan >>>> >>>> -----Original Message----- >>>> From: Louie Lu [mailto:[email protected]] >>>> Sent: Thursday, March 09, 2017 10:13 AM >>>> To: [email protected] >>>> Subject: Re: slinky with REBOOT_LOG_FCB, inside log_reboot_pkg_init >> error >>>> >>>> HI all, >>>> >>>> I'm somehow confused about this, >>>> so at this moment, this is not a critical bug and MAY closed >>>> REBOOT_LOG_FCB in those apps which used this option? >>>> >>>> Also, I think apps documentation may do some improve, or add README >>>> in each app folder, to describe the expected result of the app, >>>> otherwise, user or developer may need using more time to figure out >>>> what is the app used to be. >>>> >>>> >>>> Louie. >>>> >>>> 2017-03-10 1:48 GMT+08:00 Sterling Hughes <sterling.hughes.public@gmail. >>>> com> >>>> : >>>> >>>>> I think others have run into this as well: this is a common issue. >>>>> >>>>> Minimally, I think we need to have an assert_error() that actually >>>>> describes why the assert() is occurring. People have spent a lot >>>>> of hours debugging this one, I think :) >>>>> >>>>> Sterling >>>>> >>>>> >>>>> On 9 Mar 2017, at 9:44, Alan Graves wrote: >>>>> >>>>> Hi Louie, >>>>>> >>>>>> You are running into the same issue (not really a bug) I was >>>>>> having with the new STM32F427xx port. The Flash sector that is >>>>>> used by the reboot log (circular flash buffer) needs to be erased >>>>>> initially. >>>>>> >>>>>> ALan >>>>>> >>>>>> -----Original Message----- >>>>>> From: Louie Lu [mailto:[email protected]] >>>>>> Sent: Thursday, March 09, 2017 9:17 AM >>>>>> To: [email protected] >>>>>> Subject: slinky with REBOOT_LOG_FCB, inside log_reboot_pkg_init >>>>>> error >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I'm now running slinky without REBOOT_LOG_FCB, setting in >>>>>> sysfcg.yml >> as >>>> 0. >>>>>> >>>>>> And the result from serial is like this: >>>>>> >>>>>> 17:[ts=17000ssb, mod=6 level=4] rsn:RESET_PIN, cnt:18, >>>>>> img:1.0.0.0 Slinky >>>>>> 1.0.0.0 18:[ts=18000ssb, mod=6 level=4] rsn:RESET_PIN, cnt:19, >>>>>> img:1.0.0.0 Slinky 1.0.0.0 19:[ts=19000ssb, mod=6 level=4] >>>>>> rsn:RESET_PIN, cnt:20, >>>>>> img:1.0.0.0 Slinky 1.0.0.0 >>>>>> >>>>>> And from newtmgr: >>>>>> >>>>>> ➜ stm32f429 sudo newtmgr echo -c stm32f429 hello hello ➜ >>>>>> stm32f429 sudo newtmgr image -c stm32f429 list >>>>>> Images: >>>>>> slot=0 >>>>>> version: 1.0.0 >>>>>> bootable: true >>>>>> flags: active confirmed >>>>>> hash: >>>>>> fb6ee2516c5c89fe7f0c8ebe6d390cc7ea16a5342cb55cd3d21978d98095 >>>>>> 960f >>>>>> Split status: N/A >>>>>> ➜ stm32f429 sudo newtmgr -c stm32f429 taskstats Return Code = 0 >>>>>> task pri tid runtime csw stksz stkuse last_checkin >>>>>> next_checkin >>>>>> idle 255 0 33630 33633 64 25 0 >> 0 >>>>>> main 127 1 23 47 1024 366 0 >> 0 >>>>>> task1 8 2 0 34 192 115 0 >> 0 >>>>>> task2 9 3 0 34 64 31 0 >> 0 >>>>>> >>>>>> I think this is running as it needs to be. >>>>>> >>>>>> >>>>>> But when I setting slinky with REBOOT_LOG_FCB: 1, it will >>>>>> generate this code in slinky-sysinit-app.c: >>>>>> >>>>>> /*** Stage 200 */ >>>>>> /* 200.0: sys/reboot */ >>>>>> log_reboot_pkg_init(); >>>>>> >>>>>> which cause error when running on STM32F429. >>>>>> >>>>>> Not sure why reboot_init_handler will return MAGIC number (-7), >>>>>> and what does reboot log doing. >>>>>> >>>>>> Are there any documentation or help msg for this function? >>>>>> >>>>>> Thanks, >>>>>> Louie. >>>>>> >>>>> >>>> >> >>
