sumpfralle commented on issue #16480:
URL: https://github.com/apache/nuttx/issues/16480#issuecomment-3188209971
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.
```c
/**
\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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
