CC2642R: OAD: Persist SNV pages

Hi Andres,

Great question.

NV memory has different handling in the OAD case and doesn't go through the "usual" stack manor of writing.
The OAD NV writes skip over the the osal_snv layer and use the TI-RTOS NVS driver directly.

A more detailed explanation:

The osal_snv layer basically wraps the flash writes with a header in order to index, optimize, and minimize writes to memory. Once you read back through the osal_snv layer it uses the headers it added before to manage finding and indexing the data stored.
In the OAD case, the written data is in binary form and meant to be the application itself (not variables read with the osal_snv API functions) and there is no need for the header.

What functions are you currently calling that are failing to persist?

Best Regards,
Yuval

(If you want to get a more detailed understanding of the flash memory layout on the CC2642 you can also check out the chapter on flash in the User's Guide.)

Hi Andres,

I'm going to close this post due to inactivity. To reopen this thread, just post a follow up question. Otherwise, after 30-days of inactivity from this post, this thread will lock.
 

Best Regards,

Yuval

Hi,

Sorry for the late response.

I have added two user items to the SNV and those are not persisted after OAD. So I can't use the interface for storing calibration values etc.

I'm using "osal_snv_write" to create the items, and the ID's is 0x80 and 0x81

Hi Andres,

No worries, I apologize for my late response as well.

Try using the SNV driver functions directly to avoid the osal_snv wrapping.
You can see an example of a writeFlashPg call in the oad.c function oadImgBlockWrite.

/*!
 * Write data to flash using page and offset
 *
 * @param   page   - page to write to in flash
 * @param   offset - offset into flash page to begin writing
 * @param   pBuf   - pointer to buffer of data to write
 * @param   len    - length of data to write in bytes
 *
 * @return  status - @ref FLASH_SUCCESS if programmed successfully or
 *                   @ref FLASH_FAILURE if programming failed
 */
extern uint8_t writeFlashPg(uint8_t page, uint32_t offset, uint8_t *pBuf,
                            uint16_t len);

Just make sure you are writing to a page that will not get overwritten in an OAD later on.

Best Regards,
Yuval

Hi Yuval,

The reason i'm using the snv interface is to be able to store data in in the two page onchip storage. I want' to avoid using the external flash as this is controlled by a filesystem and not by direct page writes.

So ideally I would like to preserve the onchip NV pages during an OAD.

Best regards

Anders

Hi Andres,

I'm sorry for the delayed response, I wanted to verify why exactly you were not able to write to ID 0x80 & 0x81, and I might have an idea why this is happening.

Can you succeed in writing to ID 0x90?

Best Regards,
Yuval

Hi Yuval,

I have no problems writing the items 0x80 and 0x81. They are just erased when I do OAD with a new firmware build. So my data is stored correctly and can be loaded after power down until the FW is updated using the OAD feature - Then the contents are erased. And that is my issue - I would like to preserve the stored contents after the OAD procedure too.

Hi Andres,

I understand that the writing part is down successfully.

My suspicion is that what happens later is that this NVID gets overwritten.

The reason I am asking you to write to a different ID (basically, not to 0x80) is because there is part in the main offchip oad application file that saves the "sendSvcChngdOnNextBoot" a NV with the ID of BLE_NVID_CUST_START (0x80).

This might be a design flaw as this ID is supposed to be reserved for customer use, yet it is being used in the example.

If you could verify that when writing to a different NVID the data persists this would confirm that this is the issue.

Best Regards,
Yuval