CCS/CC2650: Issue with osal_snv_write after an OAD

Hello Simone,

There was an anomaly related to OSAL_SNV=1 (single page SNV) in which the SNV data page was erased after the first device reset following initial SW programming. This was addressed in BLE-Stack v2.2.1. Did you confirm that your data is retained after OAD? Are you updating the SNV page during OAD? We did not test the fix with BLE-Stack v2.1.x, although you can probably cherry pick the nvocop.c/h files from the 2.2.1 release if this is the phenomena you are observing.

Also, how are you initiating a device reset?

FYI, you list an 8kB range (2 flash pages) with 0x1D000-0x1F000; I think this is just a typo.

Best wishes

Hello JXS,

first of all thank you very much for your quick answer. I can confirm you that the issue is only with OSAL_SNV=1. We changed to 2 and the not volatile memory is working fine. Unfortunately some configurations of our FW are quite big and we need to have OSAL_SNV=1 to save memory (In the future we are going to use the new CC2640R2 to have more flash but this is not an option for our PCBs already in production).

I tried the changes in nvocop.c/h files from the 2.2.1 release but they did not work. Maybe I can send you in a private the message the changes then you can confirm them.

We do not need to retain data during an OAD but, after an OAD, it would be nice if we can start to store our data in the not volatile memory directly, without to perform another reset. To do that now we are using this API:

SysCtrlSystemReset();

Which is working fine but we would like to avoid it. Is there something else we can try to do?

Thank you very much for your support.

Kind Regards,


Simone Frau

Hello JXS,

could you please describe which are the side effects of using OSAL_SNV=1 instead of 2?

You said something about an anomaly after the first device reset and in the SW guide it is mentioned something about power-loss issues during compaction and performance degradation due to the temporarily disabling of the cache.

Do you know something else?

Thank you for your support.
Kind Regards,

Simone Frau

Hello Simone,

I'm assuming you have read the description of OSAL_SNV=1 vs. 2 in the SW Dev Guide (SWRU393) so I will not restate.

The only known anomaly w.r.t OSAL_SNV=1 was addressed in BLE-Stack 2.2.1 to fix the issue where data was lost after first time program.

Did you inspect the contents of SNV after an OAD? You should be able to extract with SmartRF Flash Programmer 2 and compare with the code.

Best wishes

Hello JXS,

can you help me to extract the content of the SNV from SmartRF Flash Programmer 2?

I suppose using OSAL_SNV=1 I have to read page 30 (From 0x1E000) but this is the content:

I just wrote one byte = 0xAB in the location  BLE_NVID_CUST_END  0x8F  but there is a sort of coding. With this tool I am not reading the exact content of one allocation memory...

Kind Regards,

Simone Frau

Hi Simone,

To read the NV flash, first look for the id which will be followed by length. Then, from the id, move backwards the number of bytes specified by the length. I marked up your image to show where your value was written.

It seems like the value was written ok. From your log, it looks like there were multiple resets. Can you show the contents after the first reset?

Hello Rachel,

thank you for your answer, now I can see my value. Can I ask you to explain me how do you see the multiple resets?

These resets are normal in our system because to face the issue to lose values saved in the SNV memory we had a check during initialization. Basically we write this 0xAB byte and we reboot the first time, in the second initialization we check if the value is that one otherwise we reboot the second time (Both of them using SysCtrlSystemReset() ). Usually we then have three initializations, I asked your collegue JXS to suggest me other solutions.

Anyway in this way everything is working but unfortunately it is difficult to give you the contents of the SNV memory after the first reset because, as I explained you, this is done by software and I can not know when to use SmartRF Flash Programmer 2 in the middle of the resets for that...

Hi Simone,

I saw the resets in the log of SmartRF Flash Programmer 2. Are you following the example in our Software Developer's Guide? What is the return value of the osal_snv_write function in the failed cases?

Can you confirm that you made the changes to nvocop.c that JXS recommended earlier?

Hi Rachel,

I can see the indication of the resets in the log of SmartRF Flash Programmer 2, but this is just an unfortunate coincidence, after the flashing I read the BLE MAC address of the device. This is why there are these messages in the logs. Indeed it is not possible to see the internal reset of the FW during initialization, for that it was quite a bit strange for me.

The return values of the osal_snv_write function in the failed cases is SUCCESS = 0, this is why I need to write a byte and check the value after the reset. If I do not perform any reset the osal_snv_write and the osal_snv_read functions look like they are working fine (return value and read values are correct), but this is not true because if I remove the power I lose my data. This happen ONLY the first time, what does this mean? It means that if after an OAD I perform another reset, and from that moment I start to use the SNV memory, everything is working fine (also after several powering off).

I tried the suggestions from JXS but they did not work. Actually the differences between nvocop.c in the BLE-Stack v2.2.1 and the v2.1.x are minimum. Are you sure the fixes are in this version and not in a further one?

Thank you very much for your support.

Kind Regards,


Simone Frau