DWM1000 - TWR responder example getting stuck in limbo receive loop state if message timeout or delay timeout too large

I made some custom PCBs with a DWM1000 module and an ESP32C6… I am running a slightly modified version of the TWR examples given for the decadriver, ported over for the ESP32-C6 (for the latest version of ESP-IDF of course, none of that Arduino rubbish :wink:)

It seems my initiator is running just fine.. as it transmits the final message and I don’t see any logs of an RX or TX failures…

The issue is on the responder… If I have too short of a RESP_TX_TO_FINAL_RX_DLY_UUS or POLL_RX_TO_RESP_TX_DLY_UUS, I get RX timeouts on the final message, which is fine…

E (1910) ex_05b: RX timeout waiting for final message
I (2010) ex_05b: Waiting for final message...
E (2030) ex_05b: RX timeout waiting for final message
I (2130) ex_05b: Waiting for final message...
E (2150) ex_05b: RX timeout waiting for final message
I (2250) ex_05b: Waiting for final message...
E (2270) ex_05b: RX timeout waiting for final message
...

HOWEVER if I make one or both of them slightly larger (for instance, if I bump up FINAL_RX_TIMEOUT_UUS from 4000 to 7000 but keep POLL_RX_TO_RESP_TX_DLY_UUS the same), I just get stuck forever waiting for an RX timeout…

I (400) dwt_init: dwt_readdevid: Entering, about to call dwt_read32bitoffsetreg(DEV_ID_ID=0x00, 0)
I (410) dwt_init: dwt_readdevid: dwt_read32bitoffsetreg returned, value: 0xDECA0130
I (420) dwt_init: dwt_initialise: dwt_readdevid() returned
I (420) dwt_init: dwt_initialise: Read device ID: 0xDECA0130 (expected: 0xDECA0130)
I (430) dwt_init: dwt_initialise: Device ID verified successfully
I (440) ex_05b: DW1000 initialized successfully
I (490) ex_05b: Waiting for final message...

If I log the SYS_STATUS register, i get the following:

E (1580) ex_05b: RX timeout waiting for final message
I (1600) ex_05b: Waiting for final message...
I (1600) ex_05b: STATUS REG: 0x40802FF2
E (1700) ex_05b: RX timeout waiting for final message
I (1720) ex_05b: Waiting for final message...
I (1720) ex_05b: STATUS REG: 0x80802FF2
E (1820) ex_05b: RX timeout waiting for final message
I (1840) ex_05b: Waiting for final message...
I (1840) ex_05b: STATUS REG: 0x40802FF2

Both 0x40802FF2 and 0x80802FF2 suggest that bit 13 is set (RXDFR - “End of frame. The data in RX buffer is ready for reading.”), but neither RXFCG, RXFCE, RXFSL, or any other flag used to detect a valid reception gets triggered… I tested on other boards I made (I made 10), and all behave the same way, so I doubt its a hardware related issue… seems to be some bug in the DWM1000 module that would allow it to enter this limbo state of RX data existing in the buffer, but it doesn’t know if it’s valid or not… like some sort of Schrödinger’s Cat but for RX frames :face_with_raised_eyebrow:

I tried doing dwt_forcetrxoff(); if I detect this anomaly, but that didn’t help…

I am not sure where to go from here, because all the SPI transactions look good on my scope and power looks stable… is it possible that the 10 DWM1000 modules I assembled on my PCBs are bad apples? Or is there some nuance detail or quirky hack I need to implement in my code to make this all work properly?

Here is a link to the ZIP of my current project that has the examples as well as the ported decadriver code to the ESP-IDF: https://drive.google.com/file/d/1d6K_o2rAkSlHeY_xXyRho3v6b-Lq8m_B/view?usp=sharing

I had to make some adjustments to the SPI configuration and I did have to do dwt_write16bitoffsetreg(SYS_CFG_ID, 0, (1 << 10)); to allow the ESP32 to read the device id of the DWM1000… Apparently this helps make the SPI sampling more stable for the DWM1000? Not sure if this has negative side affects that could be affecting me now…

Appreciate any help on this!

Thanks,
Nicolas

It looks like both RXFDR and LDEDONE are set.

The manual does indicate that neither FCG and FCE being set is is an indication that the LDE code hasn’t been loaded. But in that situation I wouldn’t expect LDEDONE to be set.

What happens if you trigger your frame reception process on RXDFR? Is the data / timestamp valid?

Yea super weird since it is able to get the poll request message of the TWR just fine, just fails silently at this final message response… and the initiator works just fine it seems…

Since I need to prepare for a product demo soon I decided to hotwire a RP2350 Pico board and it just worked fine… so something is up with the ESP32C6 i believe… I don’t have time to troubleshoot this any further really, but after the demo I’d like to revisit this and see if I can’t get the ESP32C6 to work