CC2642R: CC2642R flash memory

Hi Ryan,

I have a related question.  When do a osal_snv_read, I got back a 1 for the return.  What's the issue?  I couldn't find the description of the error code.

Thanks

Victor N.

Most likely it can't find the NV item if it hasn't been previously initialized.

uint8 osal_snv_read( osalSnvId_t id, osalSnvLen_t len, void *pBuf )
{
#if !defined( NO_OSAL_SNV )
  uint16 offset = findItem(activePg, pgOff, id);

  if (offset != 0)
  {
    HalFlashRead(activePg, offset, pBuf, len);

    return SUCCESS;
  }
#endif // !NO_OSAL_SNV

  return NV_OPER_FAILED;
}

Regards,
Ryan

It has been initialized and worked for a while.  Then, all of a sudden, it can't be read or written with osal_snv_read or osal_snv_write anymore.  It returns a 1 for both calls.  I dug a little deeper into the code and found that this function call NVOCMP_findItem returns an 0x0A which in turns make the read and write failed.

Regards,

Victor N.

What do you mean by "worked for a while"?  Are you using osal_snv_* functions directly, and do you ever erase contents?  Is behavior reset if you erase all memory and re-program the device?  Status 0x0A is NVINTF_NOTFOUND.

Regards,
Ryan

We are using the SNV to keep about 1K of data for configuration and status.  We create a task to read and write the SNV.  In the task, we use osal_snv_read and osal_snv_write.  In our code, we do regularly update four of those configuration/status bytes stored in SNV.  We're able to update those bytes until it gets into the issue where it can't read and write anymore.  I reset, recycle power and the problem doesn't go away.

If I erase all memory and re-program the device, the behavior is reset and the SNV works again.

Thanks for continuing to assist me.

Victor N

You can review the Flash section of the BLE5-Stack User's Guide for an example OSAL SNV implementation.  Make sure that you are using SNV_ID_APP definitions in accordance with the BLE_NVID_CUST_START/END range.  If you are exceeding the maximum of 83 write operations allowed per row (2046 bits) before a sector erase must occur , as shown in Section 8.7 from the Datasheet, please ensure that you are accomplishing erasures manually.  It may be better for your needs to create a custom NVS area in SysConfig and use the NVS Driver and nvsinternal example instead of osal_snv_* commands.

Regards,
Ryan

Regarding the erase after 83 write operations, I thought you said in your first response that it is handled by the osal_snv_write/RTOS.  We don't need to manage it in our application.  Did I understand your response incorrectly?  Could you confirm again that do we need to keep track of the write operations and erase it after 83 write operations?

Thanks again,

Victor

Hi Victor,

I have looped in a relevant expert to provide some insight.

Best Regards,

Jan

Another related question.  Is calling osal_snv_read and osal_snv_write directly without using iCall bad?  Could it cause any problem?

Thanks

Victor N

Hi Victor,

I confirm your understanding, compaction is automatically handled by the driver (see https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_5_40_00_40/docs/ble5stack/ble_user_guide/html/ble-stack-common/flash_memory-cc13xx_cc26xx.html - search for "compaction").

When it comes to the issue consisting in having osal_snv_read or osal_snv_write returning "1", I guess this is due to the NVINTF_FAILURE (see source/ti/common/nvnvintf.h) returned by NVINTF driver (please refer to the first link I have shared for details). Under the hood, NVINTF_FAILURE may be caused by some bad parameters passed to the NVOCMP driver.
As the driver first works properly for a while, the issue could be due to a corruption of the data structure holding the configuration. Maybe this could be due to some memory (heap or stack) shortages. I guess you could verify this with the ROV.

To finish, when adding a new task that makes protocol stack API calls, including calls to OSAL SNV, the task must register with ICall.

I hope this will help,

Best regards,