DW3000: Getting continuous SFD timeout (RXSTO) events on RX enable

Hello peoples,

I’m using the DWM3000. When I attempt to receive packets (sending the RX command), the reception immediately fails with the RXSTO (SFD timeout) bit set in SYS_STATUS. If I enable RXAUTR for auto-receiver-reenable, the counter EVC_STO increments by ~30,000 events/sec.

I’m using the most default configuration I can figure:

DEV_ID       deca0302
SYS_CFG      00040498     # FAST_AAT, RXAUTR, IPATOV, PHR_MODE, DIS_DRXB
TX_FCTRL     000000001800 # TXPSR-1 (64sym preamble), TR
TX_ANTD      4015
CHAN_CTRL    031e         # RX_PCODE=TX_PCODE=3, SFD=802.15.4z
RX_CAL_RESI  10888210
RX_CAL_RESQ  10888210
DTUNE0       100c         # PAC=0 (8)
RX_SFD_TOC   0041         # SFD timeout=65
PRE_TOC      0000         # no preamble timeout
DTUNE3       af5f35cc     # as recommended
RF_TX_CTRL_1 0e           # as recommended
RF_TX_CTRL_2 1c071134     # as recommended for ch5
SEQ_CTRL     80030738
CIA_CONF     00114015

Increasing the RX_SFD_TOC changes the amount of time it takes to generate the timeout, as you would expect, but the timeouts still appear immediately upon enabling RX. For some reason the preamble detector seems to be triggering continuously! (But there’s no actual preamble so we end up with a timeout.)

Messing with PAC seems to have no particular effect.

Note: I am directly programming the registers, since the API doesn’t work on my target platform, but I am using the API source as reference along with the manual. So my next step is to go re-read the API source and examples and try to figure out if there’s some magical “don’t do that!” register somewhere they program??

But, maybe someone knows off the top of their head what could possibly generate this symptom. (Oh, and unsurprisingly, I don’t seem to be able to successfully receive any actual packets.) My understanding is that SFD timeout is supposed to be quite a rare event!

– egnor

I have discovered that if I change the PCODE from 3 (16MHz PRF) to 9 (64MHz PRF), I no longer get the SFD timeout errors.

I did also discover another magic PRF-related register, the RX_TUNE_EN bit in DGC_CFG. But even if I clear that bit as recommended for a 16MHz PRF, PCODE=3 does not work for me (and neither does PCODE=4). Hmmmmmm :thinking:

In any case I can use one of the PCODEs for a 64MHz PRF and move forward. (I’m still not receiving packets, but probably there’s some other reason for that.) And it does look like PCODE=9 is the default, not PCODE=3. Still, I’d love to close this out and understand why it failed…

– egnor