Problem: USB-C + STLINK-V3 USB mini enumeration Conflict while connect to Windows or Linux together or in sequence

[islavv]

Spent two days of trying to see printf via USART1 from U585 and U575 boards. Was trying to load  BLE via DFU on B-U585 and get it work but USART1 became silent. (Wrote separate post on B-U585I-IOT2A as documentation nightmare). Problem: USB-C + STLINK-V3 USB mini enumeration Conflict. Need confirmation from support and opened ticket. On Windows to revive USART1 needed to go to regedit and clean all enumerations of old USB from all previous controllers but the combination of USB-C and ST-LINK mini connected to same Windows or Linux host IMHO looks dangerous 

• Setup: STM32U575ZI-Q or B-U585I-IOT2A board with:
• USB-C connected to native USB peripheral (for DFU)
• STLINK-V3 connected via USB (for debug + Virtual COM Port)
• Issue: When both interfaces are connected to Windows 10 or Ubuntu — either in sequence or simultaneously:
• DFU mode consistently enumerates and stays visible
• Virtual COM Port (VCP) fails to transmit data, even though it appears in the device list
• No output from HAL_UART_Transmit() or similar code reaches the host

Observed Behavior

Problem Description

• Setup: STM32 board with both USB-C (for native USB/DFU) and STLINK-V3 (for debug + VCP)
• Issue: When both interfaces are connected — either in sequence or simultaneously — USB enumeration becomes unreliable:
• DFU device fails to appear
• STLINK-V3 disconnects or freezes
• VCP port disappears intermittently
• Observed Behavior:
• Connecting USB-C first, then STLINK-V3 → DFU sometimes lost
• Connecting STLINK-V3 first → VCP appears, but DFU fails to renumerate
• Simultaneous connection → unpredictable enumeration order and port visibility

Suspected Causes

• USB Role Conflict: Host/device negotiation may be disrupted when both USB interfaces assert presence
• Power Domain Overlap: STLINK-V3 and USB-C may share or compete for VBUS, causing brownouts or unstable enumeration
• STLINK-V3 Firmware Behavior: May assert reset or interfere with USB peripheral during debug session

Temporary Workarounds

• Connect Only One Interface at a Time: Avoid simultaneous USB-C + STLINK-V3 usage unless explicitly isolated
• Firmware Isolation: Ensure USB peripheral is not initialized while STLINK is active unless needed

[FBL]

Hi @islavv 

Do you reproduce the same issue using provided examples here and here https://github.com/STMicroelectronics/STM32CubeU5/tree/main/Projects/B-U585I-IOT02A/Applications/USBX/Ux_Device_HID_CDC_ACM ?

[islavv]

Sorry for delay in answering. I was programming sample I recently uploaded to support and community that shows that USART1 under USBX is not stable working in different combitantions of Cube Programmer and IDE debugging and results in looosing printf completely. Requires closing Programmer and re-initialize Debug. Final reasons /solution is not understood but i succeeded to repeat Debug in IDE that reinstantiate printf in USART1. My opinion on the quality of software and its support in this relation is below floor. But I respect STM as hardware company. No chance to Accept Thanks . I attach my app and you can compile and play. Only USBX allows to use USART1 console otherwise whole prinitf disappears

[S C]

Hello,

I had a look at your posts as far as ST-Link seems concerned, and I have some information to share and questions to ask:

Regarding the USB on the probe, the STLINK-V3 and target USB-C are fully different devices when seen from the host. Interferences may only come from the fact that the ST-Link controls the NRST or possibly the target supply, depending on JP4 configuration. To limit the impact of such interferences, I suggest to firstly disable the mass storage interface from the STLINK-V3 (to do this: run STLinkUpgrade from STSW-LINK007 | Software - STMicroelectronics, select "change type" and the firmware without mass storage; this will also update the STLINK-V3 firmware to the most recent version). Then, I suggest to plug the ST-Link first, for the use cases where the target power supply comes from it.

Regarding the bootloader, I'm not very familiar with the topic, but I suspect a possible conflict between the UART bootloader available through the ST-Link VCP and the USB DFU. According to the AN2606, the USB bootloader is selected by cable detection, while UART bootloader with 0x7F data on the UART. My understanding of your post is that either you attempted the UART bootloader while target USB cable is connected, or attempt some VCP communication with the target while it is in USB DFU mode, both things that are not possible according to me. You have to put the board in the right configuration for the bootloader you want to use, or for target user mode. If you still face some issue with this point, may you please provide more details, because I have not clearly understood what you want to do (bootloader UART, bootloader USB, debug VCP, ... ?)

Finally, I tried your application and found no issue with UART1 output through VCP ... at least up to the time the application falls in infinite loop because of WWDG, I've not investigated why. My first suspicion, if you loose completely the printf output, would be an issue at application side, and I won't be able to help. Please provide more details on the sequence to do to reproduce the issue, if you suspect a failure at ST-Link VCP level instead.

[islavv]

Thanks for answering. I undertstand now that USB DFU and VCP/Console mode are not friends and in some boards one need to push reset/user buttons in sequence to get to DFU. Enumeration is different animal. It is USB number that Windows gives to inserted device. I have couple different STM boards and after starting from USB5 I got  higher and higher number finishing on 15. Linux does not have this mess.VCP over USB is not working in a lot of time especially when using USBX. Also using IDE and Cube Programmer ruins VCP output. I have only couple samples working well. Did not see a lot of clean instructions and explanations on VCP.

[S C]

Hello,

Regarding the COM port incrementation, it is the default behavior on Windows which identifies devices with their VID/PID and SerialNum. It should be possible to disable this incrementation if you really want, but I do not recommend if you are not familiar with the mechanism behind. You could find on the web things around a IgnoreHWSerNum registry key, which will do it if you associate to the ST-Link VID/PID, but I'm not sure it still works (not tried since very long time). Note that this will probably impact the (optional) ability from tools to select an ST-Link by its Serial Num.

I don't know what to say regarding the VCP output. The flow was tested at ST-Link level with basic applications. If the UART sending by the application is OK (which was the case with your application when I tried it, at least up to the WWDG IT), it should remain working as long as data are provided on the UART. Note that there are some limit in baudrates (detailed in STLINK-V3SET UM2448 for instance). The fact that "IDE and Cube Programmer ruins VCP output" is obscure to me, for sure when using CubeProgrammer the application stops running, and when the application restarts the UART output should restart again. This would be a first point to double check.

[islavv]

I saw clear conflict of Cube IDE and Cube Programmer showing Device not ready for either side. Also I saw VCP went silent when using USBX.

In my experience, the complexity rises quickly when working with Azure RTOS components like ThreadX, USBX, and others. It also feels like ST’s current trend is to emphasize these stacks while providing only minimal support for bare‑metal applications.

To be fair, Azure RTOS brings extra functionality, but it hasn’t become a “miracle solution.” Much of the codebase is bulky and difficult to integrate, and not every vendor ecosystem has been able to absorb it smoothly. This needs to  be considered by STM to improve bare metal solution support. The embedded world doesn’t need a repeat of the decades of legacy Microsoft experience we’ve seen in desktop operating systems.