an error occured after sending a dfu end of download request

[Daniel S.]

 

We have the STM32MP157 EV1 Board, build our own yocto images (using the st layers) and are able to flash the images into emmc using STM32_Programmer_CLI.exe. Everything works great.

Now we received our first custom boards with the same STM32MP157 Chip and the same workflow does not work anymore.

STM32_Programmer_CLI.exe -c port=USB1 -w .\FlashLayout_emmc_stm32mp157f-cubemx_xmaster5-mx-optee.tsv -vb 3

Memory Programming ...
Opening and parsing file: debug-tf-a-stm32mp157f-cubemx_xmaster5-mx-usb.stm32
 File : debug-tf-a-stm32mp157f-cubemx_xmaster5-mx-usb.stm32
 Size : 220.50 KB
 Partition ID : 0x01

Download in Progress:
 Size : 225788 Bytes

[... whole lot of output ...]

DFU status = 0 : OK
DFU state = 4 : dfuDNBUSY
bwPollTimeout = 1
DFU status = 0 : OK
DFU state = 5 : dfuDNLOAD-IDLE
bwPollTimeout = 1
Segment[0] downloaded successfully


File download complete
Time elapsed during download operation: 00:00:03.477

RUNNING Program ...
 PartID: :0x01
DFU status = 0 : OK
DFU state = 5 : dfuDNLOAD-IDLE
bwPollTimeout = 1
sending a dfu end of download request
DFU status = 0 : OK
DFU state = 7 : dfuMANIFEST
bwPollTimeout = 1
libusb get status error [-9] : LIBUSB_ERROR_PIPE
an error occured after sending a dfu end of download request
Status: errUNKNOWN, State: dfuERROR


Error: Start operation failed at partition 0x01
Error: TSV flashing service failed

It seems like the programmer can upload the first stage boot loader into the MPUs SRAM but is not able to run it.

We have no ideas left why it does not run. Especially as it is fine on the EV1. Can anyone give us a clue where to look or what we could try?

[PatrickF]

Hi @Daniel S. 

could you share the board console output ?

It is probable that the loaded custom TF-A fail at some point (e.g. DDR initialization).

Regards

[Daniel S.]

That's basically our main problem: we don't get any. On the EV1 we see outputs on UART4. In our new design we switched UART4 to other pins (using STs CubeMX tool) but no outputs there. Now we discovered that there is a hard coded panic console on PG11 - we see data there but no ascii:

00 D5 8D B5 E5 FD 3D 17 BF 5F 79 BF 8B BF 9F 0F 9B 33 33 35 39 97 8F 37 E5 EB D6 75 0F 39 35 1F 17 2D 21 23 BF 25 21 37 35 85 9F 0F 9F 9F 9F 9F 9F 9F 9D 93 BF 3D 17 8B BF 9F 0F 9B 33 33 35 39 97 8F 37 EB E5 00 FE

 (115200 baud, 8n1)

What could prevent the MPU to correctly print to the panic console? 

[PatrickF]

Hi,

Maybe look with an oscilloscope on your UART TX output and try to find the bit duration, maybe a wrong baudrate or clock settings in your TF-A.
For the UART4 pin changes not working, maybe an issue on the TF-A DTS forming or TF-A compilation not using the right DTS.

One common pitfall is the HSE bypass mode used on our EV1 board. If you use a Crystal, you should change this in TF-A by removing "st,digbypass;" (whereas bootrom use an autodetection, TF-A use DT).
https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.8-stm32mp/docs/devicetree/bindings/clock/st,stm32mp1-rcc.txt#L369

 

Regards.