Polled Receiver getting stuck

Hello dear Deca Tech Forum!

I am trying to set up a rudimentary ranging network using DW1001-DEV Boards running my own Firmware.
I am using SS-TWR which is being initiated by one Master-Node while all the other Nodes are prepared to answer, spending their time in Polled Receiving mode with frame filtering enabled and using max. timeout of 65000 (to the end of processing UART input after each RX timeout).

Everything is working as expected but at some point (around 2,5 hours into continous ranging) some of the Responder Nodes get stuck while receiving(?) and neither RXFCG nor any Error- or Timeout-Flag is set.

Polling Code (Responder gets stuck here):

while (!((status_reg = dwt_read32bitreg(SYS_STATUS_ID) & (SYS_STATUS_RXFCG | SYS_STATUS_ALL_RX_TO | SYS_STATUS_ALL_RX_ERR)))) {};

dwt_read32bitreg(SYS_STATUS_ID) does actually return 0b00000000100000000010111100000010 i.e. all the Flags for a successful frame reception are set except for RXFCG !?

I am using the following Configuration:

[code]dwt_config_t dwt_config = {
1, /* Channel number. /
DWT_PRF_64M, /
Pulse repetition frequency. /
DWT_PLEN_128, /
Preamble length. Used in TX only. /
DWT_PAC8, /
Preamble acquisition chunk size. Used in RX only. /
9, /
TX preamble code. Used in TX only. /
9, /
RX preamble code. Used in RX only. /
0, /
0 to use standard SFD, 1 to use non-standard SFD. /
DWT_BR_6M8, /
Data rate. /
DWT_PHRMODE_STD, /
PHY header mode. /
(129 + 8 - 8) /
SFD timeout (preamble length + 1 + SFD length - PAC size). Used in RX only. */
};

[…]

//Additional Setup
//Set NTM_1 and NTM_2 (LDE recognition threshold) for NLOS
dwt_write8bitoffsetreg(0x2E,0x0806,0x07);
dwt_write16bitoffsetreg(0x2E,0x1806,0x0003);[/code]

I’d appreciate any help!
Thank you in advance,
Julian

Can you read the DW state? Register 0x19… in the while loop, and verify that the device is still in RX, or which state it is in.

In your working case… what do you do after good reception? Do you clear status events? Which ones? I think the example only clears the RXFCG, this would leave all other RX events set until next RX enable. Maybe you do not re-enable the receiver?

Hi zoran, thanks for your reply!

You are absolutely right. After good reception I only clear the SYS_STATUS_RXFCG flag. So status events are not valid for error analysis.

The 0x19 register reads as 0x00040000. What state does this represent? I was unable to find instructions on how to read that register in the DW1000 user manual.

I do not understand how re-enabling the receiver works fine for a long time and then all of a sudden is supposed to fail.

Here is an extended portion of my receiving code, which shows that dwt_rxenable is called just before the polling bit:

[code] dwt_setrxtimeout(timeout);
dwt_rxenable(DWT_START_RX_IMMEDIATE);

while (!((status_reg = dwt_read32bitreg(SYS_STATUS_ID) &
(SYS_STATUS_RXFCG | SYS_STATUS_ALL_RX_TO |
SYS_STATUS_ALL_RX_ERR)))) {
dw_state = dwt_read32bitreg(0x19);
};[/code]

Best regards,
Julian

Hi Julian,

the states register (0x19) is described in Debugging App note (https://www.decawave.com/sites/default/files/aps022_debugging_dw1000_based_products_systems.pdf). The PMSC and RX states should both be in 0x5 when actively receiving. It would be good to buffer up this register to see what led to state 0x4…

Hi Zoran,

Sorry for the late response! When I ran a test printing out the state register at various points in my code the error would not occur?!

Thanks four your help,
Julian

I am having the same issue as described in this post.

I am switching between tx and rx modes and putting the DW1000 into deep sleep periodically, and sometimes it appears the calling dwt_rxenable(DWT_START_RX_IMMEDIATE) after waking up from deep sleep just doesnt work and so I am stuck waiting forever. I have read the DW system state 0x19 register to confirm that the DW is in idle mode, not rx mode.

In another similar forum post I read that calling dwt_forcetrxoff might fix it but that didnt appear to work either.

Most of the time, this works fine but randomly it doesnt.

Any suggestions on a work around or how to fix it?

Thanks,

Karl