We have a new board that uses a DW3220 IC (coupled to an STM32L433) that we’re trying to bring up. We’ve used the dw1000 extensively with several MCUs in the past. We integrated the binary dwt driver (6.0.7) into a new project, which builds and appears to be working. PCBA connectivity looks good as we can read the Device ID from the MCU directly via SPI, as well as through the binary driver (e.g. dwt_readdevid()) which we’ve traced through to our SPI access functions via the debugger.
I’ve further verified that EXT_ON is driven high and a call to dwt_checkidlerc() indicates the dw3220 has transitioned to IDLE RC. A subsequent call to dwt_initialise() returns ok. However, every time we try to configure the transceiver using dwt_configure(), it returns -2 (which seems to indicate a failure to PLL lock). Checking the status register directly, this seems to be the case as the CPLOCK (bit 1) remains cleared. We’re using a standard channel configuration for both channel 5 and 9 lifted directly from the simple tx and rx examples in the driver package. Additionally, as a shot in the dark, we increased MAX_RETRIES_FOR_PLL (defined in deca_device_api.h), but observed the same result.
Is there something else that must be initialized on the dw3220 that we’re missing? Any clues on what to look for when the PLL won’t lock?
As a follow up on this, given this is the first time we’re using an IC (DW322) rather than our previous work with the DWM1000 module, the OTP would not be configured with the PLL lock code or an XTAL trim value.
So, to verify the configuration I read the XTAL_TRIM and PLL_LOCK_CODE from the OTP (OTP offsets 0x1e and 0x35 respectively). The XTAL_TRIM value was 0 and the PLL_LOCK_CODE was 0xF04.
Then I checked the Frequency synthesizer control block registers (starting at offset 0x9) after dwt_initialize() had completed. I found that:
PLL_CFG = 0x0
PLL_CC = 0x6F
PLL_CAL = 0x0
XTAL_TRIM was 0x0.
I then set these to:
PLL_CFG = 0x1F3C
PLL_CC = 0xF04 (from the PLL_LOCK_CODE in the OTP above)
PLL_CAL = 0x31 (although register diagram shows (PLL_CFG_LD is bits [7:4], where as the description says PLL_CFG_LD is bits [7:2] in the DW3000 User Manual, so I’m unsure which is correct. I’m assuming that because the default value of 0x31 mentioned in the description is consistent with the bits set in the diagram, the diagram-based delineation of PLL_CFG_LD is incorrect.
And then I tried to call dwt_configure(), but had the same results (-2, DWT_ERR_PLL_LOCK). Then I decided to iterate through XTAL_TRIM values (0 to 0x3F, which seems to be the upper limit) and call dwt_configure() after each updated XTAL value was set using dwt_setxtaltrim(). This didn’t work either.
I also noticed that the PLL_CAL and PLL_CC registers did not change when I wrote to them. The PLL_CFG and XTAL_TRIM registers did seem to update appropriately. Not sure if PLL_CAL and PLL_CC are locked or something?