2024-09-19 07:03 AM
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?
Solved! Go to Solution.
2024-09-20 03:06 AM
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.
2024-09-20 12:21 AM
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
2024-09-20 02:36 AM
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?
2024-09-20 03:06 AM
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.
2024-09-24 12:00 AM
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