nrf5340: USBD disabling itself on USBD_DETACHED event

While developing on the nRF5340, I noticed that the USB CDC ACM driver I had been using as the Zephyr console, shell, and log backend didn't seem to want to re-enumerate when the USB port was unplugged and then plugged back in.

To test this behavior, I have compiled the zephyr/samples/subsys/usb/cdc_acm example for the nrf5340dk_nrf5340_cpuapp_ns board and fully erased and flashed it on my nRF5340-DK. 

The USB device port does enumerate and work properly the first time it is plugged in. I get a virtual COM port and can open a terminal emulator and the USB console echoes each character I type. If I unplug the USB device port, wait a few seconds, and plug it back in, the device does not enumerate, and the previous virtual COM port is not present.

I've included the hex file usbd_not_reconnecting.hex which is based on NCS 2.3.0 and compiled for the nrf5340dk_nrf5340_cpuapp_ns.

usbd_not_reconnecting.hex

In an effort to try to discover the root cause, I noticed that nrfx_usbd_disable() is called in zephyr/drivers/usb/device/usb_dc_nrfx.c when handling the USBD_DETACHED usbd_pwr_event. As an experiment, I tried commenting out the call to nrfx_usbd_disable() in that handler, and this appears to completely fix the problem.

	case USBD_DETACHED:
		ctx->ready = false;
		//nrfx_usbd_disable();
		err = hfxo_stop(ctx);
		__ASSERT_NO_MSG(err >= 0);

		LOG_DBG("USB Removed");

		if (ctx->status_cb) {
			ctx->status_cb(USB_DC_DISCONNECTED, NULL);
		}
		break;

Please advise how we should move forward with this workaround. I can implement this workaround in a private fork of the sdk-zephyr repository, but this bug will affect anybody using the usbd_nrfx driver, so it might be worth fixing in the next NCS release.

Thanks!

Parents
  • Hello,

    Can you show me some schematic around the USB (and in specific VBUS pin) on the nRF5340? Looking at the code in usb_dc_nrfx.c I can see that (as you write) that nrfx_usbd_disable() is called on USBD_DETACHED, however I can also see that on USBD_ATTACHED that nrfx_usbd_enable() should be enabled again, so I can't see that this should cause any problem. Are you able to debug whether USBD_ATTACHED occurs here or not?

    Edit: By any chance have you used CONFIG_USB_NRFX_ATTACHED_EVENT_DELAY?

    Kenneth

  • I'm seeing this behavior on the Nordic Semiconductor nRF5340-DK Rev. 2.0.0

    The schematic can be found in the Hardware files 2_0_0.zip download here.

    Edit: I have confirmed that CONFIG_USB_NRFX_ATTACHED_EVENT_DELAY is set to 0. I tried setting it to 700ms like the Thingy:53 defconfig uses, and it made no difference in behavior.

    Also, I am seeing nrfx_usbd_enable() below hitting a breakpoint in the debugger when I plug the USB cable back in, but I am still unable to get the previous virtual COM port to enumerate the second time.

    	switch (pwr_evt->state) {
    	case USBD_ATTACHED:
    		if (!nrfx_usbd_is_enabled()) {
    			LOG_DBG("USB detected");
    			nrfx_usbd_enable();
    			err = hfxo_start(ctx);
    			__ASSERT_NO_MSG(err >= 0);
    		}

  • Hmm.. It seems to work here, I simply unplug nRF USB several times:

    Kenneth

  • Kenneth,

    I am seeing different behavior. Can you please provide the .hex file you used in your test? Are you compiling and running this on the nRF5340-DK v2.0.0?

    I am not seeing the same behavior at all.

    After I unplug it for a few seconds, and plug it back in, the device does not resume and get re-configured.

    Why does your log show the Device resumed as it is unplugged? My log does not show this.

Reply
  • Kenneth,

    I am seeing different behavior. Can you please provide the .hex file you used in your test? Are you compiling and running this on the nRF5340-DK v2.0.0?

    I am not seeing the same behavior at all.

    After I unplug it for a few seconds, and plug it back in, the device does not resume and get re-configured.

    Why does your log show the Device resumed as it is unplugged? My log does not show this.

Children
Related