STM32MP257F-DK - Wakening From suspend-to-RAM

[Will_Robertson]

We ordered an STM32MP257F-DK evaluation board - DigiKey part number "497-STM32MP257F-DK-ND" - on 25 September 2025 and had it delivered to Zürich.

On 15 October 2025 we ordered the same ST STM32MP257F-DK evaluation board with DigiKey part number "497-STM32MP257F-DK-ND" for delivery to one of our developers - Paul - working remotely.

Paul booted the ST STM32MP257F-DK board using the SD card that was supplied with it and was able to take it into and out of suspend-to-RAM with no problems however when we try to reproduce this with exactly the same steps with the ST STM32MP257F-DK here in Zürich it fails to waken from suspend-to-RAM.

We thought that it could be a difference in the images on the ST cards for the two boards so we copied the image for the SD card on the board delivered to Paul and tested it on the board here with exactly the same results.

We also checked that the WakeUp switch on the board is electrically functional - when I press it:

[ 290.372530] optee: no desc for optee IT:1

We also tested wakening from suspend-to-RAM using both the WakeUp switch on the board and the RTC (Real Time Clock) on the board here in Zürich without success.

Since there are several variants of this eval. board and several variants of this MPU it went through my mind that I could have made a mistake and accidentally had different boards delivered to Zürich and to Paul.

I checked the order for the ST MCU board that was delivered to here in Zürich which shows DigiKey part number "497-STM32MP257F-DK-ND" ordered on 25 September 2025 and delivered to Zürich - this seems to be exactly the same DigiKey part number as shown in the email from DigiKey to Paul on 15 October 2025:

DISCOVERY KIT STM32MP257F MPU
DigiKey part number
497-STM32MP257F-DK-ND
Manufacturer part number
STM32MP257F-DK

In both cases, we tested the STM32MP257F-DK board with a USB cable connected to provide power and serial debugging to a Linux machine.

The only difference we could find between the STM32MP257F-DK boards was several weeks difference the dates on which they were ordere.

I was wondering if you had any suggestions or if there were any known issues with suspend-to-RAM that could have caused this?

Thank you very much for your help,

Will

[Erwan SZYMANSKI]

Hello @Will_Robertson ,
So from what I understand, you are using the default SD card image delivered with the board on 2 exact same boards, but see a difference in the final result to wake up from standby. Can you give me a bit more detail about the test you do, with which command ? 

Could you provide me the result of "uname -a" command on the board that fails ?

If you look at the STM32MP25 SoC on each board, can you provide a photo of KO and OK one ? 

Kind regards,
Erwan.

[Will_Robertson]

Hi Erwan,

Thank you very much.

Yes - Paul used the SD card that was supplied with the board and we also used the SD card that was supplied with the foard.

When we realized that Paul's board was wakening from suspend-to-RAM but our board wasn't we tried copying over the image from Paul's SD card vand testing it on our board but the result on the board in Zürich was unchanged.

Here are the numbers from the top of the chip for the board here in Zürich that doesn't seem to resume from suspend-to-RAM via either the WakeUp switch or the RTC - I'll type them twice to try to make sure I don't make typing mistakes:

ST e2

STM32MP257FA
K3
AAD53 9R Y
TWN AA 424
D4

STM32MP257FA
K3
AAD53 9R Y
TWN AA 424
D4

There's a label on the other side of the board:

STM32MP257F-DK
DK32MP257F$AR1
A244901259
MB 1605-MP257F-C01

The dip switches are in their original positions:

BOOT0 On

BOOT1 Off

BOOT2 Off

BOOT3 Off

On JP3 there's no jumper in place.

No peripherals are attached to the board.

I asked Paul to send over the details from his board - Paul's board goes into suspend-to-RAM and wakens correctly from the WakeUp switch or RTC as expected - I'll send those over as soon as I get them from Paul.

The WakeUp switch is electrically functional - when I press it:
[ 290.372530] optee: no desc for optee IT:1

Here's the board in Zürich going into suspend-to-RAM using echo mem > /sys/power/state:

