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