step by step guidelines of programming OTP

Hi achao1104,

1) Please check this forum posthttp://support.dialog-semiconductor.com/can-you-please-provide-guides-bu...

2) You can find info about using Smart Snippets in the Smart Snippets help option User Guide.pdf.

3) It depends on what you want to do (with the OTP mostly) if for example you need to read your NVDS from your OTP or boot you should define that, as mentioned in your previous post, other than that the DEVELOPMENT_DEBUG should be set to 0 and the CFG_BOOT_FROM_OTP if you are going to use OTP. Also if you should #define the CFG_WDOG

4) If you have burned the OTP Application flags (check the AN-B-001.pdf) the serial boot sequence will not execute anymore and only the JTAG programming over JTAG is possible..

Thanks MT_dialog

I am trying to use the Dialog Serial Port Service in a Panasonic PAN1740 based design, and whilst it all works perfectly when I download my hex file directly to RAM, it does not work when I program it into the OTP memory. Because the memory is OTP (why on earth was this ever chosen to be so), I now have 2 boards I cannot use and my concern is that I am going to continue scrapping boards until I identify what I am doing wrong.

Up to this point I had found the Dialog documentation excellent and very thorough, so the lack of an application note that steps through the process of programming an OTP application seems to be a major oversight, particularly given the number of posts about similar issues.

I am using the following project from the DSPS SDK:

DA1458x_DSPS\v_5.150.2\projects\target_apps\dsps\sps_device\Keil_5

From piecing together various other posts, I made the following changes to the project before building the code for OTP:

1 da1458x_config_basic.h: "#define CFG_DEVELOPMENT_DEBUG" replaced by "// #define CFG_DEVELOPMENT_DEBUG"
2 da1458x_config_advanced: "#undef CFG_BOOT_FROM_OTP" replaced by "#define CFG_BOOT_FROM_OTP"

Using Booter in the SmartSnippets Toolbox (V4.7.3.1690) I successfully downloaded the hex file to RAM of the device and was able to verify that it ran correctly by connecting to it using the DSPS app on my phone.

I then used OTP Programmer in the SmartSnippets Toolbox and successfully downloaded the same hex file to the device but was then unable to detect the device using the DSPS app on my phone.

I didn't download an OTP Header or OTP NVDS as I am unsure if these are mandatory, and if they are required then I am unsure what I need to actually set.

Since the OTP image is simply loaded into RAM and run from there, why can I run the hex file directly from RAM but not when saved in the OTP?

Help!!!

Hello,
I can confirm that I had set both the OTP Application flags to Yes but as I had been trying various things I decided to restart the whole process with a new device.

Having proven the firmware in RAM from within the Keil uVision IDE (first with CFG_DEVELOPMENT_DEBUG defined and then with it undefined), I then downloaded it to RAM using the Booter tool in the SmartSnippets Toolbox and again confirmed that the code ran correctly.

I then used the OTP Programmer in the SmartSnippets Toolbox to successfully download the same hex file to the OTP memory. I then made the following changes to the OTP Header:

1 - both Application flags set to Yes
2 - DMA length set to match the code size (later set to 0x1FC0 to specify the entire OTP image space).

Having successfully downloaded the OTP Header I then disconnected the Vpp and SWD connections and rebooted my target, but the PAN1740 does nothing (should periodically output some data on the UART and the device is not showing when I scan for Bluetooth devices).

The fact that code is only stored in OTP and is copied to RAM from where it runs, tells me that if the code runs correctly when loaded directly to RAM, then the issue with the OTP code must be to do with the header or the loading of the code from OTP to RAM, as it is EXACTLY the same code.

Are there any other Header settings that I need to set?

What does the Remapping Flag do and what should it be set to?

Is there any documentation that details all the Header fields?

Because I'm actually using a PAN1740 Bluetooth module which contains the DA14580, will some of the Header fields already have been set by the PAN1740 manufacturer? For example, the XTAL16MHz Trim Value on my device has a value of 0x5BD (1469), but the default value defined in the arch_system.h file of the SPS project code is 0x516 (1302).

I assume that when downloading code directly to RAM then default hard coded values are used and not those from the OTP Header, so the fact that the code runs ok from RAM but not from OTP, could this suggest an issue with some other values of the OTP Header?

My big problem is that my project is currently at the prototype stage and so I only have 4 units available to me. To date I have programmed the OTP memory of 3 of the units, all of which do not run the code, so now I only have 1 board left to try and so I HAVE to get that one right.

Would it be possible for you to test with my hex file to at least confirm that it is not this that is at fault? I have attached the hex file in anticipation that you will be able to do so.