cancel
Showing results for 
Search instead for 
Did you mean: 

software reset problem if reset from a task

huiyan
Associate
Posted on January 21, 2014 at 14:29

I use NVIC_SystemReset() in order to reset the system.  I am using STM32F103 in my application and RTX rtos. The problem is that if  called NVIC_SystemReset() before the RTOS started, the software reset worked. If called within a task ( even the first task), will get a Hard Fault. Anything I should do before calling NVIC_SystemReset()? or it can't be used in RTOS?

Thank you very much for your help.

5 REPLIES 5
Posted on January 21, 2014 at 15:26

Your User code no doubt operates in an unprivileged mode and thus can't do that. Put the reset code in system call (SVC)

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Jono Makepeace
Associate II

I have a similar problem. I am running Keil RTX in privileged mode. When calling NVIC_SystemReset from a thread (PSP in use), the MCU resets into​ the bootloader, however the MSP and PSP are not reset and it's as if the bootloader is running out of the calling thread.

I've worked out that I can manually modify the control register to fix the issue by manually selecting to run from MSP before calling NVIC_SystemReset, which works. I am wondering what else does not get adequately reset by calling NVIC_SystemReset. We are reverting back to using the watchdog to cause the reset.

It is a problem for us as we sometimes have unexpected behaviour at startup, such as RTX not starting threads, stack overflow and sometimes hard faults.

What is the correct way to do as system reset when running with RTX?​

>>It is a problem for us as we sometimes have unexpected behaviour at startup, such as RTX not starting threads, stack overflow and sometimes hard faults.

That sounds likes an entirely different problem you should perhaps root cause before proceeding.

Reset on ARM/STM32 platforms can be an issue if you drive NRST high externally with a push-pull driver. Most STM32 platforms also expect BOOT0 to be pulled low.

NVIC_SystemReset() isn't going to reset external peripherals like I2C ones, or other things not connected to NRST, or supporting async resets. The pulse width generated by the STM32 should be adequate to reset everything internally.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Jono Makepeace
Associate II

Thanks for your response Clive.

We have BOOT0 pull low at all times.

NRST is only ever driven high by the external programmer and is otherwise referenced to ground via a 100nF cap.

We do not expect any of the external peripherals to require resets. We need to reset in the case of critical error conditions to do with the program - external device error conditions are well handled.

We are looking in to the root cause of the problem, and at this stage we've singled it out to an upgrade we did of our Keil project to the new format, compiler upgrade and RTX upgrade, but the fact that NVIC_SystemReset is putting us into an undefined state from startup is definitely going to need to be solved before we can look further into the root cause.

An observation of state of the registers after clock stabilization after an NVIC_SystemReset call from an RTX thread indicates that NVIC_SystemReset is not doing as expected on it's own and requires manual resetting of the stack pointer state (at least) - so it's a lead. Forcing a watchdog reset does reset stack pointer state, but we preferably don't want to use the watchdog + deadloop as a solution (we don't want to rely on that the watchdog being enabled and configured properly).

Which is why I am asking what is the correct way to do a self system reset of an STM32 chip when running an RTOS that may be using PSP in privileged mode, because I have evidence that SYSRESETREQ does not do the trick unfortunately, and I'm also wondering what else it doesn't reset.

Like I suggested 4+ years ago, put it in an SVC Handler.

The only thing in an undefined state at reset is the RAM. I don't have any recollection of an issue with a processor reset causing the processor to come up in some odd state. Driving NRST high can cause it to NOT reset and continue. Try using while(1) NVIC_SystemReset(); or looping while sending characters to a USART.

Be aware that in Keil, the SystemInit() function is called before memory is initialized, this can be an issue if you have global statics in this routine, or anything it calls/touches. Watch also for NOINIT sections in the scatter file.

Do the testing without a debugger attached. Instrument the code execution paths so you can follow via a USART or GPIO signalling. Have code in Reset_Handler that fills ALL RAM with 0xCDCDCDCD or 0xE5E5E5E5 patterns to break any fragile code, and expose latent errors.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..