Why could Mass Storage Access on the STM32L4 Disconnect a Debugger

[TG]

I'm currently using an STM32L4 on a custom board, trying to implement is a composite USB class that allows CDC and MSC at the same time.

I am working with the STM generated classes for CSC and MSC, and have written an intermediate composite interface to delegate the call to each of the classes as required.

Both classes are working just fine, and I can issue the device commands, and access the onboard storage as expected. Once the device is attached to the computer, and Windows has read enough information through MSC to open a window displaying the files on the device, the debugger stops working, and TrueSTUDIO starts saying:

Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...

The light on the ST-Link V2 stays solid green and I am unable to insert breakpoints, step through the code, or any other debugger related activities. The USB on the device itself still functions, and I am able to send the device commands via CDC and access the SD card via MSC as normal.

This bug only appears once mass storage is actually read from the host, if MSC is skipped in software, the debugger does not experience this problem. I'm never manually re-configuring any pins on the device in the mass storage code, and I am unsure how the firmware itself could be losing connection to the debugger.

I've tried:

• Swapping debuggers (Tried J-Link as well)
• Swapping boards (issue does not appear to be our hardware, unless there is a defect in the chip itself)
• Updating all software/firmware on debugger and computer
• Removing all USB hubs in between device and computer

Has anyone experienced something similar to this? Any ideas are appreciated, since bringing this feature into the development branch will interfere with debugging.

[Tesla DeLorean]

Generally not.

Primarily what will is going into low-power or sleep modes (via WFI, etc), and interfering or reconfiguring the pins used by the debugger, nominally PA13/PA14, but perhaps also PB3,PA15, etc.

Some CubeMX settings/configurations may actively disable SWD/JTAG connectivity.

You're not going to be able to breakpoint, or single-step, USB code. Use instrumentation to understand flow/interaction within your code.

Use a UART, report peripheral and clock settings, etc in the condition where disconnection is occuring, so you can better understand the system's internal state.