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