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. >>>> >>> >>
