Double Receive Buffer: rare event where rx stops working

Hi All,

I am working with several dwm1001c devices and default config (Ch5).
I use code provided by decawave (deca_device.c) and do not have interrupts enabled, instead I constantly poll the IC status reg 0x0F.

Double receive buffer is enabled and everything works correctly: a tx is followed by multiple rx (using the swing buffer set) and another tx follows (asynchronous two-way ranging).

To test stability I have another dwm device configured to send about 100 uwb messages per second to flood the network. This is where I get following erratic behavior:

Once every few hours the device using the double buffer has the status flag RXOVRR set to 1 and after that the receiver stops working. Neither dwt_forcetrxoff() and dwt_rxreset() helps and I do have to make a full reset of the device. Tx still works though.

Status reg: 1100 0000 1001 0000 0000 1011 0111 0010
State reg: 0001 0000 0000 0000 0000

Rx auto enable is not active and I do switch the buffer manually after a successful rx. If a rx error or rx timeout happens, I do reset the receiver (dwt_forcetrxoff() and dwt_rxreset()).

I read the user manual several times and cannot see what I am doing wrong + I do not understand how the RXOVRR flag is set to 1 although rx auto enable is not enabled and I switch the buffers manually.

Best regards,

Not sure if this is related, but after searching the forum (again) I stumbled upon this post: When trasmining after ACK was sent RX stops working. - #15 by kamtar

[…] working in an environment with lots of UWB traffic. It seems that the noisy environment locks up the receiver for some time.

What does this mean exactely?

Still having this problem, would appreciate some help :slight_smile:

EDIT: Ok, I think I have some new insights:

In case the status flag RXOVRR is set to 1 (still unsure why this happens, maybe some kind of race condition?) I have to toggle the rx buffer manually with

dwt_write8bitoffsetreg(SYS_CTRL_ID, SYS_CTRL_HRBT_OFFSET, 1)

Calling dwt_forcetrxoff() in such situations is not enough as I mentioned in my first post - even though dwt_forcetrxoff() calls dwt_syncrxbufptrs() :thinking: