2026-03-04 5:59 AM - last edited on 2026-03-04 6:23 AM by Andrew Neil
When I calling NVIC_SystemReset() in the os task, the system will enter into hard fault handler error, so I have to call NVIC_SystemReset() again in the HardFault_Handler() to reset the system, so what is the proper way to call NVIC_SystemReset() in the os task?
Solved! Go to Solution.
2026-03-04 11:39 AM - edited 2026-03-04 11:40 AM
Do your RTOS tasks run in non-privileged mode? Then of course NVIC_SystemReset() will cause a fault.
> so what is the proper way to call NVIC_SystemReset() in the os task?
Maybe, do this in SVC handler and make the task execute SVC. Or just leave it as is.
2026-03-04 6:14 AM - edited 2026-03-04 6:14 AM
NVIC_SystemReset() is one correct way to reset the chip. Calling this from a task as opposed to the main thread should not cause issues.
If a hardfault occurs, I recommend finding the root cause and solving that. STM32CubeIDE has a hard fault analyzer that could be used.
2026-03-04 6:25 AM
As @TDK said, you should find out what's causing the Hard Fault:
Debugging Cortex-M Hard Faults
2026-03-04 11:39 AM - edited 2026-03-04 11:40 AM
Do your RTOS tasks run in non-privileged mode? Then of course NVIC_SystemReset() will cause a fault.
> so what is the proper way to call NVIC_SystemReset() in the os task?
Maybe, do this in SVC handler and make the task execute SVC. Or just leave it as is.
2026-03-08 9:19 PM
Yes, you are right. The os task is running in the non-privileged mode. As the OS has taken over the SVC_Handler, I configured the OS task to run in Privileged Mode instead.
Thank you for the help.
2026-03-08 9:26 PM
The root cause of hardfault is "Precise Data Bus Error", and the BFAR register is 0xE000ED0C which is SCB->AIRCR register (the reset register).
The root cause of my problem is that I run NVIC_SystemReset() under non-privileged mode, so I change the task mode to privileged mode to solve this problem.
Thank you for your support.