How to recover after flashing wrong tf-a firmware?

[Jin]

Hi,

I was looking at the ST Yocto dunfell update and wanted to update tf-a firmware and u-boot:

https://github.com/STMicroelectronics/meta-st-stm32mp/tree/dunfell/recipes-bsp/trusted-firmware-a

Unfortunately I did not realize which of the tf-a versions I should use and ended up flashing the SSP version (using STM32_Programmer_CLI programmer via USB OTG connection)

I had a serial terminal connected open on the other port and saw an error about SSP not being supported on this board when it tried to boot, so I wanted to flash back my old version. Unfortunately, I had to realize that its no longer possible...

The USB OTG connection which is being used for DFU is dead, I do not see anything in dmesg on my notebook when plugging or unplugging the the ST board or when powering cycling the board. The other USB port which I use for a serial connection is still being detected, but I see no output in the terminal when powering the board on.

Basically I lost the ability to reprogram the board via DFU... I also tried booting from the SD card (changed the boot switches accordingly), but it does not come up.

So at this point it is kind of bricked... how can recover from this?

[OlivierK]

Hello Jin (Community Member)

Normally, you should still have access to the USB OTG port if you can set the boot pins to 00 (DFU mode) which is independant of the tf-a firmware since it it set by the Romcode. Then use Cube programmer to select ony the TF-a partition to reprogram. Easier using the CubeProgrammer GUI version so that you can tick only the TF-A partition to program, or using the CLI version by editing the TSV file and leaving the "P" only for the FSBL1 partition.

The other option is to remove the SDcard, and reprogram the first partition using the dd command.

https://wiki.st.com/stm32mpu/wiki/How_to_populate_the_SD_card_with_dd_command

Best Regards

Olivier

[Jin]

Hi Olivier,

well that's the thing, I would expect that I can simply reprogram the board via DFU because the ROM code should allow to do just that. My issue is, that after the event described in the first post, even if I set the pins to DFU mode - the USB OTG is not being detected at all, its dead. So I can't use the cube or CLI version of the programmer - it does not find the board. The LED next to the USB OTG port goes green when I insert the cable, but on the PC side its not being detected at all, absolutely no reaction.

I rechecked my setup with a different ST board and there I can connect it in DFU mode without any problems.

I did try the SD card approach as well, i.e. flashed a working image, put the boot pins to sd-card mode and tried to boot - nothing.

The ST-Link serial line works but shows nothing in the console when booting.

Did my board die? I honestly did not do anything else except accidentally flashing tf-a SSP...

It's an STM32MP157A-EV1...

What would you suggest?

Kind regards,

Jin

[OlivierK]

Hello Jin (Community Member)

Have you tried to reprogram the TF-a using UART (via STLink ttyACM0) instead of USB OTG with STM32_CubeProgrammer?

I hope you haven't reprogrammed the OTP fuses by mistake.

https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#USB_Boot

Best Regards,

Olivier

[Jin]

Hi Olivier,

> Have you tried to reprogram the TF-a using UART (via STLink ttyACM0) instead of USB OTG with STM32_CubeProgrammer?

the wiki only describes how to do it via USB so I am not sure if I am missing some settings, I tried:

STM32_Programmer_CLI -c port=/dev/ttyACM0 -w myimage.tsv

And I get:

      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.4.0                  
      -------------------------------------------------------------------
 
Serial Port /dev/ttyACM0 is successfully opened.
Port configuration: parity = even, baudrate = 115200, data-bit = 8,
                     stop-bit = 1.0, flow-control = off
 
Timeout error occured while waiting for acknowledgement.
 
Timeout error occured while waiting for acknowledgement.
Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again... 

I also tried moving the J4/J5 jumpers to activate UART4 and connecting via UART4, but I am getting the same message like above. What am I missing?

> I hope you haven't reprogrammed the OTP fuses by mistake.

