[BUG] Hard fault in irq on raspberrypi-pico-2:nsh since 0e1b432dd

[ids1024]

Description / Steps to reproduce the issue

(I'm testing on an Adafruit Feather RP2350, so the LED is on a different pin, the flash is larger, etc., but I don't think that's relevant here.)

NuttX doesn't seem to work as expected. Connecting with gdb using the Pi Debug Probe, I see it's in the hard fault handler:

#0  up_mdelay (milliseconds=milliseconds@entry=250) at common/arm_mdelay.c:53
#1  0x10000f6a in reset_board () at misc/assert.c:811
#2  0x10000f9c in _assert (filename=filename@entry=0x0, linenum=linenum@entry=0, msg=msg@entry=0x1001878c "panic", regs=<optimized out>) at misc/assert.c:910
#3  0x100008a4 in arm_hardfault (irq=<optimized out>, context=<optimized out>, arg=<optimized out>) at armv8-m/arm_hardfault.c:147
#4  0x100009e2 in arm_doirq (irq=3, regs=0x20003580) at armv8-m/arm_doirq.c:111
#5  0x10000934 in exception_common () at armv8-m/arm_exception.S:218
#6  0x100013b6 in sched_unlock () at sched/sched_unlock.c:242
#7  0x10000cb8 in nx_start () at init/nx_start.c:770
#8  0x10000168 in __start () at chip/rp23xx_start.c:173

Bisecting, this seems to start with 0e1b432. Using the previous commit, or reverting that commit on master, prevents this, and it's able to run the nsh task.

That commit removed the code in arch/arm/src/armv8-m/arm_hardfault.c that forwarded to arm_svcall if a hard fault was triggered by svc 0. That may be correct, but I guess something needs to be changed to make sure a hard fault doesn't happen here.

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Debian Sid

NuttX Version

master (5f4a15b)

Issue Architecture

[Arch: arm]

Issue Area

[Area: Board support]

Verification

• I have verified before submitting the report.

[ids1024]

For some reason I'm also not able to see the serial console unless I reset the board with the openocd reset command. (It doesn't work immediately on plugging in, or pressing the reset button.) Not sure how to debug that since gdb also doesn't provide a trace until I reset that way.

That's a separate issue though.

[xiaoxiang781216]

@hujun260 will look at the hardfault issue.

[hujun260]

@ids1024
Did your compiled program use external code, or is all the code from NuttX?

[ids1024]

I see this behavior with just the default raspberrypi-pico-2:nsh configuration, without any modification to the config or code, on the latest commits of nuttx and nuttx-apps.

[jasonbu]

looks like missing SVC call priority configuration in RP2350, compare with nrf53.

[ids1024]

Ah yeah, makes sense to compare a different chip using the Cortex-M33.

That does seem to be the issue. coping nrf53_prioritize_syscall and the nrf53_prioritize_syscall(NVIC_SYSH_SVCALL_PRIORITY); call to rp23xx_irq.c seems to work.

[ids1024]

Looks like the issue with resets is fixed by changing the xosc startup delay. (raspberrypi/pico-sdk#2136). Probably an issue on the feather-rp2040 too (at least with some units).

With that nsh works after picotool reboot, the reset button, or power on reset. usbnsh doesn't work after using the reset button or on power on still, but the usb support on rp2350 is a little inconsistent in general (this was noted on the original PR.)

So I guess that needs some kind of configuration so the specific rp2040/rp23xx board can specific a delay multiplier, like in pico-sdk.