STM32_Programmer_CLI.exe ignores serial number in shared mode

[Rookie38]

Hello Community,

when I enable the "Shared" option when connecting with STM32_Programmer_CLI.exe software, I notice that the serial number option ("sn=<>") is completely ignored. Is this a bug? The result is that wrong MCUs are flashed during a flash operation, although a serial number is passed.

Used Command:

STM32_Programmer_CLI.exe -c port=SWD shared SN=004000373039510634393838 freq=24000 -w $(BUILD_DIR)/$(TARGET).bin 0x08008000 -v mode=UR reset=HWrst

[Aziz BRIGUI · Accepted solution]

Hello @Community member​,

The issue have been reported to STM32CubeProgrammer team.

Internal ticket number:  136233 (This is an internal tracking number and is not accessible or usable by customers)

Throughout the tests I made, I noticed that the ST-LINK serial number is ignored only when one ST-LINK is connected. In other words, I couldn't reproduce the scenario where the wrong MCU was programmed. If two ST-LINKs are connected, the one with the specified serial number will be programmed. So the impact of this bug is not as major as a wrong MCU being flashed.

If you have a scenario where you encountered the issue, please share the details of your setup.

Thanks a lot for your contribution �� !

Aziz

[Rookie38]

Hello Aziz,

I apologize for the late feedback. When rereading my post, I expressed myself a little too vaguely.

My setup looks like this:

 

When I run with the following command to flash the STM32F7 Disc, the STM32F4 Disc is flashed:

powershell "& '..\fw_toolchain\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe' \
		-c port=SWD shared SN=004000373039510634393838 freq=24000 -w $(BUILD_DIR)/$(TARGET).bin 0x08008000 -v mode=UR reset=HWrst"

Only if I remove the shared option, the correct board is flashed. I no longer have the use case of running the ST links in shared mode, but I still wanted to share the behavior. Distinguishing the ST links by SN while they are in shared mode does not seem to be possible in my setup.

[Aziz BRIGUI]

Hello @Community member​,

Thank you for your detailed response ��!

I tried connecting two ST-LINKs to the PC through a USB-Hub and still can't reproduce the scenario where the wrong MCU is programmed in shared mode (if an existing SN is specified in the CLI command).

This leads me to think that this might have something to do with the USB-Hub you're using. If possible, could you please try this with another USB-Hub and share the results? If not, could you share the name and reference of your USB-Hub?

When running the following command:

STM32_Programmer_CLI -l

Could share the trace you are getting?

Thanks

Aziz

[Rookie38]

I suspect I have discovered the problem:

The ST-Link of the STM32F7 is not recognized and when this scenario occurs, for whatever reason the second ST-Link (STM32F4) is flashed although the serial number does not match: Line 23-27 Device is missing!

powershell "& '..\fw_toolchain\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe' \
        -l -c port=SWD shared SN=004000373039510634393838 freq=24000 -w Build/Firmware.bin 0x08008000 -v mode=UR reset=HWrst"
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.11.0                       
      -------------------------------------------------------------------
 
=====  DFU Interface   =====
 
No STM32 device in DFU mode connected
 
===== STLink Interface =====
ST-LINK error (DEV_CONNECT_ERR)
ST-LINK error (DEV_CONNECT_ERR)
 
-------- Connected ST-LINK Probes List --------
 
ST-Link Probe 0 :
   ST-LINK SN  : 066DFF545052836687101831      
   ST-LINK FW  : V2J40M27
   Access Port Number  : 1
   Device Name  : 32F429IDISCOVERY
 
ST-Link Probe 1 :
   ST-LINK SN  :
   ST-LINK FW  :
   Access Port Number  : 0
   Device Name  :
-----------------------------------------------
 
=====  UART Interface  =====
 
Total number of serial ports available: 3
 
Port: COM255
Location: \\.\COM255
Description: STMicroelectronics STLink Virtual COM Port
Manufacturer: STMicroelectronics
 
Port: COM1
Location: \\.\COM1
Description: Kommunikationsanschluss
Manufacturer: (Standardanschlusstypen)
 
Port: COM11
Location: \\.\COM11
Description: STMicroelectronics STLink Virtual COM Port
Manufacturer: STMicroelectronics
 
ST-LINK error (DEV_CONNECT_ERR)
ST-LINK error (DEV_CONNECT_ERR)
ST-Link Server is running on port : 7184
ST-LINK SN  : 066DFF545052836687101831
ST-LINK FW  : V2J40M27
Board       : 32F429IDISCOVERY
Voltage     : 2.86V
SWD freq    : 4000 KHz
Connect mode: Normal
Reset mode  : Software reset
Device ID   : 0x419
Revision ID : Rev 5/B
Device name : STM32F42xxx/F43xxx
Flash size  : 2 MBytes
Device type : MCU
Device CPU  : Cortex-M4
BL Version  : 0x91
 
 
 
Warning: No need to these parameters in verify command: mode=ur reset=hwrst
 
 
Memory Programming ...
Opening and parsing file: Firmware.bin
  File          : Firmware.bin
  Size          : 179.47 KB
  Address       : 0x08008000
 
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [2 5]
Download in Progress:
██████████████████████████████████████████████████ 100%
 
File download complete
Time elapsed during download operation: 00:00:04.234
 
 
 
Verifying ...
 
 
Read progress:
██████████████████████████████████████████████████ 100%
 
Download verified successfully 
 
 
 *  Terminal will be reused by tasks, press any key to close it.

[Rookie38]

Now I have also found out when exactly this scenario occurs. In another script, I connect to the ST link of the STM32F7 to process the SWD messages. The command is as follows: This connection is not shared and causes another STM32Cube instance to not find the device and flash it.

"../fw_toolchain/STM32CubeProgrammer/bin/STM32_Programmer_CLI.exe -c port=SWD sn=004000373039510634393838 mode=UR -startswv freq=216 portnumber=0 '${workspaceRoot}/Build/swv.log'",

Still interesting to know that the CLI tool decides to flash another ST-Link if it can't find the correct serial number when it is blocked by another instance.

[Aziz BRIGUI]

That changes things in your case, if the ST-LINK is used by a second instance (with shared mode disabled), from the point of view of the first, it is not visible (SN isn't detected). So, it doesn't matter if the first instance is shared or not. You won't be able to program the MCU from it, this is expected (since the ST-LINK in question is already in use). It is as if you specified a non-existing ST-LINK SN.

To conclude, I will notify you as soon as the issue is resolved. Again, thank you for this contribution ��!

Aziz

[Aziz BRIGUI]

Hello @Community member​,

Issue is resolved in latest STM32CubeProgrammer version (v2.13.0) available under this link.

Aziz