'Hang' when calling dwt_rxenable()

Wireless Connectivity Ultra-Wideband
, , , ,
1

Hello,

I have been playing with the DW1000 example code, trying to get simple transmit/receive working between two identical DWM1000 modules.

The short summary is that when I follow the example code for ex_01a_simple_tx and ex_02a_simple_rx, the receiver will “hang” (never report a frame received, or have SYS_STATUS_RXFCG set) after the call to dwt_rxenable(), which returns DWT_SUCCESS. Further, the receiver module will get warm to the touch, and a call to dwt_readtempvbat() reports the temperature of ~60 degrees before long.

Some debugging information:
I am setting the PanID to a common value on both modules.
I am setting the 16-bit network address and EUI’s to different values on both modules.

My setup function looks like (all parameters are from the examples - I can provide if relevant):
dwt_initialise(DWT_LOADNONE);
dwt_configure();

dwt_setrxantennadelay();
dwt_settxantennadelay();
dwt_setpreambledetecttimeout();
dwt_setpanid();
dwt_setaddress16();
dwt_seteui();
dwt_setleds(DWT_LEDS_ENABLE);
dwt_setcallbacks();
dwt_setinterrupt( all );

The transmitting module will then send one packet per second, with the correct MAC bytes. I see the events getting called for successful transmissions.

The receiving module will set the timeout to 0, then call dwt_rxenable(), and that is the farthest I have gotten.

After the call to dwt_rxenable(), here are some of the registers:
SYS_CFG: 0x00401200
SYS_CTRL: 0x00000000 (somewhat odd that the RXENAB bit is not set?)
SYS_STATUS: 0x00800002
Voltage: 3.29, Temperature: 62.15

I see the thread (I can not receive) that seems to touch on a similar behavior, but transmitting a packet does not seem to help.

Also, swapping the modules does not help. Whichever module acts as the receiver exhibits this behavior.

Any pointers on what I can look at to debug this would be most helpful! I can post specific code snippets as well if desired.

Best,
-Eric

2

just a couple of comments:

If you are “dwt_initialise(DWT_LOADNONE);” … then you will not have RX timestamps. This may be what you want to do, however I doubt it as you are programming TX and RX antenna delays.

From DW1000 User Manual “The control bits within the system control register are typically
automatically cleared. The host controller sets the appropriate bit to invoke an activity and the bit is
automatically cleared by the DW1000 as that commanded activity begins.”

You can read register 0x19 to check if the device is in RX state… see APS022 (Debugging App note) for details on that register.

You should poll both 0x19 and 0xF after dwt_rxenable to see if they are changing.

3

Thanks for the quick reply!

You are correct that I will eventually want to call dwt_initialise(DWT_LOADUCODE) to get timestamps for tanging. However, I was trying to remove as many “moving parts” as I could to get any data receive to happen. I have removed calls to dwt_setrxantennadelay(), dwt_settxantennadelay(), and dwt_setpreambledetecttimeout(). There has been no change in behavior by doing so.

Both registers 0x0F (SYS_STATUS) and 0x19 (SYS_STATE) remain constant after a call to dwt_rxenable().
SYS_STATUS = 0x02800002 = [CLKPLL_LL*, SLP2INT, CPLOCK]
SYS_STATE = 0x0B41050500
I found the documentation for SYS_STATE to be a little unclear, but I think that of the 5 bytes of SYS_STATE, byte 0 is TX_STATE, byte 1 is RX_STATE, byte 2 is PMSC_STATE, and bytes 3-4 are not defined/reserved. This would make TX_STATE=IDLE, RX_STATE=PREAMBLE FIND, and PMSC_STATE=RX.

These are what I would expect.

  • Now-and-again I see the CLKPLL_LL bit being set in the SYS_STATUS register. I have tried multiple DWM1000 modules, so I am inclined to think the hardware is OK. The voltage appears steady at 3.29V, but I have not connected it to my scope to check for noise.

If I examine the EXT_SYNC registers, suggested in this thread (CLKPLL_LL status bit on DW1000), I get the following.
EC_CTRL: 0xDEAD0004 = [PLLDT]
EC_RXTC: 0x00000000 = []
EC_GOLP: 0xDEADDE00 = []

These values look normal to me given I’m not currently doing ranging or external synchronization, so I’m not sure what would be causing the CLKPLL_LL bit to sometimes be set. About 50% of the time, resetting the module will cause the CLKPLL_LL bit to clear.

Any suggestions would be very welcome!

Thanks again,
-Eric

4

Ok, so the device is in RX but does not detect anything, so just stays in preamble hunt/find … what is the channel configuration you are using?

5

Hello!

I’ve been using the channel configuration straight from the example code, included below:

/* Default communication configuration. We use here EVK1000's default mode (mode 3). */ static dwt_config_t s_dwtConfig = { 2, /* Channel number. */ DWT_PRF_64M, /* Pulse repetition frequency. */ DWT_PLEN_1024, /* Preamble length. Used in TX only. */ DWT_PAC32, /* Preamble acquisition chunk size. Used in RX only. */ 9, /* TX preamble code. Used in TX only. */ 9, /* RX preamble code. Used in RX only. */ 1, /* 0 to use standard SFD, 1 to use non-standard SFD. */ DWT_BR_110K, /* Data rate. */ DWT_PHRMODE_STD, /* PHY header mode. */ (1025 + 64 - 32) /* SFD timeout (preamble length + 1 + SFD length - PAC size). Used in RX only. */ };

Does anything stand out that might be an issue?

Thanks again for looking!