nRF SDK15 and USB Support

[AGlass0fMilk]

Description

Update - USB Implementation Done - Pull Request Merged

I have finished the implementation for the USBPhy on the nRF52840 platform. I have put in a pull request so hopefully it should be released in master soon.

You can check out my development branch here.

Please note the development branch has been updated to work with Nordic SDK version 15!

USB Basic Tests

test case	status
usb control basic test	✔️ PASSING
usb control stall test	✔️ PASSING
usb control sizes test	✔️ PASSING
usb control stress test	✔️ PASSING
usb device reset test	✔️ PASSING
usb soft reconnection test	✔️ PASSING
usb repeated construction destruction test	✔️ PASSING
endpoint test data correctness	✔️ PASSING
endpoint test halt	✔️ PASSING
endpoint test parallel transfers	✔️ PASSING
endpoint test parallel transfers ctrl	✔️ PASSING
endpoint test abort	✔️ PASSING
endpoint test data toggle reset	✔️ PASSING

Serial USB Test

test case	status
cdc usb reconnect	✔️ PASSING
cdc rx single bytes	✔️ PASSING
cdc rx single bytes concurrent	✔️ PASSING
cdc rx multiple bytes	✔️ PASSING
cdc rx multiple bytes concurrent	✔️ PASSING
cdc loopback	✔️ PASSING
serial usb reconnect	✔️ PASSING
serial terminal reopen	✔️ PASSING
serial getc	✔️ PASSING
serial printf/scanf	✔️ PASSING
serial line coding change	✔️ PASSING

Table last updated 3/15/2019

Original Description

Hi,
I'm interested in moving up to the nRF52840 for a future project. The current nRF SDK supported by mbed is 14.2. The update for this was completed fairly recently. It looks like mbed is planning renewed support for the USB (see feature branch here: https://github.com/ARMmbed/mbed-os/tree/feature-hal-spec-usb-device), which would be great to have on the nRF52840.

The nRF SDK14.2 documentation lists the USB driver (and support for the nRF52840 in general) as "experimental" and not "production quality". Is there any plan to start updating to nRF SDK15 for production quality support for the nRF52840 and USB library? Might be something I'd like to help with.

@marcuschangarm have you looked into this? I vaguely remember that quite a bit changed in the structure of some drivers from v14.2 to v15.

Issue request type

[ ] Question
[X] Enhancement
[ ] Bug

[AGlass0fMilk]

Any word @marcuschangarm? I've started to work a bit with SDK V15 and it seems easy to switch over, however it would be quite mundane...

I'd be willing to help :)
[Mirrored to Jira]

[DL6AKU]

Also interested in SDK 15
[Mirrored to Jira]

[adbridge]

Internal Jira reference: https://jira.arm.com/browse/IOTDEV-1591

[AGlass0fMilk]

I have started my own implementation of USBPhyHw for the nRF52840 target. You can check out my code here:
https://github.com/AGlass0fMilk/mbed-os/tree/nrf52840-usb-hal

[AGlass0fMilk]

The current implementation is not functioning yet. I am having issues with hard faults when connecting USB. I am also not sure if my implementation completely follows the HAL spec.

If anyone could help it would be appreciated. I would love to see USB support for the nRF52840 out of the box for Mbed.

[AGlass0fMilk]

I added code from SDK 15.2 to fix the hang when enabling USB. The issue was related to errata 171 and 187 in the nRF52840 production IC.

I suspect the hard fault on reset when USB is already plugged in is caused by some USB interrupt happening before the rest of the USB stack has been initialized. There are a few other issues that are keeping it from working.

[0xc0170]

I suspect the hard fault on reset when USB is already plugged in is caused by some USB interrupt happening before the rest of the USB stack has been initialized. There are a few other issues that are keeping it from working.

Do you keep track of issues you are having ?

cc @c1728p9 (might be interested in this)

[AGlass0fMilk]

I suspect the hard fault on reset when USB is already plugged in is caused by some USB interrupt happening before the rest of the USB stack has been initialized. There are a few other issues that are keeping it from working.

Do you keep track of issues you are having ?

cc @c1728p9 (might be interested in this)

