Hi,
I am unable to perform an OTP program. Maybe is caused by discrepancies found between headers data sent to OTP and the data that is actually written. As you may see in the attached screeshots, there are differences between the sent data and the written data. It seems the data burned is different to the one I specified.
Right now the device is toasted.
Any know bug on this? thanks.
Ed
Attachment:
Device:
Hi edlofau,
I dont think that i ve heard any issues regarding the OTP burning, from what i can see from the image you read the OTP NVDS in different offsets, the one is 40000 and the other is 44000, also in the NVDS section there is a flag that allows data to be inserted to the NVDS area, the flag is CFG_INITIALIZE_NVDS_STRUCT. If you burned that image with this flag set then you 've burned the NVDS area with that data as well and not only with the data that you ve set with the OTP NVDS burner.
Thanks MT_dialog
Hi,
Thanks for your reply.
I am not able to find this flag, as you can see in the picture it is not present.
In any case, I understand the issue can be caused by the offsets.
It´d be very helpfull having a brief summary of how to program the OTP. I am using the original example DSPS you provide for the DA14580 with no changes. The image was built with the debug flag = 0. I attached the data i want to program, maybe if you could take a quick look to identify some problems...
My main doubts are the two offsets available (for image and nvds), which values shoul I put?
Is there any other parameter should I take care with in order to perform a succesfull programmation?
Many thanks,
Ed
Hi edlofau,
The flag that i am talking about is located in the SDK and not in the OTP NVDS or the Header. If the image you ve burned had this flag enabled in the SDK the NVDS structure area was allready populated by the values that the SDK had. When you burned the NVDS data in the OTP you ORed the data allready in the OTP with the data that you wanted to burn in the OTP NVDS. The NVDS is not a seperate part of the OTP image. When you burn the image that the SDK created without the flag i mentioned previously there should be zeros in the NVDS area in order for you to burn the empty space of that area as the NVDS area from the OTP NVDS tool. The offset of the NVDS is 0x340 from the 0x4000 that is the starting address of the OTP.
Thanks MT_dialog
Hi,
Thanks for your reply.
I cannot find this flag in the DSDP example and I cannot find the DSDP in the SDK.
I found the flag in the SDK for the examples there written, in file DA1458x_config_advanced.h but this file is not present in the DSDP.
Thanks,
Ed
Hi edlofau,
In the SDK 5 DSPS this flag, as far as i can tell, is located in the da1458x_config_advanced.h in line 36 and this will initialize or not the NVDS struct located in the nvds.c file, line 41.
Thanks MT_dialog
我dowloaded SDK5herehttps://support.dialog-semiconductor.com/download/file/fid/2759and i am not able to find a project called DSDP.
Where is it placed? is it a keil5 project or ...???
Thanks and sorry,
Ed
Hi edlofau,
The project is called DSPS and its located under the reference design section on the support site.
Thanks MT_dialog
I see I was using an old verision of DSDP.
I downloaded the last one and finally find the da1458x_config_advanced.h file and the flag...
Thanks a lot for your patience.
Regards,
Ed
Hi again,
I have the DSPS code running OK in RAM (via smart snippets-booter), it makes the BLE serial bridge as desired. Now, in order to put in OTP I would like to have kind of checklist in order to burn correctly the OTP, as far I could learn:
1) Compile the with following flags in Keil5:
#define CFG_BOOT_FROM_OTP
#define CFG_INITIALIZE_NVDS_STRUCT
2)In SmartSnippets, in OTP section I burn the OTP image with the previous .hex(offset = 0)
3)Nothing to do for NVDS OTP (since the OTP image take care of it due to the CFG_INITIALIZE_NVDS_STRUCT)
4) OTP头——>许多窦bts: I guess I need to put to yes both first flags (app in OTP). But what about the other params? for the DSPS, do i need to load more things here??
Thanks!
Hi edlofau,
The steps that you mention are proper, regarding the last step, by burning the application both of the flags you will force the 580 to boot from the OTP and will not scan the peripherals for finding an image, by doing this and setting the DMA Length to 1FC0 (the length of the OTP image in words, you should set that in order for the full OTP to be copied to your sysram, just in case) you should be able to run the application from OTP. Regarding the other parameters you can check the Smart Snippets User Guide.pdf in order to check what the rest fields of the OTP header do. Also there are are quite a few forum posts regarding the OTP header burning procedure, please feel free to search the forum.
Thanks MT_dialog
Hi Dialog,
I am expecting to burn the header with the following values:
o Application flag 1 and 2 at 0x47F00 and 0x47F04 = YES
o 32KHz source section (4 bytes) at 0x47F74. External Xtal
o DMA length (4 bytes) at 0x47FF8 = 1FC0
I won´t programm the rest of values. Does it make sense?
And the last question. I observed that for deep sleep mode, i had no communication host<->device. However, for the extended mode, I had communication but lossing lot of characters in transmission. In order to configure them for instance in deep i used:
#undef CFG_MEM_MAP_EXT_SLEEP
#define CFG_MEM_MAP_DEEP_SLEEP
const static sleep_state_t app_default_sleep_mode = ARCH_DEEP_SLEEP_ON; (user.config.h)
Am I missing something? Should I take care of any other configuration at OTP programming?
Thanks a lot !
Ed
Hi edlofau,
Yes it does, make sure that the Remapping Flag has the SRAM at 0 (its the default, but just in case) and keep the JTAG enable flag enabled (this is also default) in order to be able to reconnect to the device via JTAG.
The DSPS supports only the extended sleep mode as the User Manual instructs and NOT deep sleep. I dont see anything missing, burn your device with the DSPS fw in extended sleep mode. Regarding the character loss check that you have enabled HW flow control and make sure that it is also enabled on your PC terminal, also check your connections with the RTS/CTS with your board.
Thanks MT_dialog
Hi,
Thanks a lot for your reply.
I will put then in extended. Do you know BTW what is the current comsumption when the device is not paired? And by the way, what is the current if sleep mode is OFF, and with the device not paired?
I don´t have RTS/CTS lines from my MCU so I am not using flow control. Could this be a problem?
Thanks,
Ed
Hi edlofau,
你可以找到相关信息消费意识的力量mption of the 580 in the Power Consumption FAQ's (sleep power consumption, transimiting, receiving). The consumption of the DSPS isn't any different, what makes the difference in the overall system is the advertising intervals and the connection intervals (the shorter they are, the more power you consume). Also in DSPS the power consumption depends on the ammount of data you transmit, when the device is transmitting the sleep mode is cancelled and the device stays awake until there are no data in the buffers. When the device is not sleeping it consumes about 0.6mA instead of the 1.4uA when is asleep. Additionally since not all central devices behave the same (accepting different advertising intervals, different number of packets in every connection intervals, etc), the power consumption also depends on the central that you are using.
Regarding the RTS/CTS, yes flow control is something that the device demands in order to operate, since it sleeps it has to have a way to notify the external MCU that it is awake or it has fallen to sleep, so that the external MCU will know when to send data and when to stop. Without it you are not going to be able to operate under sleep mode.
Thanks MT_dialog