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

[Kenneth]

I did not think of that, we just released v2.4.0, can you see if you observe the same there before I report it? I left office, so not able to test until next week.

Kenneth

[Rory]

I'm getting the same behavior on NCS v2.4.0. It is still only happening when I compile for nrf5340dk_nrf5340_cpuapp_ns. I tried running in the debugger, and when I re-insert the USB cable, the application is hitting the SPU Handler, which makes me think the something is using a secure peripheral when it shouldn't be.

Again, this works fine when compiled for nrf5340dk_nrf5340_cpuapp.

[Kenneth]

Sorry for the late reply, I was out office, but I added this to internal jira now, will let you know when I hear back from the developers.

Kenenth

[Nathan]

I've run into this same issue and would like to be notified when a solution is available. I'm building for target nrf5340dk_nrf5340_cpuapp_ns using NCS v2.4.0, though I've taken the peripheral_uart sample as my starting point instead of the bare cdc_acm example. 

[ovrebekk]

Hi Nathan

This issue is still under investigation on our side, and we haven't yet gotten to the bottom of it. Kenneth is currently on vacation, but he will follow up on this when he's back. 

Best regards
Torbjørn

[Kenneth]

It looks like this issue is unfortunatly making slow progress internally.

I can find from your intial description of the case that you have found a workaround where you simply don't disable USB, are you able to use this workaround in your application? Instead of waiting for the team internally find the root cause of the issue.

Kenneth

[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