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

[Steffen Rose]

I answered yesterday to your private mail. Seems you did not receive it?

[Olivier GALLIEN]

Hi @Steffenose​ ,

I contacted ST guys supporting your customer and he confirm that migration to a consistent Ecosystem V3 version is a work in progress.

I hope this next version will fix DFU instability you are observing.

In the meantime I understand you can workaround instability with verbosity setting.

Regarding other question :

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?

In production mode M4 is a slave of the A7/Linux system that control the system resource provided to M4. ( memory, clock etc.. )

That's why the load and start of M4 might be ensure by a Linux service and can't be bypass by a JTAG load directly into RAM ( this may lead to many resource conflict )

The hardware don't have ethernet 

2 alternatives :

• if HW has an USB_OTG you can try to use the USB ethernet gadget which setup a peer to peer connection ( enabled by default on DK2 Starter Image )

This can be transparently used by CubeIDE as ethernet connection.

• If you have USB host port, use USB stick to copy manually the .elf inside /lib/firmware and then proceed to load and start of the firmware thanks to manual remoteproc command

https://wiki.st.com/stm32mpu/wiki/Linux_remoteproc_framework_overview#How_to_use_the_framework

You can then still use CubeIDE for debug just unticking the "load firmware" option in the Debug Configuration.

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?

Engineering mode is a specific mode where A7 is on hold and M4 is JTAG open.

as explain in  https://wiki.st.com/stm32mpu-ecosystem-v2/wiki/STM32CubeMP1_development_guidelines in this mode M4 has access to almost all resources as master.

It can help you to mature your application.

Only potential A7 to M4 communication and synchronization will then remain to validate with Production mode.

Hope it help

Olivier

[Steffen Rose]

Thank you for your feedback. The use of Windows seems to be not so easy to create the M4 only part, but with interaction to the A7 linux.

Now I use Linux, too.

The DFU transfer seems to be good working on the beginning of the day, (fresh started PC, fresh started customer hardware). Later on the day with power off/on it seems, that I have more problems. But at the moment I have a run. 😉

Because the customer hardware don't have Ethernet, the customer activated CDC ECM on USB and it works on linux. On windows it seems not to be supported and some versions ago the workarounds (Intel, Acer driver) was removed. But if you have a solution for this it would be a good point for the wiki.

It seems, that the customer use a little bit changed linux image. The Stm32CubeIde seems to send commands to the linux side, that are not implemented (-ne not known). Is there a documentation, what the IDE needs on the Linux side to work correctly or is it possible to see the commands as echo?

At the moment I use a shell and copy all data i need on the customer hardware and start it. After them I use the IDE and start debugging of the M4.

Means in principe it works.

Thank you

BR

Steffen