Win10 Cubeprogrammer and DFU Bootloader STM32MP1 instable

[Steffen Rose]

I work on Win10. DFU is seen in the settings. I use the programmer to transfer the linux image to the customer MP1 board. The transfer is very instable and break on different files/positions. Very seldom the complete *.tsv image is transfered and I can start the linux system.

set TOOL=C:\ST\STM32CubeIDE_1.6.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.6.0.202101291314\tools\bin\STM32_Programmer_CLI.exe
%TOOL% -c port=USB1 -d tf-a-u-boot-kernel-initrd.tsv 
%TOOL%  -c port=USB1 -detach
pause

C:\Projekte\30088\EMOTAS>C:\ST\STM32CubeIDE_1.6.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.6.0.202101291314\tools\bin\STM32_Programmer_CLI.exe  -c port=USB1 -detach
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.7.0-RC1
      -------------------------------------------------------------------
 
 
 
USB speed   : High Speed (480MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : DFU in HS Mode @Device ID /0x500, @Revision ID /0x0000
SN          : 0037001E3438510B31393233
FW version  : 0x0110
Device ID   : 0x0500
Device name : STM32MP1
Device type : MPU
Device CPU  : Cortex-A7

(The last code is from the detach, but it should show my settings.)

Example for an abort:

Memory Programming ...
Opening and parsing file: u-boot.stm32
  File          : u-boot.stm32
  Size          : 823588 Bytes
  Partition ID  : 0x03
 
Download in Progress:
  Size          : 823588 Bytes
sending packet nbr: 0
DFU status = 0
DFU State = 4
DFU status = 0
DFU State = 5
sending packet nbr: 1
DFU status = 0
DFU State = 4
DFU status = 0
DFU State = 5
sending packet nbr: 2
DFU status = 0
DFU State = 4
DFU status = 0
DFU State = 5
sending packet nbr: 3
DFU status = 0
DFU State = 4
DFU status = 0
DFU State = 5
sending packet nbr: 4
DFU status = 0
DFU State = 4
DFU status = 0
DFU State = 5
sending packet nbr: 5
DFU status = 0
DFU State = 4
DFU status = 0
DFU State = 5
sending packet nbr: 6
DFU status = 0
DFU State = 4
DFU status = 0
DFU State = 5
sending packet nbr: 7
DFU status = 0
DFU State = 4
DFU status = 0
DFU State = 5
sending packet nbr: 8
DFU status = 0
DFU State = 4
DFU status = 0
DFU State = 5
sending packet nbr: 9
libusb control transfer error: -7
 
 
Error: failed to download Segment[0]
Error: failed to download the File
Error: Download partition 0x03 failed
Error: TSV flashing service failed

Regards

Steffen

[Olivier GALLIEN]

Hi @Steffenose​ ,

Thanks for your post.

I first notice that you use STM32_CubeProgrammer integrated as STM32CubeIDE pluggin.

Quite unusual way of working and this version strangely show up as STM32CubeProgrammer v2.7.0-RC1.

Could you please make a try using the official STM32CubeProg delivery from here https://www.st.com/en/development-tools/stm32cubeprog.html ?

Else please share further details about your environment :

Custom board if I got it well from previous post but what STM32MP1 reference ?

Which version of ecosystem ?

Thanks to share the .tsv content you are using and complete CubeProg and UART console traces in case of failure.

Thanks,

Olivier

[Steffen Rose]

Hi,

thank you very much for your answer, but I cannot see the relevance. It would be nice, if you point me to the relevant information. At the end of the day I want to develop on the M4 using the STM32CubeIDE on Windows. The Linux A7 is not my part, but of course it is my part to initialize the system. I used the GUI of the Programmer, too. But without differences. (Unsure, why the IDE is delivered with a RC1 version? )

I understand, that the transfer use two phases. But the transfer is instable in both. So in the first phase the CPU DFU bootloader is running, right?

CPU: STM32MP153CAA Rev B

At the moment not relevant, but I use an external ST-Link v2-1 from a Nucleo64 with SWD connection. (My next step would be to access the M4 without corrupting the A7 system. ;) But the initialization also create A7 accesses and A7 holds.)

With "--verbosity 3" it transfer slower, but more stable.

Because I use the ready to use linux images of my customer my information are limited. Hope, it helps.

NOTICE:  BL2: v2.2-r2.1(debug):v2.2-3-gbeca8e754-dirty
NOTICE:  BL2: Built : 18:43:48, Jun  6 2021

U-Boot 2021.07-rc3-dirty (Jun 06 2021 - 22:58:02 +0200)
 
CPU: STM32MP153CAA Rev.B
Model: STMicroelectronics custom STM32CubeMX board
Board: stm32mp1 in trusted mode (st,stm32mp153c-asample-mx)

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.10.10-as-dirty (***l@localhost.localdomain) (arm-***_linux-linux-gnueabi-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #80 SMP PREEMPT Sat Jun 5 13:30:40 CEST 2021

[Steffen Rose]

only one attachment?

[Steffen Rose]

the tsv-file itself

[Olivier GALLIEN]

Hi @Steffenose​ ,

Sorry, problem you report is quite unusual. To be relevant I first need to have a clear view of your context. :smiling_face_with_smiling_eyes:

With the provided file I understand you work on custom board with STM32MP153CAA RevB chip and with openstlinux-5.4-dunfell-mp1-20-11-12 (aka DV2.1 ).

Thanks to give information Linux is not your part .. so who provide you the material ? ( binaries and tsv )

Does he confirm your experiment ?

Indeed, looks like you succeed to load TF-A and Uboot in DDR but then it seems you are facing instability on USB to download next partition.

I would suggest to double check the USB Device Tree configuration in TF-A and Uboot.

Else, since you want to focus on M4, did you already think about using at first the Engineering boot mode which allow you to experiment M4 firmware without taking care of Linux side ?

For reference : https://wiki.st.com/stm32mpu-ecosystem-v2/wiki/STM32CubeMP1_development_guidelines

Hope it help,

Olivier

[Olivier GALLIEN]

Hi @Steffenose​ 

Sorry I just realized I miss information that you are using ready to use image from customer.

So interesting to get his feedback vs this issue.

Olivier

[Steffen Rose]

Hi,

attached I have the log, with the aborted uboot transfer. Do I understand you correct this transfer use the TF-A? And you suggest to check the TF-A settings.

Our customer maintain the hardware and the linux part. He use a Linux PC.

I understand, that it is needed for this part.

I familiar with STM32CubeIDE on Windows and had the hope I can use it for the M4 development, too.

As I understand the production mode is set by hardware boot pins.

I want to use the ST-Link to develop and debug the M4.

Is it possible to use the remoteproc with serial console only? It seems I need ethernet access to copy the scripts and files to the Linux system.

The hardware don't have ethernet and it seems Win10 doesn't have CDC ECM drivers, does it?

Can you explain, why you use this way instead of write the M4 program using the debug interface? It's RAM and the area is fix, right?

The M4 *elf files are static linked to fix addresses. Linux doesn't change it, does it?

Or can I use the STM32CubeIDE setting for Engineering mode, but of course the CPU itself is in production mode, that means, I don't have access to all settings and memories. RAM write by gdb should be possible in this environment, doesn't it?

OK, I will forward your information to our customer.

Thank you

Steffen

[Steffen Rose]

Our customer did have some help from your support to create the images. But I cannot write more in this community platform.

Currently (version, that I used) it is a mix of TF-A2.2 (from ECO System 2.x), U-Boot master and Linux 5.10 (ECO System 3.0).

At the moment they work on a version, that is complete ECO System 3.x (TF-A 2.4, U-Boot v2020.10, Linux 5.10).

The TF-A device tree was more than one time checked by the ST Support (by direct mail).

It seems, that the Linux version of the STM32Programmer has the same problems of timeout aborts like I on Windows.

They switched to dfu-util for more stable transfer.

But note, I cannot say so much about the Linux version and I don't understand, why the transfer work better with many Debug output.

For me it seems a timing problem and it seems a slower transfer works better. Are there parameter for additional pause settings?

Best regards

Steffen

[Olivier GALLIEN]

Hi @Steffenose​ ,

We have noticed in your log a strange DDR config @300000KHz which is the bottom limit and may explain some trouble.

Again, this require further information from your customer about the product and design choice.

You can use "Private message" to provide me further detail you don't want to disclose publicly.

BR,

Olivier