RT1170 USB CDC stuck in kStatus_USB_Busy even when breakpoint is placed in non-executing code

[Harisha]

Hi,

I am working on i.MX RT1170 (M7 core) with:

SDK version 25.09

FreeRTOS

USB CDC (Virtual COM)

CAN-FD running in parallel

Initialization is correct.
USB enumeration completes successfully.
CAN-FD and USB communication both work properly during normal execution.

System behavior under normal conditions:

CAN-FD receives data correctly

USB CDC sends data to PC (Tera Term) successfully

USB_DeviceCdcAcmSend() works as expected

USB callback executes and busy flag clears properly

Issue:

If I place a breakpoint anywhere in the project — even in code that is not currently executing (for example in main() after initialization or in some unrelated function) — the system continues running, but USB CDC eventually gets stuck.

Important observations:

The breakpoint is NOT being hit.

Code continues running normally.

FreeRTOS tasks continue executing.

CAN-FD continues working correctly.

Only USB CDC stops functioning.

After this happens:

USB_DeviceCdcAcmSend() returns kStatus_USB_Busy

USB transfer callback is not called

Busy flag never clears

USB communication stops permanently until board reset

Even using printf() during runtime can sometimes trigger similar behavior.

Configuration:

#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 2
#define USB_DEVICE_INTERRUPT_PRIORITY (6U)

USB task stack size:

#define APP_TASK_STACK_SIZE 8000L

Stack overflow is not observed.
System does not crash.
Only USB CDC communication becomes stuck.

Questions:

Why does USB CDC get stuck even when the breakpoint is placed in non-executing code?

Does the debugger momentarily halt the M7 core in a way that affects USB HS timing?

Can delayed servicing of USB interrupts cause the CDC driver to remain in kStatus_USB_Busy permanently?

Is this expected behavior of the USB HS controller (EHCI) when the CPU is halted?

What is the recommended way to debug USB CDC on RT1170 without causing transfer corruption?

Any guidance would be greatly appreciated.

Thank you.

[mayliu1]

Hi @Harisha 

Thank you so much for your interest in our products and for using our community.

Regarding your issue, I recommend trying the following adjustments:

1：Set the USB interrupt priority to the highest priority that FreeRTOS can manage to ensure that USB receives timely interrupt service.

2：Lower the interrupt priorities of other modules (such as CAN-FD in your application) so they do not stop USB processing.

Please try these changes and test again.

Best Regards

mayLiu