dwt_initialise failed

[avinashGonsalves]

Tried your program with the following:
DWM1000_Anchor* anchor=new DWM1000_Anchor("anchor",Spi::create(12,13,14,5),DigitalIn::create(4),DigitalOut::create(16));

The dwm1000 fails to initialize: dwt_initialise failed with the following prints. EUID : FF:FF:FF:FF:FF:FF:FF:FF device id : FFFFFFFF

[vortex314]

this is because you probably don't have a dwm1000 connected.

[avinashGonsalves]

DWM1000 is connected. Any other issue that can cause this? I've read your previous posts, you've had a lot of trouble with the SPI, and managed to fix it. Could you explain the black magic in your spi function?

Checked with another program for the same device, at 20MHz SPI speed DeviceId: 0xdeca0130. But at low spi speed the DeviceId: 0xbc950360. This means that the SPI is not functioning correctly at low speeds. Hence cannot initialize it correctly.

[vortex314]

Ok, it was not clear from your post that you were this far yet. What code did you use to communicate to the DWM1000 at 20 Mhz ?

If you look at the hex values you receive, and shift the last one 1 bit to left or right ( not sure what it was ), you become the right answer.

I'll check if I updated with the latest version of the DWM1000. I had to do the bit shifting in software.

I sometimes got the impression that the DWM1000 was writing & reading in different SPI modes. Now the software and DWM localization is running fine for months Code for the single bit shift. bool lowBit=0; for(uint32_t i=0; i<out.length(); i++) { uint8_t b=in.peek(i); if ( lowBit ) in.poke(i,(b>>1)+0x80); else in.poke(i,(b>>1)); lowBit = b & 1; }

[vortex314]

Some deep dive HEX : DECA0130 => BINARY : 1101 1110 / 1100 1010 / 0000 0001 / 0011 0000 HEX : bc950360 => BINARY : 1011 1100 / 1001 0101 / 0000 0011 / 0110 0000 In reverse byte order as they are read on SPI , you notice the first bit missed, but as the first byte is something you write , you don't care. 00110000000000011100101011011110 == 3001CADE 01100000000000111001010110111100 == 600395BC This understanding took months ! It's a dirty hack around the SPI ESP8266 inconsistencies.

[avinashGonsalves]

Thank you for your in-depth answer, I used the ESP_RTOS_SDK from espressif, used the spi_interface.c driver code. The funny part is at 20MHz i get 0xDECA0130, but at 2MHz i get the reverse? If the SPI is reading in reverse, then it must be writing too in reverse byte order. Let me have a try by checking the spi params again.

Btw i'm still unable to get the DWM1000 to respond with your code. Git clone directly from your repositories. Only changed the SPI CS, IRQ and RST lines.

[avinashGonsalves]

This snippet will do the hack for byte-order/shift issue above: htonl((ntohl(temp)>>1)); This will work on the SPI-Read. but the SPI-Write is still a problem and is one bit shifted out.

With a little help from the post below, i figured that the SPI-Mode 3 works perfectly without the need for the HACK. SPI-Mode 3: GPIO-5/6 on DWM1000 needs to be pulled up (https://www.amobbs.com/thread-5682564-1-1.html)

Here's a little code snipped to check to ensure the SPI read/write works correctly:

#define SPI_CHECK_LEN 4
uint8 dataA[SPI_CHECK_LEN] = {0xDE, 0xCA, 0x01, 0x30};
uint8 dataB[SPI_CHECK_LEN];

// 4 Byte
writeRegister(0x21, 0, &dataA[0], SPI_CHECK_LEN);
readRegister(0x21, 0 , &dataB[0], SPI_CHECK_LEN);

if(memcmp(dataA, dataB, SPI_CHECK_LEN) == 0)
{
    printf("DWM1000 - SPI Check Passed!");
}

[vortex314]

thanks for the update. good to know that mode 3 works fine. couldn't use it on my PCB as i left gpio 5 and 6 open, so they force mode 0.

[vortex314]

so as the other article refers to another microcontroller i start doubting if it is an esp8266 isue or a dw1000 one.