STM32MP1 Memory Corruption during Stop mode

[tinova-11]

Hi! 

We are using the STM32MP153 with FreeRTOS on the CoPro side and OpenEmbedded/Yocto Linux on A7 side. To save power, the CStop mode is used. We go to CStop using

`

HAL_PWR_EnterSTOPMode(PWR_MAINREGULATOR_ON, PWR_STOPENTRY_WFI);

`

on the CoPro side and using

`

echo deep > /sys/power/mem_sleep

systemctl suspend

`

on Linux side.

The CoPro is waken up by a falling edge on pin PI8 via an EXTI interrupt.

The Linux also wakes up using a falling edge on pin PI8 (modified device tree).

Sometimes (approx. every 10 wakeups, but I can’t reliably tell), a Hard Fault occurs on the CoPro shortly after waking up. I noticed that, when that happens, the memory area 0x10040000 through (at least) 0x10042a80 is overwritten with 0xFF. This is where the IPC shared memory is, which leads to an invalid load operation, causing the Hard Fault. Also, on Linux side, a message occurs 

`

[  272.028406] virtio_rpmsg_bus virtio0: output:id 4294967295 out of range

`.

Sometimes, the memory area of approx. 0x1003D000 through 0x1003D700 gets overwritten with patterns. This leads to a hard fault within the CoPro application.

I checked VCC_CORE which is 1.2 V and is stable throughout the Stop mode.

Data cache is disabled for debug purposes using

`

SCnSCB->ACTLR |= SCnSCB_ACTLR_DISDEFWBUF_Msk;__DSB();__ISB();

`

I am thankful for debug hints and/or ideas. Thanks!

 

[Christophe Guibout]

Hello ​@tinova-11,

To have a better understanding of the issue, I would avoid CA7 to wake up on PI8 EXTI and check if the issue is still there by only resuming CM4, and then, only wakeup CA7 on PI8 EXTI : the idea is to know which processor is responsible of the erase.

Then, As the same IRQ wakes both CPUs and as the problem is not systematic, I would check if it could have a kind of race condition between both rpmsg resume by adding some logs (maybe logs will have an impact of occurence of the issue, but anyway, it will help to understand what is happening).

Hope it will help,

BR,

Christophe

[tinova-11]

Hi Christophe,

thanks four your reply. I tested waking up the MCU first (via PI8), then the MPU via PA0 and waking up the MPU first, then the MCU. However the error still occurs.

Best regards

Timo