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]

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 ?

[AntonioST]

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]

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.

[AntonioST]

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]

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.

[dimax · Accepted solution]

Hi Patrick.

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

Thank you for support.

[CC]

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

[AntonioST]

@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]

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

[AntonioST]

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?