I have been in my head so far :) I just started this over the weekend so I haven't had much time to formally write up issues. I'll document them here shortly.

[marcuschangarm]

@TacoGrandeTX

[AGlass0fMilk]

I have been basing the USBPhyHw implementation for the nRF52840 off of this example from the Nordic SDK. It shows how to use the raw USBD HAL/Driver without Nordic's "class"-based USB profile system.

I'm in the middle of refreshing myself on USB in a NutShell and have pretty much only dealt with chip-level issues at this point so there's lots of room for improvement...

Here are the issues with the implementation that I have noticed:

First Issue

Status: Resolved

Description: When enabling the USBD peripheral by calling nrf_drv_usbd_enable the MCU would hang on the following loop:

mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_14_2/drivers_nrf/usbd/nrf_drv_usbd.c

Lines 1706 to 1709 in 0404701

	while (0 == (NRF_USBD_EVENTCAUSE_READY_MASK & nrf_usbd_eventcause_get()))
	{
	/* Empty loop */
	}

The READY event that was supposed to occur to break this loop would never happen. This was due to nRF52840 erratas 171 (USB might not power up) and 187 (USB cannot be enabled).

Solution: The workarounds for these issues are included in nRF SDK 15.2 (the most recent release) so I added them in to the nrf_drv_usbd.c driver included with mbed.

Second Issue

Status: Resolved

Description: When USB is already plugged into the target and a reset occurs (I saw this while resetting via debugger), Mbed will die. This occurs very early in the startup process (before the stdout UART has time to be configured) so I think it is related to a USB or Power interrupt. I'm guessing the interrupt occurs before the USB stack has been fully initialized (or perhaps before the static instance has been populated) and probably calls a function on some NULL pointer or something. I still have to look into this one a bit more.

Possible Solutions: Currently, the USBPhwHw_Nordic implementation uses the same logic as this example from the Nordic SDK. This means the usbd peripheral is enabled and started or stopped and disabled when USB-related power events happen. There are no flags to make sure the USB stack is ready to accept events from the USBPhyHw at this point, which I think could help solve this problem.

Actual Solution: My assumption above was correct. I simply added a flag that conditionalized whether the stack had called connect yet and was therefore ready to accept events. This prevents the USB event handlers from calling functions on NULL pointers or uninitialized USB objects.

Third Issue

Status: Resolved-ish

Description: USB events aren't synchronized and cause failures in the Nordic driver during the USB setup stage.

I kind of just slapped nrf_drv_usbd calls inside their counterparts in the USBPhyHw HAL API and hoped it would somewhat work. After spending a few hours debugging the first issue up there, I finally got to the point where USB-related events were being sent to the upper layers of the stack. Where I'm at now is that the usbd peripheral is successfully enabled, receives setup events from the host and sends them to the upper level of the stack. I believe when I was debugging, the place where the failure occurred was here:

mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_14_2/drivers_nrf/usbd/nrf_drv_usbd.c

Lines 1954 to 1962 in 0404701

	/* Setup data transaction can go only in one direction at a time */
	if ((NRF_USBD_EP_NR_GET(ep) == 0) && (ep != m_last_setup_dir))
	{
	ret = NRF_ERROR_INVALID_ADDR;
	if (NRF_USBD_FAILED_TRANSFERS_DEBUG && (NRF_USBD_ISO_DEBUG || (!NRF_USBD_EPISO_CHECK(ep))))
	{
	NRF_LOG_DEBUG("USB driver: Transfer failed: Invalid EPr\n");
	}
	}

So some synchronization needs to be introduced (should've listened to the HAL...) to prevent this check from failing.

Actual Solution: The nRF52840 USB hardware actually needs to know a lot about the control transfer stages the upper layers of the stack are currently in. This allows the hardware to automatically NAK packets that aren't in the correct sequence. It also complicates the HAL implementation a bit, but oh well. The fix was to keep track of the control transfer stages and trigger "hardware tasks" (you'll know what I mean if you're familiar with nRF chips) at the appropriate time, letting the hardware know when the OUT data stage is allowed, or the status stage is allowed, etc. Still a work in progress at this point.