Parallel Programming over USB DFU using STM32CubeProgrammer CLI

[ben8]

Hello,

I am attempting to program many devices (~15-30) using the built-in USB DFU on the STM32U585 in parallel. Using the STM32CubeProgrammer CLI (v2.17.0), I am running the following command to connect the devices:

–-connect port=usb sn=<DFU serial number>

I am performing device programming in a threaded-manner such that each device is put into USB DFU mode and connected to/programmed in parallel. 

To create the DFU serial number, I first obtain the 96-bit MCU UUID, combine the first and third 32-bit sections, then concatenating the first 4 MSB of the second section. For example, given UUID 00580027 3331500b 20333153

1. Combining 0x00580027 and 0x20333153 yields 0x208B317A
2. Then concatenating the first 4 MSB of 0x3331500b yields 0x208B317A3331

The resulting DFU serial number 0x208B317A3331 is in line with the DFU serial number detected within STM32CubeProgrammer as well the serial number detected within the USB device manager.

However, producing this DFU serial number diminishes the uniqueness of each device during programming due to the loss of the last 4 bytes of the second word of the UUID (e.g. 500b in 3331500b). In practice, I have ran into the issue where multiple devices have had shared DFU serial numbers causing inconsistencies in programming where devices either fail to program or are programmed with the incorrect binaries.

Are there any work arounds or alternatives to device uniqueness while in DFU mode? Perhaps is it possible to alter the DFU serial number per device to assure uniqueness for each MCU? Or are there any tools that would allow parallel programming aside from using STM32CubeProgrammer CLI?

[TDK]

Use a 32 bit hash of the UUID. With 10,000 devices, you have a ~1.2% chance of a collision between any 2 devices.

No way to guarantee uniqueness taking a 96-bit value down to 32-bits. The documentation for fields within the UUID has not been accurate in the past.

When I'm doing this (programming many devices), I have a script that:

• detects when a new device is plugged in
• flashes the device
• verifies flash
• waits for device to be disconnected

And just loops forever. All doable with the STM32CubeProgrammer CLI.

[MM..1]

Maybe you explain for what you calculate SN , and how is your target? Different bins for every device based on ID?

[Pavel A.]

Length of USB "serial numbers" is not limited to 12 chars. You can use all 12 bytes and add more.

[ben8]

I am calculating the DFU SN to be able to reference specific devices that in DFU USB mode to be updated by the STM32CubeProgrammer CLI. It seems that the STM32CubeProgrammer CLI only identifies devices in USB DFU mode through that serial number that I've been creating from the UUID. 

The reason I need this is because I am programming different binaries to each device based off the ID. 

[ben8]

In reference to using STM32CubeProgrammer CLI to identify multiple devices in USB DFU mode, it seems that it is limited to 8 characters as previously described. When entering DFU mode (using the built-in STM bootloader) the device serial number in is identified only using the USB DFU serial number from what I've observed.

Do you mean that there is a way to update the DFU USB serial number to use all 12 bytes? If so, is there any documentation I can look at for this?

[MM..1]

A. you ticket programming in parallel = more as one target at time no more tartgets more bins...

B. SN isnt designed here as target ID , is only for list STM32_Programmer_CLI.exe 

-l,     --list         : List all available communication interfaces
     <uart>             : UART interface
     <usb>              : USB interface
     <st-link>              : st-link interface

  For your designs is better use your own OTP based IDs or read full UUID an d use it in script

 -r32                   : Read a 32-bit data from device memory
     <address>          : Read start address
     <size>             : Size of data

etc.

[Pavel A.]

See here, for example. Max. length of a string descriptor is 126 characters (each character occupies 2 bytes in UTF-16 format). Of course, using anything besides of alphanumeric chars there is begging for trouble.

[MM..1]

@Pavel A. He using builtin ROM DFU no custom.