How to debug USBX-based examples ¶
This page highlights the main debug entry points for USBX examples and the configuration switches that make early bring-up easier.
Recommended debug sequence ¶
When a USBX example does not behave as expected, debug in this order:
-
Confirm the selected USB role and physical USB instance.
-
Confirm the PCD or HCD component is enabled consistently with that role.
-
Confirm at least one matching USB class is enabled.
-
Check USBX initialization return codes.
-
Inspect descriptors, endpoint sizes, and memory-pool sizing.
-
Inspect controller IRQ flow, attach/remove events, and transfer callbacks.
Useful debug-oriented configuration switches ¶
The current USBX configuration flow exposes several options that are useful during bring-up.
|
Setting |
Typical bring-up usage |
Debug value |
|---|---|---|
|
|
Enable while validating the integration |
Catches common middleware misuse |
|
|
Enable during early development |
Helps detect invalid API arguments |
|
|
Keep enabled in debug builds |
Surfaces internal assumptions earlier |
|
|
Increase if more trace history is needed |
Preserves more diagnostic context |
|
|
Enable for device-connection event tracing |
Helps confirm connect, disconnect, suspend, and resume events |
Role-specific checks ¶
Device-mode checks ¶
Focus on:
-
Device descriptor content
-
Endpoint addresses and packet sizes
-
VBUS sensing and cable behavior
-
Reset, suspend, resume, and enumeration events
Host-mode checks ¶
Focus on:
-
HCD startup and port-power sequencing
-
Device insertion and removal events
-
Class activation results
-
ED, TD, and ISO TD pool sizing for the active topology
FreeRTOS example checks ¶
If the example uses FreeRTOS, also verify:
-
USBX thread priorities are not starved by unrelated tasks.
-
The required FreeRTOS advanced APIs are enabled.
-
The generated application thread sizes are adequate for the class logic.
Links ¶
-
USBX FAQ USBX FAQ
-
USBX Best practices USBX Best practices
-
How to initialize USBX How to initialize USBX