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 ) 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:
“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.