xiaoxiang781216
commented
1 year ago @michi-jung could you @zhutouwangzha ?
Closed zhutouwangzha closed 1 year ago
xiaoxiang781216
commented
1 year ago @michi-jung could you @zhutouwangzha ?
zhutouwangzha
commented
1 year ago @michi-jung could you @zhutouwangzha ?
Hello!When i only open Binary Loader Debug and informational output in the nuttx debug, a new error message appears:
ABCDF
stm32l5_nmi: PANIC!!! NMI received
_assert: error file:chip/stm32l5_irq.c line:128
_assert: Current Version: NuttX 0.0.0 0 May 12 2023 13:15:41 arm
_assert: Assertion failed panic: at file: chip/stm32l5_irq.c:128 task: 0x90002315
up_dump_register: R0: 9000164d R1: 00000004 R2: 20001888 R3: e000ed04
up_dump_register: R4: 80000000 R5: 90021313 R6: 900005f4 FP: 900005f4
up_dump_register: R8: 900005f4 SB: 900005f4 SL: 200018a4 R11: 20001888
up_dump_register: IP: 900005f4 SP: 20001950 LR: 9000165f PC: 900018b8
up_dump_register: xPSR: 81000200 PRIMASK: 00000000 CONTROL: 00000000
up_dump_register: EXC_RETURN: ffffffa8
dump_stack: IRQ Stack:
dump_stack: sp: 0x20000a08
dump_stack: base: 0x20000368
dump_stack: size: 00002048
stack_dump: 0x20000a00: 00000800 00000001 00000000 20000ba0 900018b8 20000a08 00010000 9000a123
stack_dump: 0x20000a20: 90001fb5 900005f4 900005f4 9001fe91 900278a4 00000080 90002315 20000acd
stack_dump: 0x20000a40: 00000000 9002789c 00000080 900278a4 7474754e 90000058 9002124b 900221f7
stack_dump: 0x20000a60: 00000000 200000a0 20000a80 00000000 9000c93b 9000c8ff 9002124b 9002fe00
stack_dump: 0x20000a80: 20000a98 302e3000 0000302e 20000adc 90027880 00000003 20307880 2079614d
stack_dump: 0x20000aa0: 32203231 20333230 313a3331 31343a35 00000000 00000000 00000000 9000c93b
stack_dump: 0x20000ac0: 90001fb5 9000c8ff 00000000 6d726108 90027800 00000003 00000000 20000b08
stack_dump: 0x20000ae0: 90001911 20000ba0 00000000 01000003 9000209b 9000a123 00000000 9002789c
stack_dump: 0x20000b00: 00000080 900278a4 90027948 9000191b 00000000 00000000 2000187c 00000002
stack_dump: 0x20000b20: 00000003 00000000 90002247 9000293b 2000187c 00000002 90002077 00000002
stack_dump: 0x20000b40: 00000000 900018e9 80000000 9000209b 00000000 00000002 00000000 80000000
dump_stack: User Stack:
dump_stack: sp: 0x20001950
dump_stack: base: 0x2000188c
dump_stack: size: 00001000
stack_dump: 0x20001940: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef 00000062 deadbeef
stack_dump: 0x20001960: deadbeef deadbeef 90025ff9 90026109 90021313 00000062 2000015c deadbeef
stack_dump: 0x20001980: 90022a25 90026109 90025ff9 00000012 9002f788 00000000 00000000 deadbeef
stack_dump: 0x200019a0: 90022a25 9000b989 90026109 00000012 9002f788 deadbeef 9000bc45 9000b989
stack_dump: 0x200019c0: 90022a25 deadbeef 00000012 9002f788 20001bac deadbeef 20001bac deadbeef
stack_dump: 0x200019e0: 9000bc45 9000bf93 9000b989 9002f732 00000000 00000000 20001bac deadbeef
stack_dump: 0x20001a00: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
stack_dump: 0x20001a20: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
stack_dump: 0x20001a40: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef 00000012 deadbeef
stack_dump: 0x20001a60: 00000012 9002f788 00000000 00000000 73ad0000 deadbeef 9000bc45 9000bf93
stack_dump: 0x20001a80: 9000bf93 20001c18 deadbeef deadbeef 20001c14 9002f730 20001bac deadbeef
stack_dump: 0x20001aa0: 00000000 9000bf93 9000bc45 9002fe03 00000000 00000000 20001bac deadbeef
stack_dump: 0x20001ac0: 20001c14 deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
stack_dump: 0x20001ae0: deadbeef 20001ba4 deadbeef 20001ba4 00000000 deadbeef deadbeef deadbeef
stack_dump: 0x20001b00: deadbeef deadbeef 00adbeef deadbeef 90017cd3 900043cb 00000000 deadbeef
stack_dump: 0x20001b20: 00001c78 00000000 00000000 00000000 56000200 deadbeef 900221f7 9002124b
stack_dump: 0x20001b40: 9000bf93 20001b90 00001c78 00000000 20001b8c 9002fe00 20001bac 00000001
stack_dump: 0x20001b60: 9000c93b 9002124b 900221f7 00000001 20001bac 20001b8c 90002a99 9000c93b
stack_dump: 0x20001b80: 9000c8ff 9002124b 9002fe00 20001ba4 20001bac 9000de71 20001be8 9002f730
stack_dump: 0x20001ba0: 00000006 9002f730 20001be8 00000000 9002294d 900229cd 9000c67d 00000065
stack_dump: 0x20001bc0: 9000d339 200025f8 9000c93b 9001e7c1 9000c8ff 9000cf47 20001c14 9002f730
stack_dump: 0x20001be0: 00000006 20002778 20001c14 9001e8c7 9000c93b 00000188 00000006 0002da08
stack_dump: 0x20001c00: 20001c14 900005f4 9000263b 9001e8c7 9002f730 9002f788 9001e7c1 0008020c
stack_dump: 0x20001c20: 90002637 900005f4 9000263b 900005f4 9001e7c1 00000008 20002778 900005f4
stack_dump: 0x20001c40: 9000263b 0002e38c 20001c74 20000ba0 20000b6c 00000000 00000001 900005f4
show_tasks: PID GROUP PRI POLICY TYPE NPX STATE EVENT SIGMASK STACKBASE STACKSIZE USED FILLED COMMAND
show_tasks: ---- --- --- -------- ------- --- ------- ---------- -------- 0x20000368 2048 2048 100.0%! irq
dump_task: 0 0 0 FIFO Kthread N-- Running 0000000000000000 0x2000188c 1000 992 99.2%!
acassis
commented
1 year ago @zhutouwangzha can you use GDB with SWD (i.e with OpenOCD, JLink GDB, etc) and do some step by step debugging to reveal the root cause?
Just to make things clear, could you please show the steps you are doing?
Example:
First I'm configuring the board and compiling NuttX:
$ ./tools/configure.sh stm32l562e-dk:nsh $ make -j
Then I'm flashing it using the command ....
It will help others with same board to follow your steps.
zhutouwangzha
commented
1 year ago According to the Readme file, I followed these steps: $./tools/configure.sh stm32l562e-dk:nsh $make -j $python3 ~/compile/STM32CubeL5/Middlewares/Third_Party/mcuboot/scripts/imgtool.py sign -k ~/compile/STM32CubeL5/Middlewares/Third_Party/trustedfirmware/bl2/ext/mcuboot/root-rsa-2048_1.pem -E ~/compile/STM32CubeL5/Middlewares/Third_Party/trustedfirmware/bl2/ext/mcuboot/enc-rsa2048-pub.pem -o 0x90000400 -e little -S 0x100000 -H 0x400 --pad-header -v 1 -s auto --align 8 nuttx.bin tfm_ns_enc_sign.bin
Then follow the prompts to change the sample code in 1.3.1TF-M, and then go to the Projects/STM32L562E-DK/Applications/TFM/TFM_SBSFU_Boot/STM32CubeIDE directory and modify line 30 in TFM_UPDATE.sh,$stm32programmercli $connect -d/my_home/nuttxspace/nuttx/tfm_ns_enc_sign.bin $slot1 -v. After the modification, execute regression.sh and TFM_UPDATE.sh. But I can't debug with GDB at the moment.
michi-jung
commented
1 year ago I am currently looking into this. So at the moment these are more notes for myself, which I will update along the was.
But I can't debug with GDB at the moment
You have to set the RDP level to 0 in order to be able to use GDB. This is in TFM/TFM_SBSFU_Boot/Inc/boot_hal_cfg.h line 41.
With current Nuttx HEAD (c60dd72a2a8bace64480c73bc824daf8bb9d41a1) I get the following:
(gdb) bt
#0 SecureFault_Handler () at ../../../../../../../../Middlewares/Third_Party/trustedfirmware/secure_fw/core/arch/include/tfm_arch.h:62
#1 0xffffffac in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) x/1wx 0xe000ede4
0xe000ede4: 0x00000080This is LSERR in the SecureFault Status Register (SFSR). That's the Lazy state error flag.
After modifying TrustedFirmware-M to not use Lazy FPU register stacking I get:
#0 __stack_overflow_trap () at armv8-m/arm_stackcheck.c:82
#1 0x90006a4a in nxsem_wait (sem=0x20001c40) at semaphore/sem_wait.c:72
#2 0x90006c1a in sem_wait (sem=0x20001c40) at semaphore/sem_wait.c:303
#3 0x9000aa80 in nxmutex_lock (mutex=0x20001c40) at misc/lib_mutex.c:199
#4 0x9000db54 in mm_lock (heap=0x20001c40) at mm_heap/mm_lock.c:96
#5 0x9000e08e in mm_malloc (heap=0x20001c40, size=12) at mm_heap/mm_malloc.c:150
#6 0x9000e2a4 in mm_realloc (heap=0x20001c40, oldmem=0x0, size=4) at mm_heap/mm_realloc.c:81
#7 0x9000d7ee in realloc (oldmem=0x0, size=4) at umm_heap/umm_realloc.c:91
#8 0x90017bb0 in files_extend (list=0x20002998, row=1) at inode/fs_files.c:69
#9 0x900180be in files_duplist (plist=0x20001e28, clist=0x20002998) at inode/fs_files.c:367
#10 0x9000452c in group_setuptaskfiles (tcb=0x200028b0) at group/group_setuptaskfiles.c:76
#11 0x900048a2 in nxtask_init (tcb=0x200028b0, name=0x90027530 "nsh_main", priority=100, stack=0x0, stack_size=2048, entry=0x9000f595 <nsh_main>, argv=0x20001be4,
envp=0x200028a0) at task/task_init.c:126
#12 0x90003930 in nxtask_spawn_create (name=0x90027530 "nsh_main", priority=100, stack_addr=0x0, stack_size=2048, entry=0x9000f595 <nsh_main>, argv=0x20001be4,
envp=0x200028a0, actions=0x0) at task/task_spawn.c:104
#13 0x90003a12 in nxtask_spawn_exec (pidp=0x20001bac, name=0x90027530 "nsh_main", entry=0x9000f595 <nsh_main>, actions=0x0, attr=0x20001bd0, argv=0x20001be4, envp=0x0)
at task/task_spawn.c:224
#14 0x90003ab0 in task_spawn (name=0x90027530 "nsh_main", entry=0x9000f595 <nsh_main>, file_actions=0x0, attr=0x20001bd0, argv=0x20001be4, envp=0x0)
at task/task_spawn.c:340
#15 0x90002762 in nx_start_application () at init/nx_bringup.c:270
#16 0x900027b2 in nx_create_initthread () at init/nx_bringup.c:365
#17 0x900027e0 in nx_bringup () at init/nx_bringup.c:448
#18 0x900026ea in nx_start () at init/nx_start.c:679
#19 0x90000680 in __start () at chip/stm32l5_start.c:21After extending the idle thread's stack to 2048 byte I now get:
Breakpoint 9, exception_common () at armv8-m/arm_exception.S:297
297 msrne psp, r0 /* R0=The process stack pointer */
(gdb) stepi
305 msr primask, r3 /* Restore interrupts */
(gdb) stepi
312 bx r14 /* And return */
(gdb) info register
r0 0x200037f8 536885240
r1 0x90001fe9 -1879040023
r2 0x20003860 536885344
r3 0x0 0
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x200030a0 536883360
r11 0x0 0
r12 0x0 0
sp 0x200037f8 0x200037f8
lr 0xffffffe9 -23
pc 0x9000200a 0x9000200a <exception_common+86>
xpsr 0x41000003 1090519043
fpscr 0x0 0
primask 0x0 0
basepri 0xe0 224
faultmask 0x0 0
control 0x0 0
msp 0x200037f8 0x200037f8
psp 0xfffffffc 0xfffffffc
msp_ns 0x200037f8 0x200037f8
psp_ns 0xfffffffc 0xfffffffc
msp_s 0x30030800 0x30030800
psp_s 0x30030f40 0x30030f40
msplim_s 0x30030400 0x30030400
psplim_s 0x30030800 0x30030800
msplim_ns 0x0 0x0
psplim_ns 0x0 0x0
primask_s 0x0 0
basepri_s 0x0 0
faultmask_s 0x0 0
control_s 0x3 3
primask_ns 0x0 0
basepri_ns 0xe0 224
faultmask_ns 0x0 0
control_ns 0x0 0
(gdb) stepi
Breakpoint 4, SecureFault_Handler () at ../../../../../../../../Middlewares/Third_Party/trustedfirmware/secure_fw/core/arch/include/tfm_arch.h:62
62 __ASM volatile ("MOV %0, LR\n" : "=r" (result));@zhutouwangzha Can you please have a look at https://github.com/secore-ly/nuttx-upstreaming/tree/issue-9316 and let me know whether this works for you?
Note that you need to update STM32CubeL5 to version 1.5.0 and that a third patch is required as described in the updated board's README.
zhutouwangzha
commented
1 year ago @zhutouwangzha Can you please have a look at https://github.com/secore-ly/nuttx-upstreaming/tree/issue-9316 and let me know whether this works for you?
Note that you need to update STM32CubeL5 to version 1.5.0 and that a third patch is required as described in the updated board's README.
Thanks for your help, I pulled your updated NUTTX code and updated TF-M to version 1.5.0 according to the new README.txt, and it finally works. But I don't know if I'm using GDB to debug the steps correctly, my operation is as follows: $openocd -f interface/stlink-v2.cfg -f target/stm32l5x.cfg $gdb-multiarch nuttx/nuttx $(gdb)target extended-remote :3333 $(gdb)break nsh_main $(gdb)continue When the last step is executed, gdb prompts: The program is not being run.
michi-jung
commented
1 year ago Thanks for your help, I pulled your updated NUTTX code and updated TF-M to version 1.5.0 according to the new README.txt, and it finally works.
Do you mean that your board boots successfully to the NSH prompt now? I.e. is the fix good to go into a pull request?
But I don't know if I'm using GDB to debug the steps correctly
Did you set OB_RDPLEVEL0 in Projects/STM32L562E-DK/Applications/TFM/TFM_SBSFU_Boot/Inc/boot_hal_cfg.h?
You have to apply the regression.sh script, before you flash the new firmware to the device (This will reset all Option Byte settings, disable TrustZone and erase flash).
I am not running with openocd. I am using the ST-LINK_gdbserver from STM32CubeCLT like this:
$ ST-LINK_gdbserver -d -cp /opt/secore.ly/compute-secore.ly-sdk/bin
STMicroelectronics ST-LINK GDB server. Version 6.1.0
Copyright (c) 2022, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 31
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
COM frequency = 24000 kHz
Target connection mode: Default
Reading ROM table for AP 0 @0xe00fefd0
Hardware watchpoint supported by the target
ST-LINK Firmware version : V3J10M3B5S1
Device ID: 0x481
PC: 0xc0154c0
ST-LINK device status: HALT_MODE
ST-LINK detects target voltage = 3.30 V
TrustZone: Active
ST-LINK device status: HALT_MODE
ST-LINK device initialization OK
Stm32Device, pollAndNotify running...
SwvSrv state change: 0 -> 1
Waiting for connection on port 61235...
Waiting for debugger connection...
Waiting for connection on port 61234...$ arm-nuttx-eabi-gdb
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-nuttx-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target remote :61234
Remote debugging using :61234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0c0154c0 in ?? ()
(gdb) symbol-file nuttx_user.elf
Reading symbols from nuttx_user.elf...
(gdb) break nsh_main
Breakpoint 1 at 0x818073c: file nsh_main.c, line 57.
(gdb) monitor reset
STM32 Successfully completed reset operation (System reset)
(gdb) continue
Continuing.
Breakpoint 1, nsh_main (argc=1, argv=0x200d0c18) at nsh_main.c:57
57 sched_getparam(0, ¶m);
(gdb)Yes, the NSH prompt now boots successfully. Thanks for your help, I'll look into GDB debugging myself later.
Nuttx operating system with stm32l562 board, compile the bin file of the board, and then according to the board directory, readme.txt in the operation through the TFM load the bin run, will give the following secure fault problem: [Sec Thread] Secure image initializing! ABCDF [Sec Handler] Oops... Secure fault!!! You're not going anywhere! [INF] Starting bootloader [INF] Checking BL2 NV area [INF] Checking BL2 NV area header [INF] Checking BL2 NV Counter consistency [INF] Consistent BL2 NV Counter 3 = 0x1000000 [INF] Consistent BL2 NV Counter 4 = 0x1000000 [INF] Swap type: none [INF] Swap type: none [INF] verify counter 0 1000000 1000000 [INF] counter 0 : ok [INF] verify sig key id 0 [INF] signature OK [INF] verify counter 1 1000000 1000000 [INF] counter 1 : ok [INF] verify sig key id 1 [INF] signature OK [INF] Bootloader chainload address offset: 0x17000 [INF] Jumping to the first image slot set to BL2 SHARED DATA2XX_HUKCUSTOMIZATION [INF] Code c002900 c011bfe [INF] hash TFM_SBSFU_Boot 12f2c685 .. 57deacd1 [INF] otfdec key b8, c0, 35, 4f, 78, 9e, e4, 62, [INF] otfdec key 37, 7a, f0, 8, 51, 96, 70, 2b I have completely followed the steps of readme.txt, but there is still this problem, I would like to ask anyone who has encountered this problem, or how to find the author who created the board code, thank you.