USB Driver update broke my ST-Links

Sysprogs forums Forums VisualGDB USB Driver update broke my ST-Links

Tagged: 

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #26201
    davidoz
    Participant

    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
    David

    • This topic was modified 4 years, 5 months ago by support. Reason: formatting
    #26206
    support
    Keymaster

    Sorry, 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.

    #26211
    davidoz
    Participant

    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

     

    #26212
    support
    Keymaster

    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).

    #26214
    davidoz
    Participant

    Yes, that makes sense.  I’ll purchase an ST-Link/V3 to replace the old one.  Thanks for your help.

    #26215
    davidoz
    Participant

    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

    #26219
    support
    Keymaster

    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.

    • This reply was modified 4 years, 5 months ago by support. Reason: mentioned the new OpenOCD setting
    #26435
    davidoz
    Participant

    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

    #26444
    support
    Keymaster

    Good to know it works. Feel free to reach out to us again if you encounter further issues.

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.