DW1000 device ID reads correctly, but cannot write registers/do anything

Wireless Connectivity Ultra-Wideband
,
1

Hi,

Running into a very weird problem using the DW1000 with an ESP32. I’m using the thotro Arduino library, modified so it compiles for ESP32, and I’m testing using the extremely simple connectivity test https://github.com/thotro/arduino-dw1000/blob/master/examples/BasicConnectivityTest/BasicConnectivityTest.ino

That code gives this output:

Device ID: DECA - model: 1, version: 3, revision: 0
Unique ID: 00:00:00:00:DE:CA:01:30
Network ID & Device Address: PAN: 00, Short Address: 00
Device mode: Data rate: 110 kb/s, PRF: 16 MHz, Preamble: 2048 symbols (code #4), Channel: #5

The Device ID and Unique ID are correct. But the code should also set the Network ID and Device Address, yet clearly, it doesn’t, as they remain 00.

DW1000.newConfiguration();
DW1000.setDeviceAddress(5);
DW1000.setNetworkId(10);
DW1000.commitConfiguration();
Serial.println(F("Committed configuration ..."));

After trying a few other things, such as reducing SPI speed, with, I admit, the help of Codex (AI), I edited the code to do a raw PANADR write, which didn’t change anything.

PANADR before raw write: 00 00 00 00
PANADR after raw write : 00 00 00 00
Device ID: DECA - model: 1, version: 3, revision: 0
Unique ID: 00:00:00:00:DE:CA:01:30
Network ID & Device Address: PAN: 00, Short Address: 00
Device mode: Data rate: 110 kb/s, PRF: 16 MHz, Preamble: 2048 symbols (code #4), Channel: #5

I also tried to write PANADR with a manual SPI transaction at 1MHz, but again no luck. Of minor interest, reading the register gave a slightly different value using this method compared to the raw writes, but I don’t know if this means anything.

PANADR before raw write: 00 00 00 00
PANADR after raw write : 00 00 00 00
PANADR before manual 1MHz: 00 00 00 01
PANADR after manual 1MHz : 00 00 00 01
Device ID: DECA - model: 1, version: 3, revision: 0
Unique ID: 00:00:00:00:DE:CA:01:30
Network ID & Device Address: PAN: 00, Short Address: 00

Finally, modified the code to read SYS_TIME directly, twice with a 20ms delay in between, so it should have changed, as well as trying different SPI modes. The output from that code is below, but the two reads were the exact same, every time. Also weird different SPI modes have different readings, though always the same before and after.

DEV_ID raw: 30 01 CA DE
SYS_TIME A: 12 00 32 00 00
SYS_TIME B: 12 00 32 00 00
PANADR before raw write: 00 00 00 00
PANADR after raw write : 00 00 00 00
PANADR before mode 0: 00 00 00 01
PANADR after mode 0 : 00 00 00 01
PANADR before mode 1: 00 00 00 03
PANADR after mode 1 : 00 00 00 03
PANADR before mode 2: 24 01 64 00
PANADR after mode 2 : 24 01 64 00
PANADR before mode 3: 00 00 00 01
PANADR after mode 3 : 00 00 00 01
Device ID: DECA - model: 1, version: 3, revision: 0
Unique ID: 00:00:00:00:DE:CA:01:30
Network ID & Device Address: PAN: 00, Short Address: 00
Device mode: Data rate: 110 kb/s, PRF: 16 MHz, Preamble: 2048 symbols (code #4), Channel: #5

Seemingly, my DW1000 is functional enough to get the Device ID (so SPI communication does work), but not to do anything else. This issue means I basically can’t use it, since it won’t transmit or receive, as it isn’t connecting properly.

I have triple checked all my connections, made sure it has power, capacitors near the power pins etc. None of that has done anything.

At this point, I’m very lost. I don’t have an oscilloscope or logic analyser, and really not sure what else I can try. Any help would be much appreciated!

P.S. In my other post, I asked about connecting RST and WAKEUP - this is a different module, and so an unrelated issue.

2

Device ID is address 0, offset 0. Read is indicated by a low. So if you hold MOSI low and give it a clock you’ll get the device ID.

To me this implies that SCLK and MISO are correct but you may have an issue on the MOSI line. What you are seeing is roughly what I would expect to happen if your MOSI line had a conflict and was getting stuck low a lot of the time. At this point I’d normally say you need to look at the lines with an oscilloscope but you don’t have one.
Do you have a multimeter? Can you check the resistance from MOSI to GND, to MISO and to any other adjacent pins. Also check the soldering on those connections.

3

Just double checked MOSI using my multimeter - definitely not shorted to anything it shouldn’t be, and while some of my soldering is a little dodgy, all the SPI pins appear to be perfect (and I did check many other pins too, and none of them were shorted).

Any other ideas for what could cause something like this?

4

The datasheet calls for 32ns between the last bit on one byte and the first bit of the next. Slowing down the SPI should have ensured that. Getting the correct device ID implies that the CS line timing is also correct.

To be honest at this point I’m not sure where to look without being able to look at the signals on the bus.

I am assuming that there is no fundamental flaw in your drivers. How extensive were your changes to the driver firmware? Assuming you’ve not gone and changed the guts of them significantly I’m not sure what changes you could have made that would have had this effect.