@tannewt: here's Claude's diagnosis and possible fixes. I cannot judge which is the best, so I'll leave it to you, or just tell me which one sounds good to you and I'll continue my session with that choice.
Claude wrote this:
Problem
On nordic_nrf54lm20dk, builds of main since a42fa71 (#11457) boot, mount CIRCUITPY, and run code.py, but the USB CDC console never answers. The J-Link VCOM (uart20) still shows the MCUboot and CircuitPython boot logs, plus usbd_cdc_acm: Ring buffer full, discard data.
Cause
- USB class names for CDC ACM are
cdc_acm_<n>, where n is the devicetree instance number (usbd_cdc_acm.c).
- Adaboot's
nrf54lm20dk.dtsi, which sysbuild applies to the app image too, adds cdc_acm_uart0 on zephyr_udc0 for bootloader mcumgr. In the app devicetree it becomes instance 0, and cdc_acm_console/cdc_acm_data from app.overlay shift to 1 and 2.
supervisor/usb.c registers the hardcoded names "cdc_acm_0"/"cdc_acm_1" (L302, L354) but opens the console via DT_NODELABEL(cdc_acm_console) (L266). The host enumerates cdc_acm_uart0, which the app doesn't use (app mcumgr is BLE-only), and console output goes to an unregistered instance.
Changing the names in usb.c to "cdc_acm_1"/"cdc_acm_2" restores the REPL on the DK. That was a diagnostic only, since it breaks every other board. Only the nRF54LM20 DK dtsi adds a CDC ACM node today, so other boards are not affected yet.
Possible fixes
- A. In
usb.c, find each class's registered name by walking the USB class list and matching c_data->priv against DEVICE_DT_GET(DT_NODELABEL(cdc_acm_console))/cdc_acm_data, instead of hardcoding instance numbers. Robust to any devicetree ordering, but relies on Zephyr's class-list layout rather than a documented API. Claude's suggestion.
- B. Set
cdc_acm_uart0 to status = "disabled" in the app devicetree for this board. Smallest change, but the next Adaboot dtsi that adds a CDC node breaks the console the same way.
- C. In Adaboot, keep bootloader-only USB nodes (and
zephyr,uart-mcumgr) out of the app image. Cleanest split between the images, but a broader build change.
@tannewt: here's Claude's diagnosis and possible fixes. I cannot judge which is the best, so I'll leave it to you, or just tell me which one sounds good to you and I'll continue my session with that choice.
Claude wrote this:
Problem
On
nordic_nrf54lm20dk, builds ofmainsince a42fa71 (#11457) boot, mount CIRCUITPY, and runcode.py, but the USB CDC console never answers. The J-Link VCOM (uart20) still shows the MCUboot and CircuitPython boot logs, plususbd_cdc_acm: Ring buffer full, discard data.Cause
cdc_acm_<n>, wherenis the devicetree instance number (usbd_cdc_acm.c).nrf54lm20dk.dtsi, which sysbuild applies to the app image too, addscdc_acm_uart0onzephyr_udc0for bootloader mcumgr. In the app devicetree it becomes instance 0, andcdc_acm_console/cdc_acm_datafromapp.overlayshift to 1 and 2.supervisor/usb.cregisters the hardcoded names"cdc_acm_0"/"cdc_acm_1"(L302, L354) but opens the console viaDT_NODELABEL(cdc_acm_console)(L266). The host enumeratescdc_acm_uart0, which the app doesn't use (app mcumgr is BLE-only), and console output goes to an unregistered instance.Changing the names in
usb.cto"cdc_acm_1"/"cdc_acm_2"restores the REPL on the DK. That was a diagnostic only, since it breaks every other board. Only the nRF54LM20 DK dtsi adds a CDC ACM node today, so other boards are not affected yet.Possible fixes
usb.c, find each class's registered name by walking the USB class list and matchingc_data->privagainstDEVICE_DT_GET(DT_NODELABEL(cdc_acm_console))/cdc_acm_data, instead of hardcoding instance numbers. Robust to any devicetree ordering, but relies on Zephyr's class-list layout rather than a documented API. Claude's suggestion.cdc_acm_uart0tostatus = "disabled"in the app devicetree for this board. Smallest change, but the next Adaboot dtsi that adds a CDC node breaks the console the same way.zephyr,uart-mcumgr) out of the app image. Cleanest split between the images, but a broader build change.