On Thu, Mar 16, 2017 at 10:23 AM, Alan Graves <[email protected]> wrote:
> > Perhaps there is already a mechanism in MyNewt to persist system > parameters other than a full blown Flash File System? > Config package (in sys/config) can use FCB as its data store (in fs/fcb), which is pretty much what you describe. -----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. > >>>>>> > >>>>> > >>>> > >> > >> > >
