STM32MP235 fails to boot

[axel101]

I am using STM32MP235 on custom board. 

At some point, I wanted to update the firmware via SFU using STM32CubeProgrammer.
I rebooted the board in USB mode (setting the boot mode to BOOT using the pins) and launched CubeProgrammer.
TF-A-programmer-usb loaded onto the board normally, but after that, the board stopped responding via DFU.
After a power reset, the board boots in DFU mode, even though the internal eMMC contains the old firmware, and the default boot mode is eMMC.
As soon as TF-A is loaded onto the board, the board disappears. Nothing is written to the debug port, making it seem as if TF-A failed to boot.
I tried using ROMTrace TF-A. The behavior is exactly the same, and no trace is output to the port.
Pin PG4 (FAILBOOTN) is connected to a red LED. During normal boot, this LED starts blinking, and after flashing the TF-A (whether via USB or Serial), it turns solid.
The documentation says that the FAILBOOTN LED blinks when the board initially boots in USB/UART mode, meaning it doesn't even attempt to load the stock firmware?

[PatrickF]

Hi ​@axel101 

did you check BOOTs pins level ? They need 1K pull-up for a safe logic ‘1’ detection (and left open as embedded pull-down for a logic ‘0’).

Once boot is falling back to DFU instead of eMMC (which mean BootROM does not detect a valid TF-A on the eMMC active boot partition), you should be able to load the ROMTraceDump FW and get helpful output on UART.
On the Cubeprogrammer command line, use the right .stm32 binary for the UART you have (for MP23, use the MP2ROMtracesdump….. files).

https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_trace_analyzer#On_STM32MP2_series 

Regards.

[PatrickF]

notice that BOOTFAILN for MP235 platform is on PH4 pin (and not PG4 as you mention).
Usually in DFU it blink until USB is connected (and could stop either high or low, not important).
refer to AN5489

 

[axel101]

BOOTPIN level is correct and ROM BOOT starts successfully in DFU mode.

According to BOOTFAIL pin it is my mistake. The LED connected to correct PH4 pin, yes.
I tried a ROMtrace and behavior is similar - once CubeProgrammer tries to star uploaded RomTrace.stm32 binary a BOOTFAIL LED flashing solid.

It feels like the board somehow entered SecureBoot mode on its own and simply won’t even accept the loader. I tried inserting code into the loader that would make another LED blink at the very earliest stage of initialization, but that didn’t work either. I also verified that this isn’t a monotonic version counter error. I built the bootloader with the maximum value for this counter (STM32_TF_VERSION=32) and ran it on the board with the same result

 

I didn't mention that before the board entered this state, I was updating the firmware using my own utility, which works the same way as STM32CubeProgrammer and flashes the firmware via a TSV file over USB DFU.
Quite a few steps had been taken before the board bricked, and I wasn’t sure if it was my program that put the board into this state, but now I’m more certain of it.
However, my utility doesn’t flash the OTP itself, and there was never a partition with ID 0xF2 in the TSV file.

 

[axel101]

I figured out that the problem was with my custom flashing program. When flashing fsbl-boot, it selected the wrong alt partition and wrote to alt=1 instead of alt=0—where, according to the partition table, RSSE_FW is located.
Now the question is, can the board be repaired after such a flash?

Partition table in ROM BOOT DFU:
 

$ dfu-util -l
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=0200, devnum=115, cfg=1, intf=0, path="1-5.3", alt=4, name="@virtual /0xF1/1*512Ba", serial="0029004A4236501600333258"
Found DFU: [0483:df11] ver=0200, devnum=115, cfg=1, intf=0, path="1-5.3", alt=3, name="@RSSE_PLUGIN /0xF6/1*96Ke", serial="0029004A4236501600333258"
Found DFU: [0483:df11] ver=0200, devnum=115, cfg=1, intf=0, path="1-5.3", alt=2, name="@RSSE_BLOB /0xF5/1*128Ke", serial="0029004A4236501600333258"
Found DFU: [0483:df11] ver=0200, devnum=115, cfg=1, intf=0, path="1-5.3", alt=1, name="@RSSE_FW /0xF3/1*256Ke", serial="0029004A4236501600333258"
Found DFU: [0483:df11] ver=0200, devnum=115, cfg=1, intf=0, path="1-5.3", alt=0, name="@FSBL /0x01/1*256Ke", serial="0029004A4236501600333258"