DWM30001CDK standalone operation without connection to USB UART

Hi everyone,

I am trying to get the DWM3001CDK working in standalone operation as an anchor/responder without having it connected to a USB host. My setup uses the latest “DWM3001CDK DK Software, Sources, Tools and Developer Guide.zip” and has two DWM30001CDK devices where one is configured as a responder and one is configured as an initiator. The setup of the responder is stored on the NVM and the RESPF application starts automatically as soon as the device is connected to a power supply. Everything works nicely as long as both devices are connected to a USB UART. However, there are errors in the ranging if the responder in not connected to a USB UART.

  1. Does the firmware provide the option to run correctly in standalone mode or does it currently require a USB UART connection? I built the “DWM3001CDK-DW3_QM33_SDK_CLI-FreeRTOS.emProject” and stepped through it with the debugger but I don’t yet understand how everything works together.

  2. Could it be that the UART output causes the issue when no USB UART is connected? And if so, what do I have to look in the code for to disable it.

  3. How to switch to the UART connection on the Raspberry Pi header and disconnect the USB UART without issues? I managed to activate the UART connection on the Raspberry Pi header (command “uart 1” on CLI, followed by “save”) but the device still requires an active USB UART connection to work correctly.


"Device":"DWM3001CDK - DW3_QM33_SDK - FreeRTOS",
"Current App":"STOP",
"Build":"Oct 28 2022 13:48:15",
"Driver":"DW3XXX Device Driver Version 06.00.14",
"UWB stack":"R11.9.2"}}


  • Both devices connected to USB UART
  • Initiator connected to USB UART, Responder connected to powerbank
  • Initiator connected to USB UART, Responder powered via Raspberry Pi header


Hi @christian.i
Im not familiar with the demo code.


  • On DWM3001CDK is a STM32 chip which behaves as SWD debugger and USB to UART bridge. From this point of view it should not matter is the RPi UART is used or if you use the USB.
  • I dont think it is an UART issue at all
  • I pretty much convinced that is is your powerbank who generate the issue. Some power banks contain poor DCDC converters which are working very badly (very high noise) with low power load. Try to replace the power bank with some adapter first to double check that.
  • Most of the newer powerbanks has a “smart power” feature which cut off the power output when it detect a low current at its output - it also can cause target power cycling - double check that. For example to bypass this I have created a cable with addition resistor load.


Hi @leapslabs ,

thanks for your input, but I don’t think it’s only due to the powerbank. I also used a laboratory power supply to hook the board up via the RPi header. In that case there are also problems with the communication as shown in the images above. For me this indicates that the SW behaves differently depending on whether the UART is connected via USB or not. Also, switching to the UART on the RPi header does NOT turn off the USB UART - it remains active an can be used to controll the board at the same time.

Still, my main question is whether the SW currently works as intended without an active USB UART connection. I assume that saving the responder application (so that it starts at power-up) should do the trick, but I can’t get it working.

Maybe someone can confirm whether the responder app works without active USB UART connection.


Hi @christian.i
Im not familiar with the SW so I cant help you here. But I have doubts that UART needs to be connected, but who knows.


Hi @carlos.silva , please take a look at my post when you have the time. The responder app seems to require a USB UART connection to work properly. Do you have an idea in mind of how I can make it work?

Hi @christian.i ! Weird that I didn’t see the notification for this message!

How did you set the DWM3001CDK role, CLI “initf” plus “save”?
It seems to be an issue with the report function. If the USB is not connected the embedded app gets stuck, even able to range.

You can try to remove the report part “reporter_instance.print” or disable the USB.
If you need to start FiRa ranging in code (because CLI is not available), add “scan_fira_params()” to main:

scan_fira_params("initf 2 2400 200 25 2 42", true); // Change to false if responder

And inside “\Src\Apps\Src\common\app\common\app.c” set the “DEFAULT_APP” to “helpers_app_fira”:

extern const app_definition_t helpers_app_fira[];
#define DEFAULT_APP helpers_app_fira //idle_app

By doing this the app should be able to start FiRa TWR in the startup and work on the USB.

Best regards!

1 Like

Hi @carlos.silva, thanks for the instructions. I changed the FW to automatically start the responder app with my parameters, and disabled the UART communication by removing the define USB_ENABLE from the project preprocessor settings. However, that didn’t fix the FiRa ranging problem.

It seems that the issues is related to the USB driver but independent from the UART communication.

I flashed the original CLI FW to prevent any side effects of my changes. I can also rule out any power supply issues because I get the same results with a laboratory power supply and batteries.

This is what I found out:

The FiRa ranging works as expected as soon as the green LED D9 on the responder board goes ON.

This happens in the function “usbd_user_ev_handler(…)” in “\Src\HAL\Src\nrfx\HAL_usb.c”

static void usbd_user_ev_handler(app_usbd_event_type_t event)
    switch (event)

        if (!nrf_drv_usbd_is_enabled())

    • bsp_board_led_on(LED_USB_RESUME);

To me it seems that the USB driver has to reach a certain state before the responder app can work properly.

The state can be reached in a reproducible manner as described in the picture below.

In order to get the green LED D9 ON, there MUST be a micro USB connector plugged into J20. Only providing VBUS via the test point pad TP14 does NOT work. So it seems to me that the plug detection is involved.

At this point I’m stuck. I want to start the responder board by just connecting the power supply. I have no idea about how to solve the USBD issue.


1 Like

Hi @christian.i ! Thank you for the very detailed explanation.

You’re right, I’ll try to find where exactly the app is halting, waiting for USB.

Kind regards!

this does not happen with the V3 sdk CDK binary loaded. I am testing powered on the j9 connector, usb power leads only and the board is providing ranging (client)

1 Like

Hi @rexxdad ! This is interesting!

I tried with an nRF52840-DK and it worked with the same code I was using for DWM3001CDK.
I hope to test it again still this week.

Hi @rexxdad, the current download from the qorvo product page (link) is DWM3001CDK SDK 0.1.1 (which includes DWM3001CDK-DW3_QM33_SDK_CLI-FreeRTOS_0_1_1.hex). What V3 SDK binary are you referring to?

I tried to reproduce your setup with DWM3001CDK-DW3_QM33_SDK_CLI-FreeRTOS_0_1_1.hex, but I only get a singe range measurement, the remaining output is all errors.


  • Initiator connected to PC via USB UART

  • Responder

    1. device not connected in any way
    2. micro USB (power leads only) plugged into J9
1 Like

Hello @carlos.silva, did you by any chance find where the app is waiting for a USB connection? I am trying to run the device without connecting it to a computer, but it seems that I only obtain one successful response when the device first starts, and everything after just fails.

Hi @youssef !

Still working on it.
Not sure how the issue is related to USB, but the chip is taking too long sleeping and a workaround would be to change DEEPSLEEP_WAKE_CONSTANT_DW3000_us to a very high value in \DWM3001CDK-DW3_QM33_SDK-FreeRTOS\Src\UWB\dw3000_lp_mcu.h
Using like this, I got it working:

#define DEEPSLEEP_WAKE_CONSTANT_DW3000_us (999999)

Not ideal because this way the chips are awake all the time.
I’ll get back here when I found a real solution.

Kind regards!

1 Like

Hello @carlos.silva

I was working on a solution around a week ago, and I found something that might be of use. I currently lost access to that solution, but I still have an idea on what I did. In SDK_BSP/Nordic/NORDIC_SDK_17_1_0/components/libraries/usbd/app_usbd.c where the app_usbd_event_execute function is, I moved the portion of the code related to the resume outside the switch statement, and run just that. The idea is to force the device to resume without having to wait for a usb connection event. To some extent, it worked. I managed to plug my device to an external power source, but it had some negative outcomes. For example, the boards should be facing each other at a very delicate angle in order to obtain successful transmissions, and a slight change in the angle would affect that. Moreover, I placed the devices at a farther distance ~6 meters, and I wasn’t able to obtain any successful transmissions.

I apologize, but I cannot fully remember what I changed in the code back then.
This is not the best approach, but hopefully it could assist you. As for your solution, I will give it a try as soon as I gain access of the devices again.


1 Like

Hi, @youssef ! Thanks for that!

I just figured out what was happening, I was looking for low-power functions inside both USB and UWB code, but it was actually the HFCLK.
The HFCLK is used by the USB driver, the nrf_drv_clock_hfclk needs a request for each peripheral/resource using it, USB has a request, but UWB doesn’t. The nrf_drv_clock_hfclk is set like only USB is using it and when USB releases it stops. The solution is to add a new request for UWB:
In main_cli() look for BoardInit(), it calls peripherals_init() which has the clock initialization.
There you will find a call for nrf_drv_clock_lfclk_request(NULL), right before this line you should add the nrf_drv_clock_hfclk_request(NULL).

This single call will solve the problem, but Nordic sets the call with a verification before proceeding:

   while (!nrf_drv_clock_hfclk_is_running())
       // spin lock

Well, that’s it! Thanks for spotting this issue!
Kind regards!


Hey @carlos.silva thank you for this solution! I will try it out when I gain access to the devices and let you know if I face any issues. Glad to be of help!

Kind regards :slight_smile:

I tested the fix and it works! Took me a while to figure out how to compile firmware. I am running 8x anchors and they save their commands and automatically start, either with USB power or battery. I have a single tag at the moment.

For future-me reference:
The IDE is Segger Embedded Studio for ARM. To load the firmware source, go to C:\UWB\DWM3001CDK_SDK\Sources\DWM3001CDK-DW3_QM33_SDK-FreeRTOS_0_1_1\DWM3001CDK-DW3_QM33_SDK-FreeRTOS\Projects\DW3_QM33_SDK\FreeRTOS\DWM3001CDK\ses and double-click on the DWM3001CDK-DW3_QM33_SDK_CLI-FreeRTOS.emProject file. It will automatically load the entire project into Segger. You then search for nrf_drv_clock_hfclk_request(NULL) across entire project to find the right file to edit.

1 Like

Yup it works! Thank you @carlos.silva !
Also @Costas for the last sentence, I think you made a typo. You should search or nrf_drv_clock_lfclk_request not nrf_drv_clock_hfclk_request

1 Like