cancel
Showing results for 
Search instead for 
Did you mean: 

Hello. We are trying to reset MCU from within MCU by asserting SYSRESETREQ it in Cortex M4 AIRCR register (by calling NVIC_SystemReset). After that the MCU halts and FW is not running.

dimax
Senior

If we emulate the MCU watchdog reset on STM32MP1 it works fine. MCU is got restarted and runs after that.

SYSRESETREQ assertion (by calling NVIC_SystemReset) works fine with dedicated M4 processor.

We wander what can be a problem on STM32MP1 ?

1 ACCEPTED SOLUTION

Accepted Solutions
dimax
Senior

Hi Patrick.

Yes we have validated it and indeed things work as described.

Thank you for support.

View solution in original post

10 REPLIES 10
AntonioST
ST Employee

Maybe related to the RCC register RCC_MP_GCR ?

If the bit BOOT_MCU is zero, the M4 will not boot after a reset

dimax
Senior

Hi,

Yes it helped. Thanks.

But as usual your manual is wrong and incomplete. It states the WWDG1 reset is hold by the BOOT_MCU=0, but it does not.

0690X00000AsCNoQAN.png

AntonioST
ST Employee

I expect you have Linux running on the Cortex-A7.

When there is a watchdog reset on Cortex-M4 side, the watchdog also sends an interrupt to Cortex-A7 to inform it that the FW has crashed.

The Linux remoteproc framework receives the interrupt and has to handle it. The behavior depends on "/sys/kernel/debug/remoteproc/remoteproc0/recovery"

If the recovery is enabled it will restart the FW on Cortex-M4

You can change the behavior with the command

echo disabled > /sys/kernel/debug/remoteproc/remoteproc0/recovery

PatrickF
ST Employee

I want to highlight that product Reference Manual focus on HW behavior and it does not prejudge any Linux (or more generally SW) capabilities.

Although in that case the product documentation is accurate, thank you to be forgiving any errors in documentation. We try to provide as much accurate information as possible, but some mistakes are always possible, and we are thankful when somebody catch it.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
dimax
Senior

Hi Patrick.

Yes we have validated it and indeed things work as described.

Thank you for support.

@AntonioST​ What is the proper way to set BOOT_MCU to 1? Can you do it from Linux?

@CC​ 

OpenSTLinux uses the standard "remoteproc" Linux framework to load a firmware to the M4 and run it in execution.

The M4 is used as a coprocessor of the Linux system.

You can find some example on how to run the firmware on M4 at this link

https://wiki.st.com/stm32mpu/wiki/STM32CubeMP1_Package#How_to_run_the_examples

The communication between Linux and M4 is usually done through the standard "rpmsg" Linux framework. You can ignore it if the M4 does not need to communicate with Linux.

CC
Associate II

@AntonioST​  I need the M4 to reset when I call NVIC_SystemReset. I don't know how to set the RCC_MP_GCR BOOT_MCU bit from the Linux side of things, and the manual says it cannot be set by the MCU, so how do I set it? I am not seeing anything in that article that explains how to do that, but I could be missing it. Any advice?

Linux is supposed to be the master of the M4, so it's Linux that has to restart the M4.

The easier way I can imagine to let M4 trigger a self-reset is that M4 enables the watchdog and does not refresh it. The watchdog will reset the M4 and send an interrupt to Linux. If the "recovery" flag explained below is set, Linux will restart the M4 firmware.

You can find an example of using the M4's watchdog here

https://github.com/STMicroelectronics/STM32CubeMP1/tree/master/Projects/STM32MP157C-DK2/Examples/WWDG/WWDG_Example

Just for my curiosity, what is the use case that requires M4 to reset itself?