DWM1000 and NXP Kinetis

Has anyone successfully used the DWM1000 module with NXP’s Kinetis processors?

I’m trying to port the SimpleTX example and sometimes it works and sometimes (usually) it doesn’t. I’ve been working with DecaWave tech support but it appears they don’t use the Kinetis processors much. They have looked at my code and don’t see any issues.

What I’ve done:

  1. Connected the DWM1000 board (on a custom breakout board) to an FRDM-K22 development board.
  2. I have power ground, SPI, IQ and Reset lines connected.
  3. I can talk SPI to the radio and read the device ID (DecaWave asked me if I can read it every time so I ran a test and successfully read it 100000 times).
  4. Per the troubleshooting documentation, APS022 “Debugging DW1000 based products systems”, I can read and write to the USR_SFD (0x21) register and it works fine.
  5. I am staying in a low rate SPI mode until I have it working
  6. I am reading SYS_STATE_ID and SYS_STATUS_ID to try and find out why it doesn’t work. The former often returns 0x40001 and the latter 0x800012. This is not consistent, though.
  7. I thought it might be a timing issue, so I have put delays in various places (and stepped through the code in the debugger), but it doesn’t seem to matter.

I have an EVB1000 board that I am running SimpleRX code on to act as a receiver.

I’ve attached the project if anyone is interested in looking at the code.

Thanks – any suggestions on things to try would be very much appreciated.

Brad

Sounds like you have done all the right things with reading the device ID via SPI etc.
Are you using interrupts in your code? Might be worth disabling to see if you get better stability.

Facing the same issue trying to interface with ESP-8266. Although the logs and status say the TX is successful, there is no reception and there are some RX errors (PHY and Reed Solomon) and no RX-Timeout although this is set.

[DBG][dwm1000.c:724] DWM1000 - Tag Poll
[DBG][dwm1000.c:750] System State: 0x40001, Status REG: 0x2800012
[DBG][dwm1000.c:750] System State: 0x40001, Status REG: 0x2800012
[DBG][dwm1000.c:750] System State: 0x10000, Status REG: 0x28000f2
[DBG][dwm1000.c:763] Frame Sent Sucessfully!
[DBG][dwm1000.c:830] System State: 0x10000, Status REG: 0x28113f2
[DBG][dwm1000.c:838] Rx Error!
[DBG][dwm1000.c:840] Rx Error: SYS_STATUS_RXPHE
[DBG][dwm1000.c:842] Rx Error: SYS_STATUS_RXRFSL
[DBG][dwm1000.c:724] DWM1000 - Tag Poll
[DBG][dwm1000.c:750] System State: 0x40001, Status REG: 0x2800012
[DBG][dwm1000.c:750] System State: 0x40001, Status REG: 0x2800012
[DBG][dwm1000.c:750] System State: 0x46050500, Status REG: 0x28000f2
[DBG][dwm1000.c:750] System State: 0x50c00, Status REG: 0x28000f2
[DBG][dwm1000.c:763] Frame Sent Sucessfully!
[DBG][dwm1000.c:830] System State: 0x50e00, Status REG: 0x28013f2
[DBG][dwm1000.c:838] Rx Error!
[DBG][dwm1000.c:840] Rx Error: SYS_STATUS_RXPHE

Thanks, no, I’m not using interrupts at this point. Just trying to get them talking.
[hr]
Here is a screenshot of the Beagle I2C/SPI bus analyzer. It’s in SPI mode. What I find interesting is that what I’m sending agrees with what the EVK1000 development kit sends. But for some reason the radio isn’t answering. For instance on index 5, I write 0x21 | 0x80 which is register 0x21 with the write bit set. Then I write numbers one to four. When I try to read it back (indexes 11 and 12), it gives me garbage. All I can figure is that the radio is not reading the bits I’m sending. The get device ID works (index 2 and 3) because all I’m sending is zeros for that and as you can see is does return 0xDECA0130.

Before anybody asks, I’m am using DecaWave’s API.

Thanks,

Brad

@jbmillard couple of things to try, the below order worked for me:

  1. Once your MCU is up, reset the DWM-1000 using hard-reset (RST Pin)
  2. Initialize the SPI at <3MHZ (and OTP stuff is required to be done at <3MHz)
  3. Do a soft-reset (looks like CLKPLL lock happens only after step 1 above)
  4. DWM1000 Initializtion code…
  5. SPI > 3MHz.

I’ll try this and let you know. At this point, I haven’t been able to talk to the device reliably so initialization is out of the question.

Thanks,

Brad

So I tried it and it didn’t do anything for one of the boards.

I have two development boards with different processors (both Kinetis, one a K22 and the other KL05).

With the K22 board, I can get the device ID, pass the read write test and configure the radio. I’ve ported the simple transmit to this board, but for 9/10 runs, it doesn’t transmit. Everything returns DWT_SUCCESS and but no joy. I’ve tried the dwt_setlnapamode(1, 1) to see what was happening and I know it is not transmitting (no spikes on o-scope for PA). When it does transmit, I can see the transmission with a DecaWave development kit running the simple RX example program. I’ve talked to DecaWave Engineers about this and they don’t know why it doesn’t work – they have looked at my code with no suggestions.

For the KL05 board, I can get the device ID, but the simple read/write test fails, everytime. I’ve tried multple modes, etc. Nothing seems to work. The screen capture from the Beagle posted above was from this board.

DecaWave has told me it must be the processors, but I find it hard to believe that NXP’s SPI implementation is broken when I’ve been using it on multiple projects for years.

If anybody has ANY ideas, I’d love to hear them.

Thanks,

Brad

I was able to get it working with the KL05 board. It appears that the problem was the chip select changing between bytes. I bit banged it and forced it low for the entire transfer and it works.

I need to try it with the K22 board when I have time. The SPI module on it has a “CONT” flag to keep the CS pin low, and it is on, so I don’t know what the problem is there.

Thanks for the help everyone.

Hi Brad, thanks for sharing the update! Maybe it needs to be made clearer as well in the DW1000 documents. We will take a look.

It’s not a complete success. I switched to bit banging to avoid the SPI module and some radios work and some don’t. Near as I can tell the SPI is just flakey. I have an SPI bus analyzer that can read it just fine, but some of the radios can’t. For instance, I’m reading a transmission from the receive buffer and a few bits get shifted (compared to what is sent and what the development kit receives) – but only on some radios.

We basically have nothing that we can point to that works every time.