USB without Softdevice Issue

[George Beckstien]

I ported the nRF52840 USB driver to work with Mbed-OS's USB Device stack. When building without the soft device, the following macros are removed from the compilation:

"SOFTDEVICE_PRESENT=1",
        "S140",
        "BLE_STACK_SUPPORT_REQD",
        "NRF_SDH_CLOCK_LF_XTAL_ACCURACY=7",
        "NRF_SD_BLE_API_VERSION=6",
        "NRF_SDH_ENABLED=1",
        "NRF_SDH_BLE_ENABLED=1",
        "PEER_MANAGER_ENABLED=1",
        "NRF_SDH_BLE_GATT_MAX_MTU_SIZE=23",
        "NRF_SDH_BLE_OBSERVER_PRIO_LEVELS=4",
        "NRF_SDH_BLE_GAP_EVENT_LENGTH=3",
        "BLE_ADV_BLE_OBSERVER_PRIO=1",
        "BLE_CONN_STATE_BLE_OBSERVER_PRIO=0",
        "BLE_CONN_PARAMS_BLE_OBSERVER_PRIO=1",
        "NRF_BLE_GATT_BLE_OBSERVER_PRIO=1",
        "NRF_SDH_DISPATCH_MODEL=2",
        "NRF_SDH_SOC_ENABLED=1",
        "NRF_SDH_STACK_OBSERVER_PRIO_LEVELS=2",
        "NRF_SDH_STATE_OBSERVER_PRIO_LEVELS=2",
        "NRF_SDH_SOC_OBSERVER_PRIO_LEVELS=2",
        "NRF_SDH_REQ_OBSERVER_PRIO_LEVELS=2",
        "NRF_SDH_BLE_STACK_OBSERVER_PRIO=0",
        "NRF_SDH_SOC_STACK_OBSERVER_PRIO=0",
        "FDS_BACKEND=2",
        "SWI_DISABLE1=1"

Now, the USB code is somehow affected. It appears to timeout after a few endpoint transfers during enumeration. I'm thinking one of these compiler flags is changing how interrupts behave slightly and causing issues for the USB driver.

Any hints on where else I should look? My dev chip appears to be ENGINEERING_REV_C.

You can see the associated github issue here: https://github.com/ARMmbed/mbed-os/issues/10862

And a majority of the driver code here: github.com/.../USBPhy_Nordic.cpp

[Bjørn Kvaale]

Unfortunately, it seems like this issue is related to mbed-os & not the 52840. As this seems to be related to the Cordio BLE stack, I would continue the discussion on the github issue you created. They should be able to help you more than we can.

[George Beckstien]

Hi Bjorn, it isn't related to the Cordio BLE stack as I am building without it enabled. Mainly what I am asking is:

What changes occur to interrupt handling when the soft device is present vs absent? Is interrupt latency decreased when it is absent? Can you give me your thoughts on why the USB stack may be affected by removing the softdevice?

It appears the issue is being caused when an endpoint write is triggered on a non-control endpoint. The transfer complete interrupt is occurring before the USB stack has internally updated its state to reflect that a write operation was triggered. This was somehow not occurring before removing the soft device.

[George Beckstien]

Turns out it was an issue with the critical section API used by Nordic drivers when the soft device is disabled (by setting "SOFTDEVICE_PRESENT" to 0).

The Nordic drivers were switched to use an internal critical section API rather than the same one Mbed was using. So the Nordic drivers would unexpectedly reenable global interrupts while Mbed expected to be in a critical section still.