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
)
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 ![]()
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