Sample applications that enable USB and error if it fails are incompatible with boards like thingy53 with auto-USB init (i.e. USB CDC for logging)

[nordicjm]

Describe the bug
Sample applications that enable USB usually exit if it fails, this is a problem if a board uses USB CDC for it's main UART as this will be enabled during boot-up, but applications will also enable this, which will fail, and if the code exists, the sample will not run.
Example: smp_svr

To Reproduce
Build application for device with USB CDC UART, e.g. bl654_usb or thingy53, image will boot, show USB error, then be inoperable

Expected behavior
Applications to work regardless of USB CDC configuration

Impact
Showstopper

Environment (please complete the following information):

• Commit SHA or Version used: 510dca5

[nordicjm]

This also impacts mcuboot

[jfischer-no]

This is certainly not a bug.

USB device support should be generally enabled from the application, which all samples in the tree do. Apart from simple applications that only contain usb_enable(), we have examples that register specific devices or status callback before USB device support is enabled. With new USB device support, the settings of device properties also moved into the application. Briefly, all samples are supposed to behave uniformly and if USB support is already turned on, fail, they do.

How is it possible that USB device support is not only enabled by the application? Some boards, like bl654_usb, configure CDC ACM UART as logging backend and enable Kconfig option USB_DEVICE_INITIALIZE_AT_BOOT. (Whereby bl654_usb is still a good example, other boards have cumbersome configurations and probably do not work as desired.) To enable USB_DEVICE_INITIALIZE_AT_BOOT at board level is not a good solution, it is not generic although the problem can be solved generically, as shown in #40645.

Anyway, as expected, bl654_usb does not work out of the box with USB device support samples, this limitation was explicitly pointed out ahead of time, and the author of this issue even accepted it.
"does not work out of the box" means the user has to disable CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT at build time, cmake -DBOARD=bl654_usb -DCONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n, or disable it in the application's prj.conf, like

diff --git a/samples/subsys/usb/cdc_acm/prj.conf b/samples/subsys/usb/cdc_acm/prj.conf
index 7614fbb1a43..55e4fe9217f 100644
--- a/samples/subsys/usb/cdc_acm/prj.conf
+++ b/samples/subsys/usb/cdc_acm/prj.conf
@@ -8,3 +8,4 @@ CONFIG_USB_DEVICE_LOG_LEVEL_ERR=y
 CONFIG_SERIAL=y
 CONFIG_UART_INTERRUPT_DRIVEN=y
 CONFIG_UART_LINE_CTRL=y
+CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n

Please accept it. The way out is whatever comes after shields/snippets where idea from #40645 will be acceptable.

[nordicjm]

Can you not close unresolved bugs? This is a real issue that needs addressing for thingy53, where it needs to be fixed is a question in its own right but closing bugs that are bugs and unresolved helps no-one and just hides that there is an issue