This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

USB without Softdevice Issue

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

Parents Reply Children
  • 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.

Related