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