• State Not Answered
  • Replies 3 replies
  • Subscribers 97 subscribers
  • Views 71 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 364282
Options

nRF Connect SDK Intermediate, Lesson 9, Exercise 4, problems with nrF53

John-Eric Kamps

Hi

SDK 3.4.1

Custom Board but with working USB-Interface from App

https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-4-dfu-over-usb/

If I configure it like described, I will get no USB-CDC device. The Serial port is present.

From my current understanding of mcuboot it is wrong to setup

STEP 1.1 - Configure serial recovery to use CDC_ACM, which by default uses the USB
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_UART=y

It should be

STEP 1.1 - Configure serial recovery to use CDC_ACM, which by default uses the USB
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_UART=n
CONFIG_BOOT_SERIAL_CDC_ACM=y
But with that I got an error:
2026-10-30T09:39:03.377Z C:/ncs/toolchains/4f5b6ad6dd/opt/zephyr-sdk/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: zephyr/subsys/usb/device_next/libsubsys__usb__device_next.a(usbd_cdc_acm.c.obj):C:/ncs/v3.4.1/zephyr/subsys/usb/device_next/class/usbd_cdc_acm.c:1386: multiple definition of `__device_dts_ord_190'; zephyr/libzephyr.a(cdc_acm.c.obj):C:/ncs/v3.4.1/zephyr/subsys/usb/device/class/cdc_acm.c:1229: first defined here

Is the usb-next driver not final in mcuboot for nrf53?

Best regards 

John

  • 0

    For documentation:

    • Clean exercise 4
    • Changes as diff:
      diff --git a/l9/l9_e4/sysbuild.conf b/l9/l9_e4/sysbuild.conf
index 277d0a0..3b3365f 100644
--- a/l9/l9_e4/sysbuild.conf
+++ b/l9/l9_e4/sysbuild.conf
@@ -1,4 +1,5 @@
 # Add MCUboot
 SB_CONFIG_BOOTLOADER_MCUBOOT=y
-SB_CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM=y
+#Fix Build warning
+SB_CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM=n
 
diff --git a/l9/l9_e4/sysbuild/mcuboot/boards/nrf5340dk_nrf5340_cpuapp.overlay b/l9/l9_e4/sysbuild/mcuboot/boards/nrf5340dk_nrf5340_cpuapp.overlay
index 131d953..539601e 100644
--- a/l9/l9_e4/sysbuild/mcuboot/boards/nrf5340dk_nrf5340_cpuapp.overlay
+++ b/l9/l9_e4/sysbuild/mcuboot/boards/nrf5340dk_nrf5340_cpuapp.overlay
@@ -7,4 +7,8 @@
 };
 
 /* STEP 2.1 - Configure CDC ACM */
-
+&zephyr_udc0 {
+	cdc_acm_uart0: cdc_acm_uart0 {
+		compatible = "zephyr,cdc-acm-uart";
+	};
+};
diff --git a/l9/l9_e4/sysbuild/mcuboot/prj.conf b/l9/l9_e4/sysbuild/mcuboot/prj.conf
index e736ae2..366f8f3 100644
--- a/l9/l9_e4/sysbuild/mcuboot/prj.conf
+++ b/l9/l9_e4/sysbuild/mcuboot/prj.conf
@@ -20,7 +20,8 @@ CONFIG_NCS_APPLICATION_BOOT_BANNER_STRING="MCUboot"
 
 # Step 1.1 - Configure serial recovery to use CDC_ACM, which by default uses the USB
 CONFIG_MCUBOOT_SERIAL=y
-CONFIG_BOOT_SERIAL_UART=y
+CONFIG_BOOT_SERIAL_UART=n
+CONFIG_BOOT_SERIAL_CDC_ACM=y
 
 # Disable console UART, since Serial Recovery uses UART
 CONFIG_UART_CONSOLE=n
@@ -33,3 +34,8 @@ CONFIG_MCUBOOT_INDICATION_LED=y
 
 
 # STEP 1.2 - Enable USB subsystem 
+CONFIG_USB_DEVICE_STACK_NEXT=y
+CONFIG_MULTITHREADING=y
+CONFIG_UART_USE_RUNTIME_CONFIGURE=y
+CONFIG_UART_LINE_CTRL=y
+#CONFIG_USBD_CDC_ACM_CLASS=y
\ No newline at end of file
    • Notes:
      • Deprecated USB_DEVICE_DRIVER and USB_DEVICE_STACK is enabled --> Looks wrong
      • MCUMGR_TRANSPORT_UART is disabled --> Looks wrong
      • Failure: region `FLASH' overflowed by 7908 bytes
    • Will increase bootloader Flash size, because USB Next need more from my searching

    Questions:

    • Why it is not needed to change "zephyr,uart-mcumgr" from "uart0" to "&cdc_acm_uart0" in mcuboot overlay?
      • Like later for the application.
  • 0

    Hi John,

    That is correct, usb next is not an option for the nrf5340. It will alsways select the legacy USB device stack. The kconfig to enable USB next selects only Next for nRF54 series devices

    config BOOT_SERIAL_CDC_ACM
	bool "CDC ACM"
	select USB_DEVICE_STACK if !(SOC_NRF54LM20A || SOC_NRF54LM20B)
	select USB_DEVICE_STACK_NEXT if (SOC_NRF54LM20A || SOC_NRF54LM20B)

    We'll look into the exercise and double check if and what is wrong/not working for the non nRF54LM20 devices.

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Hi again,

    The author agrees that a fix is required. They will make an update to the course to either highlight the different requirement for the SoCs and/or patch the issue. Resolution is TBD and depends on what is supported in the SDK tag.

    Reassigning the case to them and leaving it as open.

    Thank you for reporting this,

    Kind regards,
    Andreas

Related
Terms of service