- This topic has 8 replies, 2 voices, and was last updated 5 years ago by
.
-
Posts
-
Hi All,
I recently upgraded my STM23CubeProgrammer and I think it updated some USB drivers. Since then my ST-Links won’t play nice together. I have three different boards. Each has their own ST-Link. They all work correctly if they are the only board connected to the PC. However, if I connect more than one I get various errors:
ST-Link V2 (dongle) – Fails to connect – it says
Warn : UNEXPECTED idcode: 0x6ba02477 Error: expected 1 of 1: 0x0bb11477
ST-Link V3 (onboard) – It connects ok, but times out when trying to erase external NOR Flash:
target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x080096ac msp: 0x20020000 Info : Erasing FLASH: 0x60000000-0x60006400... ------ Error: timed out while waiting for target halted Error: timed out while waiting for target halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0800112e msp: 0x2001ffe8 Error: failed erasing sectors 0 to 99 Error: flash_erase returned -302 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x080096ac msp: 0x20020000
ST-Link V2.1 (onboard) – works ok even when the other two st-links are connected.
I’ve tried all the usual troubleshooting – rebooting, rollback drivers, re-install drivers, updated st-link firmware.
The three boards communicate with each other, so I really need to debug them at the same time. How do I get back to that environment?
Cheers
DavidSorry, the first issue looks like you are trying to debug an STM32 device that is not supported by OpenOCD yet. Ynfortunately, OpenOCD relies on a hardcoded list of STM32 device IDs in order to detect the FLASH parameters. ST usually contributes push requests to the OpenOCD repository providing the updates, and then our packaging system picks them up, but that typically takes a few months since a new device is released.
It is also hard to say why the external NOR FLASH driver would be failing. If it’s using our OpenOCD FLASH driver plugin system, we can suggest a few things to check. However if it is something that comes with OpenOCD, our best advice would be to build a debug build of OpenOCD from sources and try stepping through it in order to understand what is going on.
Another option would be to switch from ST-Link to Segger J-Link. It is more expensive than ST-Link, however it allows Segger to maintain and regularly update their own proprietary replacement to OpenOCD that does not have many of the USB driver issues known to OpenOCD and also typically introduces support to new devices much faster than open-source tools like OpenOCD. VisualGDB supports both OpenOCD and the Segger J-Link debug stack the same way, so simply select J-Link in the Debug Settings once you plug it in and VisualGDB will switch the existing project to use it.
Thanks for your reply. I should have made my point a bit clearer. Each St-Link/board works perfectly in isolation. As long as it is the only board connected to the PC. That indicates it isn’t an issue with the boards or unsupported devices. It appears VisualGDB or OpenOCD is selecting the wrong ST-Link to communicate with. It is doing that because the serial number on one of the ST-Link/V2 dongles is corrupt.
<span style="color: #004000;">Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
Warn : *********************************************************
Warn : Found multiple matching USB devices:
Warn : VID | PID | Serial number
Warn : 0483 | 374b | 0669FF343339415043185838
Warn : 0483 | 374e | 003100413137511133333639
Warn : 0483 | 3748 | R?pQ?RS@?
Warn : Add the following command to your interface script to select a device:
Warn : hla_serial "<serial>" (for ST-Link)
Warn : jlink_serial "<serial>" (for J-Link)
Warn : ft2232_serial "<serial>" (for FT2232-based devices)
Warn : Auto-selecting the first device
Warn : *********************************************************
Info : STLINK V2J29M18 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.263810
Warn : UNEXPECTED idcode: 0x6ba02477
Error: expected 1 of 1: 0x0bb11477</span>As you can see, PID 3748 has a corrupt serial number. Consequently, when I try to connect to it, OpenOCD ends up selecting one of the other ST-Links.
The ST-Link Utility can access the serial number successfully (no corruption). That would imply the issue is somewhere with OpenOCD.
I’m going to order another ST-Link/V2, but I suspect that won’t fix the issue.
Btw, this does not explain why the 3rd board can’t erase external NOR flash when another ST-Link is connected to the PC. I suspect USB messages are being incorrectly routed, but for some other reason than the corrupt serial number.
Cheers
David
Thanks for pointing this out. Indeed, the older ST-Link v2 do not report the serial number in a USB-compliant way and hence the stock OpenOCD doesn’t properly work with multiple instances of them.
The ST’s branch of OpenOCD uses very non-trivial modifications to its USB logic to support querying the serial number using a vendor-specific hack, however those changes were never merged into the mainstream OpenOCD and may break compatibility with other debug probes (hence our OpenOCD fork doesn’t include them).
As the issue only affects the older ST-Link 2.0 devices (not St-Link 2.1 or 3.x), we suggest simply moving on to the newer St-Link 2.1 (that uses newer firmware and also typically has a built-in COM port).
Btw, I have investigated the erasing of the external nor flash a little further. It’s not related to the serial number corruption discussed above. Given two similar boards with ST-Link/V2.1 &v3 are connected to the PC. I’ve noticed after openocd erases the external nor flash (via the flash plugin) it then attempts to program the flash by calling the <span>FLASHPlugin_ProgramAsync</span>(). However, that call suddenly gets re-directed to the second board, not the one being programmed.
Do you think the issue might lie with your Flash Plugin extension, or with the openocd main code?
Cheers
David
This is rather strange, as normally OpenOCD should not suddenly switch to another board.
In order to troubleshoot this, please check if the problem can be reproduced outside VisualGDB, with just one OpenOCD instance running. If not, please try understanding what set of circumstances triggers the problem (e.g. 2 OpenOCD instances are running and VisualGDB confuses the TCP ports of them).
If the problem happens with just 1 instance reliably, please double-check whether using the same command line (having the serial number hardcoded), but actually unplugging the second device changes anything. Please also let us know what exactly you observe when the call to ProgramAsync() jumps to the second board. Perhaps, something else is happening to the board that looks like it’s trying to run ProgramAsync().
Edit: there could be another source of issues when using multiple ST-Link adapters of different versions. Because historically OpenOCD had different internal drivers for ST-Link 1, 2 and 2.1, VisualGDB internally treats them as separate incompatible devices. So if you have just one instance of ST-Link v2 and one instance of ST-Link v2.1, VisualGDB would assume that each interface is unique and would not pass the serial number to OpenOCD. As OpenOCD now considers both devices equivalent, this would let it pick one interface arbitrarily. That said, it should happen at the beginning of the debug session and not between erasing and programming the FLASH memory.
We have also added a “Pass the USB serial number to OpenOCD even if just 1 device is present” setting to our OpenOCD GUI (VisualGDB Project Properties -> Debug -> Advanced) that will override the default serial number behavior. Please feel free to install the OpenOCD update via the VisualGDB Package Manager and enable the new setting.
Hi, I have good news. The change you made so the USB serial number is always passed to OpenOCD has fixed my problem. I suspect when programming the external Flash the USB link was dropping out and reconnecting to the wrong board. Now with your fix it’s staying with the right board and works well.
Thank you for support.
Cheers,
David
- You must be logged in to reply to this topic.