[BUG] reboot (BOARDIOC_RESET) fails on rp2040 with SMP enabled

[sumpfralle]

Description / Steps to reproduce the issue

I am using an rp2040 board (based on w5500-evb-pico) with SMP enabled.

When trying to reboot the system, the reset-initiating thread starts to consume most of the CPU time (reducing the usual 50% share of the CPU's idle task). Probably it is waiting for the reboot to happen. The reboot never happens.

Both of the following methods of triggering a reset show the same behavior:

• run reboot in the nuttx shell
• run boardctl(BOARDIOC_RESET, 0); in my code

I can work around the issue in two ways:

• A) send a second reboot request (e.g. open another nsh session via telnet and execute "reboot")
• B) disable SMP

The above behavior feels like only one of the CPUs is told to reboot. The other CPU continues to run until someone else tells her to reboot, too.

Thanks for your time and thoughts!

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Debian Trixie

NuttX Version

master ( b0342c87eec)

Issue Architecture

[Arch: arm]

Issue Area

[Area: Board support]

Host information

host-info.txt

Verification

• [x] I have verified before submitting the report.

[acassis]

@sumpfralle could you please confirm w5500-evb-pico is working for Ethernet communication before trying to run this reset command? My friend @JorgeGzm is trying to connect a w5500 on this pico board and it is not working.

[sumpfralle]

@sumpfralle could you please confirm w5500-evb-pico is working for Ethernet communication before trying to run this reset command?

Yes, here the current state of the repository is working fine:

• nsh via usb (cdcacm)
• nsh via telnet
• custom network services

nuttx is working great and I did not notice any problems with nuttx code changes over the last twelve months.

[sumpfralle]

Regarding the original issue:

• up_systemreset fails, if executed in CPU 1
• up_systemreset works, if executed in CPU 0

I took a look at the rp24040 datasheet. The relevant register description does not mention any condition regarding the executing CPU:

Writing 1 to this bit causes the SYSRESETREQ signal to the outer system to be asserted to request a reset. The intention is to force a large system reset of all major components except for debug. The C_HALT bit in the DHCSR is cleared as a result of the system reset requested. The debugger does not lose contact with the device.

The function in pico-sdk also looks identical. Just the initial DSB is missing in NuttX - but id does not make a difference.

/**
  \brief   System Reset
  \details Initiates a system reset request to reset the MCU.
 */
__NO_RETURN __STATIC_INLINE void __NVIC_SystemReset(void)
{
  __DSB();                       /* Ensure all outstanding memory accesses included buffered write are completed before reset */
  SCB->AIRCR  = ((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) | SCB_AIRCR_SYSRESETREQ_Msk);
  __DSB();                       /* Ensure completion of memory access */

  for(;;)                        /* wait until reset */
  {
    __NOP();
  }
}

My current workaround for rebooting is to start a new thread (limited to CPU 0) and call boardctl(BOARDIOC_RESET, 0); from there. But this feels weird to me.