cancel
Showing results for 
Search instead for 
Did you mean: 

an error occured after sending a dfu end of download request

Daniel S.
Associate II

 

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?

1 ACCEPTED SOLUTION

Accepted Solutions

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.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

View solution in original post

4 REPLIES 4
PatrickF
ST Employee

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

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

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? 

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.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Thanks for your fast response.
The HSE bypass mode did the trick. Now the board prints out a lot more and we are able to read it (don't really know why - we also the switched logic analyzer for decoding).
So now we are able to boot through TF-A and are stuck in optee but that's a different story. Thank you