root@stm32mp2-e3-aa-db:~# echo mem > /sys/power/state
[ 356.015138] PM: suspend entry (deep)
[ 356.015392] Filesystems sync: 0.000 seconds
[ 356.170023] Freezing user space processes
[ 356.171461] Freezing user space processes completed (elapsed 0.001 seconds)
[ 356.175433] OOM killer disabled.
[ 356.178653] Freezing remaining freezable tasks
[ 356.184408] Freezing remaining freezable tasks completed (elapsed 0.001 seco)
[ 356.190576] printk: Suspending console(s) (use no_console_suspend to debug)

And here it is using rtcwake --date +5sec -m mem

root@stm32mp2-e3-aa-db:~# rtcwake --date +5sec -m mem
rtcwake: assuming RTC uses UTC ...
rtcwake: wakeup from "mem" using /dev/rtc0 at Sat Jan 1 00:19:50 2000
[ 267.482029] PM: suspend entry (deep)
[ 267.482228] Filesystems sync: 0.000 seconds
[ 267.633771] Freezing user space processes
[ 267.635666] Freezing user space processes completed (elapsed 0.001 seconds)
[ 267.639233] OOM killer disabled.
[ 267.642454] Freezing remaining freezable tasks
[ 267.648216] Freezing remaining freezable tasks completed (elapsed 0.001 seco)
[ 267.654384] printk: Suspending console(s) (use no_console_suspend to debug)

With the above, the board in Zürich didn't seem to waken on WakeUp switch or RTC.

>Could you provide me the result of "uname -a" command on the board that fails ?

Thanks - I'll do that and send it over ASAP.

Will

[Will_Robertson]

Hi Erwan @Erwan SZYMANSKI ,

Thank you very much for your help with this - here are the details from Paul's board - I've highlighted the numbers on the SoC that differ from the board in Zürich in bold:

SoC:

ST e2
STM32MP257FA
K3
AA027 9R Y
TWN AA 444
01

Digikey label on the board:
STM32MP257F-DK
DK32MP257F$AR1
A244901977
MB1605-MP257F-C01

DataMatrix on the label decodes to:
STM32MP257F-DK;DK32MP257F$AR1;A244901977;MB1605-MP257F-C01;Z4A49001

There does seem to be a difference in the following numbers on the SoC on the board here in Zürich which doesn't waken from suspend-to-RAM:

AAD53 9R Y
TWN AA 424
D4

and the corresponding numbers on the SoC on Paul's board which was ordered 3 weeks after the board here in Zürich and which does waken from suspend-to-RAM correctly:

AA027 9R Y
TWN AA 444
          01

Will

[Erwan SZYMANSKI]

Hello @Will_Robertson,
Can you please try to generate 2 new SD image from the starter guide here and test it on both board ? 
https://wiki.st.com/stm32mpu/wiki/Getting_started/STM32MP2_boards/STM32MP257x-DK/Let%27s_start/Populate_the_target_and_boot_the_image

If you still have a difference between both boards, I invite you to contact Digi to exchange the board that looks non functional. Further analysis will be done on their side.

Kind regards,
Erwan.

[Will_Robertson]

Hello Erwan @Erwan SZYMANSKI ,

Thank you very much for your help.

Following the instructions on: 

https://wiki.st.com/stm32mpu/wiki/Getting_started/STM32MP2_boards/STM32MP257x-DK/Let%27s_start/Populate_the_target_and_boot_the_image

there's a link to:

https://www.st.com/en/embedded-software/stm32mp2starter.html#get-software

To make sure that we get everything exactly right, should we try the A35-TD flavor or the M33-TD flavor and - if the A35-TD flavor - should we select version 6.1.0, 6.0.1 or 6.0.0?

Until now we've only tried with the SD card included with the board delivered to Zürich and a copy of the SD card that was delivered with Paul's board.

I asked Digi to send a replacement board to Zürich so that we can see whether or not the problem is reproduced on it.

Thank you very much for your help!

Will