DW1000 Rx re-enable problem after Tx success

Hi everybody,

my driver is now working, and I’ve made a TWR implementation following the User Manual. But I’ve faced with a problem I can’t understand: sometimes (unfortunately not so often to make investigation simple :sweat_smile: ) the Rx is re-enabled by the driver, but DW1000 does not receive anything.

I use neither auto Rx re-enable nor WAIT4RESP. The driver processes are the following: 1. The Tx function executes TRXOFF, sets registers, interrupts etc., starts Tx.
2. On Tx success (TXFRS) Rx re-enable is called, on Tx fail (delayed Tx) a TRXOFF is executed and Rx re-enable is called.
3. The Rx (re-)enable function makes the buffer alignment (if needed), sets up interrupts and executes RXENAB.

The debug output is the following:
dw_forum2

“UWB Rx started!” is printed after every Rx re-enable (after successfully receiving a packet, or after Tx success). The register dump is called in every seconds. It can be seen that “UWB Rx started!” was done finally, the DW1000 is in Rx state, the interrupts are set for receiving, but nothing happens. Just the reserved, undocumented upper SYS_STATE bits are varying sometimes…

Shortly: the DW1000 is configured correctly, working fine, but sometimes manual Rx re-enable after Tx causes an erroneous internal state and the device receives nothing.

What may cause this? I checked the Decawave examples, but it uses always WAIT4RESP to enable Rx after Tx. Should I wait for a while after Tx before re-enabling Rx? Or should I execute a TRXOFF also before enabling Rx after Tx?

Additional information: if I issue a new Tx and then an Rx re-enable in this weird state, it continues working fine.

Thank you!

Idea 1. Are you sure you do not have an asynchronously running processes, which could conflict?
i.e. are you sure that you have a volatile access to a single resource (dw1000 chip)?

Idea 2. Are you sure power stable?

Good luck debugging!

Thank you for the ideas. I do not use asynchronous processes, the GPIO ISR does nothing just sets a static volatile boolean variable. The power is also o.k.

Finally I’ve tried a workaround that solved this problem seemingly (multiple devices work for more than a day continuously doing TWR in every 3 seconds). Before re-enabling Rx after Tx (even after delayed Tx fail) I execute a TRXOFF command and a receiver-only soft reset.

PS: the Decawave team does not read this forum? :face_with_raised_eyebrow: These problems are related to undocumented chip internals, but the chip designers there surely know every little thing about them. Just not bother with these questions…

Looks like that, sadly. I had two problems related to undocumented chip internals (as far as I can tell) and got no help whatsoever:

https://forum.qorvo.com/t/force-tx-clock-enable-implications/6847

https://forum.qorvo.com/t/receive-frame-wait-timeout-event-rxrfto-not-set/8891