DWM3001CDK SS_TWR Example

Hello Qorvo Support Team,

I hope you’re doing well.

I’m currently working with the DWM3001CDK Development Kit (nRF52833 MCU + DW3110) to run the SS_TWR_Initiator/Responder examples from the Qorvo SDK. Using two Dev Kits, I was able to successfully measure distance without any issues.

Recently, I designed a custom PCB featuring the DW3220 IC and a custom antenna design that closely replicates the one on the DWM3001CDK Dev Kit. I connected the DW3230 to the 3001CDK module via the SPI2 interface (side header pins), and communication works as expected — I can successfully read the device ID (deca 0312).

On my custom board, I’m running the ss_twr_initiator example and can successfully transmit the initial poll message, with the sequence number incrementing as expected:

log_poll_msg: 41 88 79 CA DE 57 41 56 45 E0 00 00

On the DWM3001CDK Dev Kit running the ss_twr_responder example, I can receive the message successfully:

log_poll_msg (RX): 41 88 79 CA DE 57 41 56 45 E0 4E F3

The response message is also logged as follows:

log_poll_msg (TX): 41 88 00 CA DE 56 45 57 41 E1 4B 0B B8 1A 01 10 32 1D 00 00

However, when I call dwt_starttx(DWT_START_TX_DELAYED) on responder (dev-kit), the function consistently returns -1. This return code comes from dw3000_device.c where checkTxOK has the HPDWARN bit asserted from STATUS register.

On the responder side, the difference between the last rx_poll_timestamp and the current one always remains constant, which suggests there may not be a clock synchronization issue. The same behavior is observed with the calculated response_tx_timestamp.

Could you please advise what might cause dwt_starttx() to fail in this context, or suggest any additional steps to verify timing or antenna calibration on the custom hardware?

Thank you for your time and support.

Best regards,
José Portilha

1 Like

The description for HPDWARN is fairly clear.
The internal clocks wrap around about every 30 seconds (36 seconds from memory). That flag indicates that you have requested a transmit time that is over half of this period in the future. This is almost always an error caused by attempting to schedule a transmit for a time that is in the past.

Short version - your firmware didn’t process the message and respond quickly enough to meet the timing requirment constants in your code. Either speed up the processing (a faster SPI bus, or different optimisation settings can make a huge difference) or increase the time allowed.