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

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

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

Hi Patrick.

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

Thank you for support.