Debugger listing

[schneidersoft]

Implement the short option -L to find and list all the interesting usb devices and serial numbers correct some whitespace

[spth]

-L itself works for me. Even when I invoke it multiple times. But once I've invoked stm8flash otherwise, all serials are the same (example with an external ST/Link V2 and an STM8A-Discovery attached):

root@notebook6:/tmp/stm8flash# ./stm8flash -L
Programmer 0: STMicroelectronics STM32 STLink, Serial Number:513F6B06493F50535320163F
Programmer 1: STMicroelectronics STM32 STLink, Serial Number:303030303030303030303031
root@notebook6:/tmp/stm8flash# ./stm8flash -L
Programmer 0: STMicroelectronics STM32 STLink, Serial Number:513F6B06493F50535320163F
Programmer 1: STMicroelectronics STM32 STLink, Serial Number:303030303030303030303031
root@notebook6:/tmp/stm8flash# ./stm8flash -c stlinkv2 -w /home/philipp/sdcc-trunk/sdcc-extra/historygraphs/dhrystone-stm8-speed-13900/image.ihx -p stm8af5288
Determine FLASH area
WARNING: More than one programmer found but no serial number given. Programmer 1 will be used:
Programmer 1: STMicroelectronics STM32 STLink, Serial Number:513F6B06493F50535320163F
Programmer 2: STMicroelectronics STM32 STLink, Serial Number:303030303030303030303031
STLink: v2, JTAG: v16, SWIM: v4, VID: 8304, PID: 4837
SWIM error 0x09
root@notebook6:/tmp/stm8flash# ./stm8flash -L
Programmer 0: STMicroelectronics STM32 STLink, Serial Number:303030303030303030303031
Programmer 1: STMicroelectronics STM32 STLink, Serial Number:303030303030303030303031

[schneidersoft]

I was not able to reproduce the behavior you see. But I did find a minor bug in my implementation. It should not have caused what you are seeing though.

[spth]

As I have now learned the iSerial changing to 303030303030303030303031 after first use of the ST-Link/v2 is a known bug in ST-Link/v2 firmware that can be fixed with a firmware update. Maybe we should emit a warning when we see a iSerial of 303030303030303030303031?

The warning should be phrased carefully (we don't want to push the user for a firmware update too much - after all the firmware is AFAIK still non-free; and some third-party clones of the ST-Link/v2 AFAIK do not work with the latest firmware).

But if we output an iSerial of 303030303030303030303031 the user should know that this is most likely not the correct value. Maybe something like "This serial number is most likely an invalid one caused by a known ST-LINK firmware bug. The bug is fixed in ST-LINK firmware V2.J21.S4 and later."

[schneidersoft]

I'd like to add a link to somewhere describing this bug. do you have a good link?

[spth]

Unfortunately, I don't have a good link.

There's some discussion in an OpenOCD forum (https://openocd-devel.narkive.com/ZE7UXDWO/st-link-v2-serial-number), and a note in OpenOCD documentation (https://openocd.org/doc/html/Debug-Adapter-Configuration.html). And sme info on someones personal website (http://wunderkis.de/stlink-serialno/).

In particular, I did not find a firmware Changelog at ST's firmware upgrade documentation page (https://www.st.com/en/development-tools/stsw-link007.html#documentation). Looks like there is only a Changelog for the firmware upgrade utility, but not the firmware that comes bundled with it.

P.S.: I just upgraded the firmware on an original external ST-Link/v2 from V2J16S4 to V2J42S7. I also upgraded the firmware on an integrated ST-Link/v2 on an original STM8AF board from the STM8A-Discovery bundle from V2J0S4 to V2J0S7. On both devices, before the upgrade, I saw the 303030303030303030303031 problem. Since the upgrade, the problem is gone. But this also means that we probably shouldn't mention a specific firmware version in the warning, as different ST-Link/v2 variants have different firmware version numbering. So maybe a better warning text would be "This serial number is most likely an invalid one caused by a known ST-LINK firmware bug in older firmware versions."