• State Not Answered
  • Replies 3 replies
  • Subscribers 68 subscribers
  • Views 1070 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 231168
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
No Data
Related