[color=#212121][size=medium]I want to write data to the DW1000 OTP memory. I looked at the manual and tried to use the source code provided in the OTP memory to write to it, but it seems to not work properly. Even if I reset the device, I want to set the address to the device with the data in the OTP I wrote earlier. I would appreciate if you can find out which part to look at or if there is an example function provided by RTLS F / W version 1.05 or 3.11 version.[/size][/color]
[color=#212121][size=medium]Help me. [/size][/color]
[size=large][color=#222222]Our API has functions for OTP reads and writes and verify. See deca_device.c in our example programs. [/color][/size]
[size=large][color=#222222] @brief This is used to program 32-bit value into the DW1000 OTP memory.[/color][/size]
@param value - this is the 32-bit value to be programmed into OTP
@param address - this is the 16-bit OTP address into which the 32-bit value is programmed
returns DWT_SUCCESS for success, or DWT_ERROR for error
int dwt_otpwriteandverify(uint32 value, uint16 address)
int prog_ok = DWT_SUCCESS;
int retry = 0;
// Firstly set the system clock to crystal
_dwt_enableclocks(FORCE_SYS_XTI); //set system clock to XTI
//!!! NOTE !!!
//Set the supply to 3.7V
[size=large]And more, see [color=#222222][size=large]deca_device.c[/size][/color][/size]
[color=#222222][size=large]The User manual explains this process and what is required. For example, one should increase the supply voltage to the VDDIOA input for the OTP write.[/size][/color]
[color=#222222][size=x-small][font=Times New Roman][size=large][size=large][size=small][size=large]See section IC user manual in section 6.3.2 on programming the OTP (Page 60) [/size][/size][/size][/size][/font][/size][/color]
I have a question related to OTP programming.
We have a PCB design incorporating a DW1000 which I’d like to program an EUI64, XTALT, and antenna delay to the OTP. It does not have an external way to drive the VDDIO (or VDDIOA) to 3.8V though (currently 3.3V). This says “optimal programming” requires this. Does this mean if we don’t drive the VDDIOA line to the higher voltage it may still work?
How is this normally recommended? Does Decawave recommend exposing a contact for this line for a POGO contact board (or similar) which will only be used during manufacturing “burn in” of EUI64, etc?
What happens if I don’t drive these lines? Will OTP programming just not execute at all, or do I risk actually ruining the OTP memory?
I’ve never had a problem programming the OTP using 3.3V. Maybe I’ve just been lucky but it has worked fine for ~20 parts purchased over a long enough time that they should be from at least three different batches of chip.
Hearing this, my guess is that it’s not an issue most of the time, but perhaps on a marginal DW1000 OTP, the 3.3V could potentially not get enough charge on the gates to actually program the flash to the desired level.
I actually haven’t gotten around to trying it myself yet.
Andy, I have finally gotten around to testing this with the base 3.3V on a DW1000. The OTP programming procedure doesn’t appear to work with this.
I am about to rig something up to allow me to apply 3.8V to the VDDIO pin on the DW1000 to see if my firmware procedure works. Will let this thread know how that goes afterwards.
I’m wondering if you write the OTP successfully. The OTP memory is a one-time-program register.It seems we can only write once
Hi Leo, Lincoln, Andy,
I’m about to read/write the OTP memory on several DW1000 and I cant get it to work.
What I have tried so far:
- dwt_otpwriteandverify() single word using VDDIO = 3.3V Failed
- dwr_otpwriteandverify() single word using VDDIO = 3.8V Failed
(selected battery with proper voltage and connect battery plus with VDDIO pin)
Reading OTP fields shows changes in some bits but no exact numbers previously written could be found.
Can you please direct me to what else should I check?
Could I ask you what SPI speed you’re using The speed requires to be 3Mhz , so please lower the SPI rate if you haven’t done so yet.
thanks for your reply. Indeed lowering the spi speed during otp operation did solve the problem.
I also need to mention that otp read operation needs slower spi clock as well.
Thanks for your support.