vTaskNotify stops system reset


I’m using STM32f767zi with FreeRTOS kernel. I have two task:

1- one of them are triggered by task notifications from interrupt every 100ms and receives some data through TCP.
2- the other task is taking some requests from PC.

Now, if task-2 do system reset using “NVIC_SystemReset” upon request from PC, system reset fails and every things hangs. When I run debugger and halt it stops at “vPortRaiseBASEPRI”. In disassembly that is a few lines after “vTaskNotifyFromISR” which is the notification I used for task-1.

When I remove task notification and use just a flag in the interrupt, the system reset works fine. However, I think this way consumes the processor cycles.

I tried to disable interrupts “portDISABLE_INTERRUPT”, tasks “vTaskSuspendAll” or enter critical “taskENTER_CRITICAL” but nothing work.

I did a way around by requesting to “portDISABLE_INTERRUPT” in an independent request(so that any pended interrupt or “notification” can finish), then sending system reset in another request. This one works, however, it is not safe from user perspective because the user can (by mistake) do the system reset before disabling interrupts.

Note that when I do hardware reset (push button on board) it works fine?!

So, any idea how to solve this problem? how to reset the board by software without that issue?

I wonder how NVIC_SystemReset can fail ? I‘d say that‘s impossible.
So I guess your application hangs either a few steps right before finally invoking NVIC_SystemReset due to a different reason or reset was done and the restarted application hangs.
Do you’ve a debugger at hand to single step your reset procedure ?
Did you define some of the very helpful debug support macros like configASSERT, configCHECK_FOR_STACK_OVERFLOW including vApplicationOverflowHook, etc. ?

My guess is that the NVIC_SystemReset isn’t the equivalent of a full system reset, and perhaps the stuff that doesn’t get reset is the issue.

Also, with a bit of research, for many STM parts, NVIC_SystemReset doesn’t work with the debugger attached as they interfere with each other.

1 Like

The problem solved by simply adding some delay after disabling task-1 interrupt:


I still don’t know if this solved the root cause.

The issue is likely that NVIC_SystemReset isn’t as complete a reset as a total system reset, particularly of peripherals, so just executing it, might cause unexpected things to happen after it. You likely want to totally disable interrupts before doing it, and maybe aborting any device operations that might interfere with the the boot loader running.

1 Like

I agree with this, because reset button onboard worked fine.