nrf5340: USBD disabling itself on USBD_DETACHED event

[Rory]

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!

[Kenneth]

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

[Rory]

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);
		}

[Nathan]

Sorry I'm not the original poster of the issue, I just also ran into it using a different example as a starting point and reported that here instead of creating a new issue for the same problem. 

The original poster reported that the workaround does not work if the application is built using the non-secure compilation target, which is unfortunately what I'm using. I'm working on other parts of my project at the moment so I can wait a bit longer, I'll consider switching to the other target when I have to get back to working on this part of the project. 

[Rory]

No, we are not using this workaround in our application. This workaround was put in simply to identify the function causing the SPU error as part of the debugging process.

This workaround isn't going to be suitable our application because we must disable USB when unplugged to save on power consumption.

[Kenneth]

Hello,

Sorry for the time this is taking, before the developers can start to look into making a workaround they need to ensure the designers understand the root cause (it's only then they can be sure that any workaround will handle the issue). The issue have been recreated on actual boards, and next step is to recreate the issue by simulation (to find the root cause), simulation is a time consuming task both to setup but not least running the actual test in simulation (the entire chip is simulated so they need to simplify the software to for instance avoid any busy waits etc to reduce the simulation time). I expect simulations will be finished sometime next week, and I will update you when I learn more.

Kenneth

[Kenneth]

Hello again,

I can confirm they have been able to recreate the issue in simulation, so they understand more of what exactly is causing the issue, they are now looking into finding the least intrusive workaround. This will take some time, since workaround needs to be confirmed by actual test on the board but also simulations. I will update you when I know more.

Kenneth

[Kenneth]

Hello,

Good news!

They have created a pull request with the changes required to handle the issue (all changes in nrfx_usbd.c):
https://github.com/zephyrproject-rtos/zephyr/pull/63029

Please try the changes and report back to me.

Best regards,
Kenneth

[Rory]

Thanks for the update. I have integrated the changes in your pull request, and haven't had a single occurrence of the SPU error yet! It's working perfectly so far, and so I suspect the problem is fixed. Thanks for all your help.