Hi Peter, If you happen to know that this was working before on an older NuttX version, you could use git bisect to narrow down the breaking commit. Then the issue might be clearer.
Best, Matteo On Fri, Feb 6, 2026, 4:09 PM Peter Barada <[email protected]> wrote: > I have a STM32 Nucleo-h753zi board - and configured a build for > nucleo-743zi2:nsh (which is closest board/chip; the stm32h753zi is same > as stm32h743zi but h753zi includes crypto acceleration hardware). > > Build works, but if I boot and try 'time ls' nuttx faults: > > nsh> uname -a > NuttX 0.0.0 9ecfff0833 Feb 6 2026 15:45:28 arm nucleo-h743zi2 > nsh> time ls > /: > dev/ > > 0.00dump_assert_info: Current Version: NuttX 0.0.0 9ecfff0833 Feb 6 2026 > 15:45:28 arm > dump_assert_info: Assertion failed panic: at file: :0 task: <noname> > process: <noname> 0x800c9fd > up_dump_register: R0: 0801e624 R1: 0000000a R2: 00000050 R3: 0000000a > up_dump_register: R4: 00000001 R5: 240000e4 R6: 00000000 FP: 00000000 > up_dump_register: R8: 00000000 SB: 00000000 SL: 00000000 R11: 00000000 > up_dump_register: IP: 00000000 SP: 38000c08 LR: 080059db PC: 08005984 > up_dump_register: xPSR: 41000000 BASEPRI: 00000000 CONTROL: 00000000 > up_dump_register: EXC_RETURN: ffffffe9 > dump_stackinfo: User Stack: > dump_stackinfo: base: 0x38000518 > dump_stackinfo: size: 00002000 > dump_stackinfo: sp: 0x38000c08 > stack_dump: 0x38000be8: 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 > stack_dump: 0x38000c08: 0000000a 0801e624 0801e624 38000200 38000fac > 00000000 0801e624 080172c1 > stack_dump: 0x38000c28: 00000000 0801e624 38000200 38000158 00000000 > 00000000 38000fac 0800caa1 > stack_dump: 0x38000c48: 00000000 0800cc77 0801e624 000002fc 38000500 > 00000001 00000001 38000cf0 > stack_dump: 0x38000c68: 38000cf0 00000008 38000200 00000000 00000000 > 0800ca79 38000500 00000001 > stack_dump: 0x38000c88: 00000064 38000cf0 00000064 0800ca33 38000500 > 00000001 00000064 00000000 > stack_dump: 0x38000ca8: 00000000 08009325 00000000 38000500 00000001 > 0800c9fd 00000000 080052f1 > stack_dump: 0x38000cc8: 00000000 38000500 00000000 38000158 00000001 > 00000001 00000000 00000000 > stack_dump: 0x38000ce8: 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 > dump_tasks: PID GROUP PRI POLICY TYPE NPX STATE EVENT > SIGMASK STACKBASE STACKSIZE COMMAND > dump_task: 0 0 0 FIFO Kthread - Ready > 0000000000000000 0x240018b0 1000 <noname> > dump_task: 1 1 100 RR Task - Running > 0000000000000000 0x38000518 2000 <noname> ��]���& > > Wondering if anyone has run across this before? Backtrace shows: > > Program received signal SIGTRAP, Trace/breakpoint trap. > exception_common () at armv7-m/arm_exception.S:127 > 127 mrs r0, ipsr /* > R0=exception number */ > where > #0 exception_common () at armv7-m/arm_exception.S:127 > #1 <signal handler called> > #2 0x08005984 in env_cmpname (pszname=0x801e624 "PS1", > peqname=0xa <error: Cannot access memory at address 0xa>) > at environ/env_findvar.c:50 > #3 0x080059da in env_findvar (group=0x38000200, pname=0x801e624 "PS1") > at environ/env_findvar.c:105 > #4 0x080172c0 in getenv (name=0x801e624 "PS1") at environ/env_getenv.c:89 > #5 0x0800caa0 in nsh_update_prompt () at nsh_prompt.c:77 > #6 0x0800cc76 in nsh_session (pstate=0x38000cf0, login=1, argc=1, > argv=0x38000500) at nsh_session.c:249 > #7 0x0800ca78 in nsh_consolemain (argc=1, argv=0x38000500) > at nsh_consolemain.c:77 > #8 0x0800ca32 in nsh_main (argc=1, argv=0x38000500) at nsh_main.c:76 > #9 0x08009324 in nxtask_startup (entrypt=0x800c9fd <nsh_main>, argc=1, > argv=0x38000500) at sched/task_startup.c:72 > #10 0x080052f0 in nxtask_start () at task/task_start.c:104 > #11 0x00000000 in ?? () > > Scratching the surface shows that env_findvar() is called with group > pointer of 0x38000200, group->tg_envp is 0x380004b8, both which are > reasonable. But *group->tg_envp is 0xA. Further if I "watch > *(int*)0x380004b8" in GDB, I see it is getting overwritten by > up_serialout() invoked from stm32_serial.c::up_send. > > Any suggestions on how I can best track this down further? > > Thanks in advance! > > -- > Peter Barada > [email protected] >
