Hi,
I am trying to integrate DWS3000 (UWB) APIs, given here to nRF52840 with BLE stack enabled such that my firmware can have the softdevice on at the same time when UWB ranging is performed.
Is there already any working done on this? I’m facing issues with the interrupt priority as I try to integrate the two, the code gets stuck.
Any leads/help would be much appreciated.
Kind regards,
UK
Very interested if anyone was successful with this.
The example code uses lots of “delay” statements that are verboten when working with a SoftDevice (BLE Stack). Is there a code example that does something more intelligent, like use a task manager?
Reworking the example SPI driver to use task manager is a pretty major stir of the code.
Seems there are more than IRQ priority issues. Hard fault’s abound.
Integrating the DWS3000 with the nRF52840 with a BLE stack enabled has more than interrupt priority issues. However, setting the SPI IRQ priorities to the lowest priority (APP_IRQ_PRIORITY_LOWEST) everywhere resolves compiler errors and it seems to operate okay.
More serious are hard faults caused by use of the SPI port in combination with the SoftDevice.
The DecaWave example code uses the high speed SPIM3 port of the nRF52840, leveraging the 32mb transfer rate. SPIM3 has numerous errata posted, even in current silicon. One of the errata (anomaly_198) involves conflicts between simultaneous access to the RX/TX buffers by internal DMA (EasyDMA) and CPU operations resulting in ambiguous data.
Nordic provides a software workaround in their SDK (nrf_spim.c) for this anomaly which involves writing to a specific memory location. With non-SoftDevice applications, this memory location is freely addressable.
When an application includes a SoftDevice, various memory regions are protected from application writes using the Nordic Memory Watch Unit (MWU) and hard faults are generated whenever application code outside the SoftDevice writes locations in these regions.
The special memory address written by the Nordic anomaly_198_workaround() code violates one of these regions and as a result a hard fault occurs whenever the workaround code is executed with a SoftDriver present. The DecaWave SPI driver calls Nordic nrf_spim functions and thus the workaround code whenever SPI operations are performed resulting in immediate hard faults.
After some digging it appears that there are two mitigation suggestions to resolve this issue that have some promise, either solo or in combination:
Using 1) will probably get you going but 2) may be required to avoid race conditions. Testing that now.
And yes, I’m getting rid of the nrf_delay()/Sleep() calls. Ugh.
Manipulating memory watch unit configuration (MWU) settings does get you going … but eventually you still get a hard fault at the transition. Also note that the Nordic workaround code executes from both application level (enable/disable workaround setting) and IRQ level (disable workaround setting).
Implemented Time slot API (sd_radio_session_open() and related functions). but it is still not working as expected, with hard faults occurring at protected memory write operations in the workaround code.
Considering abandoning SPIM3 configuration for nRF52840 and BLE, using SPIM2 or other channel with lower bandwidth.
@KentI ,
I’m hoping you might have more of an update on how you were able to implement the softdevice with the existing API. I’d be interested to know if switching the SPIM instances worked?
Hi @jenna, Apologies for the delayed response.
I was able to get the BLE/Qorvo combination to work.with SPIM3 although the details of how are a bit fuzzy. Shortly after I got it working, the project was cancelled so I was not able to put the code into production.
As I recall, the solution hinged on a combination of creating a custom memory map to keep the SPIM3 controller from conflicting with the SoftDevice (which uses dedicated memory spaces), removing all the anomaly workaround code, and making sure IRQ priorities were appropriate. I also ended up implementing my application code and some of the DecaWave functions as tasks using Nordic’s TaskManager module.
I also recall doing a lot of modification to the DecaDriver to make it work with a task oriented application.
I’m not sure how well this scheme would hold up under fairly constant interface traffic (BLE and UWB) but it was working in our proof of concept demo.
What is clear is that the DecaWave demo was not compatible with being co-resident with a SoftDevice and the SPIM3 conflict was but one of several.
Things have moved along for Qorvo since then so I’m not sure any of this still applies to the current development environment.
Best regards,
-Kent I.
Hello @jenna , @Usmankhan717 ,
I am facing the same issue with the integration of DW3000 API and nRF52840. I would like to know if you were able to find a solution to solve this issue. Also, if you have any sample codes or workarounds (especially for the memory map)?
Any leads/help would be much appreciated.
Many thanks,
Amir