DW3000 User manual missing information present in the drivers

Wireless Connectivity Ultra-Wideband
1

In the DW3000 user manual the register REG:11:04 – CLK_CTRL – PMSC clock control register lists bits 11 and 12 as reserved and should always be 0.

In the DW3000 driver the function dwt_force_clocks() contains the code

if (clocks == FORCE_CLK_SYS_TX)
{
    uint16_t regvalue0 = CLK_CTRL_TX_BUF_CLK_ON_BIT_MASK | CLK_CTRL_RX_BUF_CLK_ON_BIT_MASK;
    //SYS_CLK_SEL = PLL
    regvalue0 |= ((uint16_t) FORCE_SYSCLK_PLL) << CLK_CTRL_SYS_CLK_SEL_BIT_OFFSET;
    //TX_CLK_SEL = ON
    regvalue0 |= ((uint16_t) FORCE_CLK_PLL) << CLK_CTRL_TX_CLK_SEL_BIT_OFFSET;
    dwt_write16bitoffsetreg(CLK_CTRL_ID, 0x0, regvalue0);
}

The two lines forcing the clock mode match up with the user manual however given the #defines in the header file of

#define CLK_CTRL_TX_BUF_CLK_ON_BIT_MASK      0x1000U              
#define CLK_CTRL_RX_BUF_CLK_ON_BIT_MASK      0x800U

this code is also setting bits 11 and 12, bits that the user manual indicates should never be set.

So which is it? Are these bits reserved or do they need to be enabled when entering CW mode?

My guess is that the driver is correct and the manual is missing the required information. But how many other omissions like this are there? If the manual is missing information like this what use is it?

The supplied source code clearly indicates that more detailed internal documentation exists, other registers are made up of various flags in the source code while the manual contains a fixed magic number to use. While I understand that the full internal documentation can’t be published it would be nice to at least have documents with enough information to use the part and create drivers for it.

When can we expect a user manual that actually includes all the information required to drive the chip?

1 Like
2

A second example of this: The driver in various places sets various flags in a register called LDO_CTRL.

LDO_CTRL_ID is defined as 0x70048 meaning register 7, offset 0x48. The user manual doesn’t even mention that this register exists.

The driver also includes the definition of a couple of LDO_TUNE registers which are also missing from the documentation. Since OTP_CTRL includes a bit to automatically load LDO tuning from OTP I’m hoping there is no need to touch these although it looks like one of them does need to be modified in order to perform an OTP write.

3

Did you ever get an answer to all of this? Or figure out how to extract enough “magic” to do what you want? (Edit: Looks like a lot of it got covered in this other forum thread…)

4

Indeed some of it got answered there. In the end I shoehorned the decawave supplied drivers into my existing firmware structure rather than try to reverse engineer them.