Debug while running as a USB device (FRDM-K66F)

[threepoint]

Summary: I'm trying to understand why I can't simultaneously debug the HID composite audio device sample code (frdmk66f_dev_composite_hid_audio_unified_freertos) on my FRDM-K66F while also using it as a USB device with my host machine; I can only do one or the other.

Details: With only the DAPLink / SDA USB port (clockwise of the Ethernet port when the board is viewed from above) attached to my host computer, I am able to deploy and debug the sample code with no problems. While the code is running (not stopped in the debugger), I then connect the "device" USB port (counterclockwise of Ethernet port) to my host. I would expect to see new audio in and audio out ports appear on my host, but this does not happen. However, if I stop debugging, disconnect both cables, and then reconnect ONLY the device USB port, I see both new audio ports appear and can then use the board to play back and record audio, as expected.

I have also had similar problems in the past, unrelated to audio, where I am trying to run the board as a USB device while wanting to debug it. It seems that I can only do one or the other, which makes developing a bug-free USB device exceptionally challenging since I can't pause code execution and inspect data.

Am I doing something wrong here, or is there some inherent limitation in either the FRDM-K66F or MCUXpresso that I haven't seen mentioned anywhere?

Thank you so much for any help!

[ErichStyger]

About

Press the Continue button. (I tried disabling the "break at main()" feature by going to Project Settings -> Run/Debug Settings -> Edit... -> Startup and disabling "Set breakpoint at: main" and enabling "Resume" but this did not prevent MCUXpresso from still breaking at main() – any ideas?)

This works for me:

I'm using IDE 11.4.1 with the latest LinkServer/J-Link/P&E, and here it works. But I remember that with earlier versions sometimes this was not functional.

I suggest you check your Breakpoints view if you have other breakpoints set in main()?

[ErichStyger]

Generally speaking: the USB host (you PC) is polling your USB device. If you debug your device and stop the target (e.g. halting, stepping) you pause the communication with the host. So from the host point of view, the device does not respond any more, so the host decides to disconnect the device.

If you want to deal with this situation, you need to start/stop the target and the host in synchronous way: this is not easily possible with a host PC and an embedded target.

Still, you can run usually to your first breakpoint, but if this breaks communication, that's it.

What I do in such situation if it is about the USB protocol to debug, I'm using a USB analyzer (e.g. see https://mcuoneclipse.com/2019/09/01/programming-the-esp32-with-an-arm-cortex-m-usb-cdc-gateway/), or I perform some logging (UART, RTT, USB CDC, ...) with a logging framework like this one: https://mcuoneclipse.com/2020/06/01/mculog-logging-framework-for-small-embedded-microcontroller-syst...

I hope this helps,

Erich

[threepoint]

@ErichStyger thanks so much for your reply!

If you debug your device and stop the target (e.g. halting, stepping) you pause the communication with the host. So from the host point of view, the device does not respond any more, so the host decides to disconnect the device.

I'm not sure that this is exactly my scenario. Here would be my steps to reproduce this behavior:

1. Disconnect the board completely from the host, reboot the host, and open MCUXpresso.
2. Connect only the DAPLink / SDA port from the board to the host.
3. Press the Debug button in MCUXpresso and wait for the program to load.
4. Press the Continue button. (I tried disabling the "break at main()" feature by going to Project Settings -> Run/Debug Settings -> Edit... -> Startup and disabling "Set breakpoint at: main" and enabling "Resume" but this did not prevent MCUXpresso from still breaking at main() – any ideas?)
5. With the sample code now running, but the device USB port having not yet been attached to the host, attach the port now.

Expected behavior: Since the host is seeing the device for the first time and no interruptions occur in program flow after the device is first attached, the device should enumerate normally.

Actual behavior: No device is seen by the host.

Maybe I am missing something in my mental model of how this is supposed to work? Corrections would be very welcome!

[ErichStyger]

Ok, thanks for the details what you are trying to do. I was assuming that you want to debug the USB stack, while running, and this is what I was referring to.

Your use case works on my side (K22FX, J-Link and LinkServer) with the USB (CDC) stack:

a) run the debugger, target running

b) plug in USB cable to the host

c) device enumerates properly on the host

I'm using IDE 11.4.1, if that matters.

The other thought I have: check your power supply to the board, as a brown-out could affect debugging too.