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