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