I’ve been trying to get the DWM1000 to work on my STM32 dev board.
When loading the LDOTUNE_CAL (as described in user manual 2.5.5.11), the way to know if the loading is done, is polling the OTPREAD bit from the OTP_CTRL. If it’s 0, then the operation is done.
When I do this, however, the bit always stays 1.
I’m using this library, and I’m quite sure the proper commands are being sent over the SPI connection.
What could I have done wrong? Could the chip be defect?
This is the library code that does it:
// hl.rs, line 114
// Set LDOTUNE. See user manual, section 2.5.5.11.
self.ll.otp_addr().write(|w| w.value(0x004))?;
self.ll.otp_ctrl().modify(|_, w|
w
.otprden(0b1)
.otpread(0b1)
)?;
while self.ll.otp_ctrl().read()?.otpread() == 0b1 {}
(Also, the RSTn may have accidentally been pulled high for a couple of milliseconds due to some old code that was still present when booting it up the first time. I wasn’t aware when connecting that this could harm the chip. I can’t find what would break, though, when it happens)
Hi,
I’m not familiar with the code from that website, and so could I ask you why not using the examples we have have , especially becuase you’re using a STM32 processor.
Anyways, could you confim you are using slow SPI (< 3MHz) and system clock set to XTAL for this LDE load operation…
Maybe you can read the Chip ID to check if the IC is ok.
see example API attached. DW1000_Software_API_Guide_rev2p7.pdf (1.5 MB)
Also consult the UM, section 6.3 on the OTP
Regards
Leo
I’m using this library, because the project is written in Rust. If this doesn’t work, then I might indeed try the official code examples.
I’ve tried many SPI speed settings, because that was a concern of mine too. Right now I’ve got it set up very slow at ~30KHz. I can read the Chip ID just fine as well.
When booting the chip, I’ve tried to set PMSC_CTRL0.SYSCLKS to 1 which forces the system to run off of the the 19.2 MHz XTI clock. That didn’t work, so I also tried 2 which forces the use of the 125 MHz PLL clock. That didn’t work either.
Now, for the actual loop: The UM says that another write to 0 should be done.
I’ve removed the loop and changed it to what the UM says. It now gets stuck somewhere else.
Fixing that, I notice that writing to the chip seems to give inconsistent results. Sometimes a write seems to succeed and sometimes not.
I will try to add a capacitor close to the chip to see if that solves the problem. If not, I’m afraid I’ve destroyed the chip and have to order new one(s).
My problem has been solved.
I got a new radio module to test with, but it had all the same problems. I was just about to look at the official code samples, but before that I tried to change one thing.
For development, I like to use a software SPI connection. This allows me to plug in any device in any free pins I have. Now I’m using the SPI hardware peripheral at 100 kHz and everything just works (also the old chips that I thought I may had blown up). Very strange.