software reset problem if reset from a task

[huiyan]

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.

[Tesla DeLorean]

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)

[Jono Makepeace]

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?​

[Tesla DeLorean]

>>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.

[Jono Makepeace]

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.

[Tesla DeLorean]

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.