Receive Frame Wait Timeout Event (RXRFTO) not set

[looki]

Hi,

i am working with the DWM1001 chip on channel 5, PRF_64M, PLEN_128, PAC16 @ 6.8 Mbits/s.
Frame filtering is enabled, auto ack disabled.

I am currently facing the problem, that during reception once every few hours the RXRFTO event is not set (even though no other device is transmitting or even turned on). While polling the System Event Status Register 0x0F the device is stuck in the loop. The register holds the following value: 0x800072

Before starting reception, a frame is transmitted + busy waiting for clearing TXFRS flag once set. This means, in my understanding, the dw1000 should be in IDLE state before reception.

Simplified code for reception:

void receiveFrame(uint16 timeout){
dwt_setrxtimeout(timeout);
dwt_rxenable(DWT_START_RX_IMMEDIATE);

uint32 status_reg;

do{
	//problem: sometimes RXRFTO event is not set
	status_reg = dwt_read32bitreg(SYS_STATUS_ID);
} while (!(status_reg & (SYS_STATUS_RXFCG | SYS_STATUS_ALL_RX_TO | SYS_STATUS_ALL_RX_ERR)));

if (status_reg & SYS_STATUS_RXFCG) {
	dwt_write32bitreg(SYS_STATUS_ID, SYS_STATUS_RXFCG);
	//received frame!
	return;
}  else if (status_reg & SYS_STATUS_ALL_RX_TO) {
	dwt_write32bitreg(SYS_STATUS_ID, SYS_STATUS_ALL_RX_TO);
	dwt_rxreset();
} else if (status_reg & SYS_STATUS_ALL_RX_ERR) {
	dwt_write32bitreg(SYS_STATUS_ID, SYS_STATUS_ALL_RX_ERR);
}

timeout = getRxTimeoutLeft();
if(timeout > 0){
	receiveFrame(timeout); //recursive call if some time is left for staying in RX
}

return;

}

[btprg]

Hallo,

at the first glance I see that you doesn’t execute dwt_forcetrxoff() on Rx error as in the sample ISR by Decawave.

Furthermore, I think that your problem might be related to the one I’ve experienced:

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 ) 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 (TXF…

You wrote that you are also transmitting, IMHO it is possible that this Rx re-enable problem after Tx causes this Rx timeout malfunction too. My workaround seems to solve this problem, so you may implement it to your code.

Good luck

[looki]

@btprg

You wrote that you are also transmitting, IMHO it is possible that this Rx re-enable problem after Tx causes this Rx timeout malfunction too. My workaround seems to solve this problem, so you may implement it to your code.

Thanks for the reply. Maybe you’re right and I have to call dwt_forcetrxoff() on rx errors, I will look into it.
For now, I implemented a similar workaround as you have: I have a simple timeout for the first while loop in my code example, i.e. I count how often the while loop is executed and terminate after count > threshold. In this case I call dwt_forcetrxoff() as well as dwt_rxreset(). With this I do not have an additional spi call (dwt_forcetrxoff()) for each and every rx (as in your workaround), but only when it is really necessary.