Ugh... well, the only thing I did was - flashing the tf-a binary produced by the build of https://github.com/STMicroelectronics/meta-st-stm32mp/blob/dunfell/recipes-bsp/trusted-firmware-a/tf-a-stm32mp-ssp_2.2.bb via the programmer/DFU just as I would usually flash any other tsv/linux images that I build for this board.

There was no "big fat warning" about tf-a-stm32mp-ssp so I really hope that nothing bad should happen? I did not do any special steps or anything unusual, just flashed the .tsv that I have been using many times, with the only difference that it was pointing to the newly built tf-a-stm32mp-ssp binary.

Is there a way to check the state of those fuses now? I guess for that I would need to be able to access the board somehow?

Kind regards,

Jin

[OlivierK]

Hi Jin (Community Member)

Can you try this page for reading the OTP:

https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer#How_to_fuse_STM32MP15x_OTP

Indeed, I fear that you may not be able to read them if you cannot connect to the board.

The normal procedure to read the OTP via USB is:

PC $> STM32_Programmer_CLI -c port=usb1 -otpdispl

you may try to connect via UART and increase the timeout

Best Regards

Olivier

[PatrickF]

Hello,

Basic HW checks to see if IC is booting (Bootrom only)

Step1: put IC in serial boot

• disconnect everything on EV1 board, put the jumpers on their default (see appendix-A of https://www.st.com/resource/en/user_manual/dm00591370-evaluation-boards-with-stm32mp157-mpus-stmicroelectronics.pdf)
• Place Boot switch in 0b000 (https://wiki.st.com/stm32mpu/nsfr_img_auth.php/4/4d/STM32MP157x-EVx_jumper_flash.jpg)
• power on the EV1 board

You should have

• Red led (PA13) toggling at about 5 Hz

That's is first sign of life, if not toggling, check supplies, resets, etc... eventually try using MB1263 alone to see what could be wrong.

Step2: Connect USB_OTG (USB micro-B on motherboard, between UART4 and the 4 x USB Type-A) to the PC

• Red led should freeze (either on or off) once USB is correctly enumerated
• You Windows device manager a device like "DFU in HS mode @Device ID /0x500...." should appear

Let us know the result of each step

[Jin]

Hi Olivier and Patrick,

thank you for the responses.

> STM32_Programmer_CLI -c port=usb1 -otpdispl

>

>you may try to connect via UART and increase the timeout

Unfortunately I can't get anywhere with the programmer because it seems there is "nobody home" on the other end... I do not get a working USB enumeration except on the daughter board/ST-Link.

>Step1: put IC in serial boot

> disconnect everything on EV1 board, put the jumpers on their default (see appendix-A of https://www.st.com/resource/en/user_manual/dm00591370-evaluation-boards-with-stm32mp157-mpus-stmicroelectronics.pdf)

OK, checked all jumpers and made sure everything is set according to the document.

> Place Boot switch in 0b000 (https://wiki.st.com/stm32mpu/nsfr_img_auth.php/4/4d/STM32MP157x-EVx_jumper_flash.jpg)

> power on the EV1 board

Did that.

> You should have

> Red led (PA13) toggling at about 5 Hz

Here is the first problem: PA13 is on, but it is steady, its not flashing. LD6 is flashing green and LD1 is steady green.

Connecting the USB_OTG port makes the LD2 led which is located next to the USB_OTG port to light up green, but otherwise nothing is happening and USB is not being enumerated.

> eventually try using MB1263 alone to see what could be wrong

Could you please give some hints on what I could try there? The only thing I can tell so far is, that when I connect the ST-Link USB port on the MB1263, it gets correctly enumerated. Usually I was using it with a terminal program to access Linux serial console/u-boot, now I can connect the terminal to it, but it is otherwise silent.

[Jin]

One more note: I took the MB1263 off now and powered it on alone, LEDs on it behave the same, i.e. PA13 is on steady red.

[Jin]

And yet another note: I also tried booting from the SD-card with an OpenSTLinux image (generated from FlashLayout_sdcard_stm32mp157c-ev1-trusted.tsv, boot switches set to boot from SD) and I see no output in the ST-Link serial console and no change in behavior, PA13 is still steady red.