Hi christophe,
did you figure this out? We’re running into the very same issue, although with a slightly different configuration set, enabled double buffering and enabled auto RX.
SysState: 0x40050500
SysStatus: 0xC0000000 (although this also happens with 0x0…, but seemingly less often)
SysCfg: 0x20440200
Configuration:
{
.channel = UWB_CONFIG_CHANNEL_1,
.prf = UWB_CONFIG_PRF_16MHZ,
.code = UWB_CONFIG_CODE_1,
.datarate = UWB_CONFIG_DATARATE_110KBPS,
.sfd = RECOMMENDED,
.pac = UWB_CONFIG_PAC_32,
.preambleLength = UWB_CONFIG_PREAMBLE_LENGTH_2048,
.optimizeForNLOS = false,
.enableDoubleBuffer = true,
.enableSmartTx = false
}
We are not using the decawave driver and we have only one anchor and one tag communicating with each other at the moment.
This also happens no matter if we send messages with 1 Hz or 50 Hz. We also watched the IRQ- and SPI-wires for, well, anything really, but the registers are accessed and set identically in cases where we can receive signals and where we can not receive signals. Timing is also pretty identical.
When messages can no longer be received, SYS_STATUS does not change at all, leading us to believe that the preamble search already fails.
As you wrote, forceTxOff helps resolving being stuck in RX, but restarting the reception somewhat randomly seems to be a rather bad solution.
@alliv: is there any reason for avoiding auto-RX-reenable? Also, what kind of race condition could occur? We are replying to a single message, reenable RX after the message was sent (and the interrupt appeared) and sometimes this just fails (although SysState clearly claims that it worked).
Thanks.
Edit: Well … seems to be a known problem: DW1000 Rx re-enable problem after Tx success - #3 by btprg … ?