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!