CC1312R: Need help using NVS in OAD project

Hi MH,

Could you elaborate on what you are trying to do more exactly, are you trying to add an additional NVS region in parallel to the others or simply replace the one normally used in the "flash_interface" implementation?

Hi M-W,

I am trying to add a third region in parallel for storage unrelated to OAD. Some of my app's own internal data needs to survive reboots.

Hi MH,

In that case, why do you modify the flash interface files used by the stack? Even if you do the init at some other location, the NVS params in the flash interface file as this would still be needed internally.

As it is not super clear what you are doing, it almost sounds like you are modifying the flash_interface_* files to do what you want, I would expect that you leave these alone and use the NVS driver for your third region without the "internal flash" interface in the example. Could you elaborate on why you saw the need to comment out the parameter initialization in the stack flash interface files?

Hi M-W,

I read a post here by a TI employee stating that NVS_init() should only be called once in a project.

Besides, I am having the same problem whether the code in flash_interface init is commented out or not.

So, for the sake of clarity, let's pretend I have not touched anything but app code. All I intend to do is store some data in NVS from within an OAD-based project. 

Any pointers where I should look next?

Hi MH,

That is true for the NVS_init() function (for some reason, we did not add a guard for this but lets not focus on that). The NVS_Params_init() function however is a requirement to call before all the open calls. If you do not chances are that you are just opening up the driver with gibberish parameters. 

I would verify that the handles are not mixed up for some reason (both being unique). Then I would put down a few breakpoints in the OAD part of the application to try capture the OAD events and see if they fail their NVS operation for some reason (check return statuses of these etc.). As it uses the "flash interface" files it should be rather easy to put breakpoints down to capture this. 

Hi M-W,

I had already stepped through the flash-related code in OAD, and operations all returned 0 (SUCCESS). I had also tried only commenting out the NVS_init() line in flash_init(), with similar results.

I will do this again and verify if the problem is the same at the collector and report back.

Hi M-W,

confirming the exact same problem with:

void flash_init(void)
{
//    NVS_init();
    NVS_Params_init(&nvsParams);
}

in flash_interface_int_rtos.c

Reading from flash is successful just before the system reset:

Hi again M-W,

in the last instance, I believe the device resets into the persistent FW as it should, but still fails to perform OAD. 

I built the simplest test case I could think of. Starting from the SDK 4.10 project

sensor_oad_onchip_secure_CC1312R1_LAUNCHXL_tirtos_ccs

I have added

then in main.c main(), I have added basically the same NVS code:

int main(void)
{
    Task_Params taskParams;

#ifndef USE_DEFAULT_USER_CFG
    macUser0Cfg[0].pAssertFP = assertHandler;
#endif

    /*
     Initialization for board related stuff such as LEDs
     following TI-RTOS convention
     */
    Board_init();

    // test code below

    NVS_Params nvsParams;

    NVS_init();
    NVS_Params_init(&nvsParams);
    NVS_Handle nvsHandle = NVS_open(CONFIG_NVS_0, &nvsParams);
    char test[11] = {"Some string"};
    
    // uncommenting this line prevents OAD from working later on, it works otherwise
    // NVS_write(nvsHandle, 0, (void *)test, 11, NVS_WRITE_ERASE | NVS_WRITE_POST_VERIFY);

Writing to NVS breaks OAD functionality, but the sensor keeps working. I have validated that the data is written correctly:

and also commented out NVS_init(); from flash_interface.

If you can please confirm my findings and provide a workaround, or maybe point out what I am doing wrong, it would be appreciated.

Hi M-W,

if I understand correctly, the linker file for OAD_IMG_B should have its FLASH_END at 0x2A000, right (at least in the TI project files)?

Your diagnosis of memory corruption is correct, and the actual fix in my case was to make a bit more room for my app, such that I can use room between 0x2A000 and 0x2C000, and have the persistent app start at 0x2C000.

Thanks for your help!