• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 51 subscribers
  • Views 1040 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2650 SNV

Feras Qammou
Expert 2080 points
Other Parts Discussed in Thread: CC2640

Hey,

I was working on simpleBLEPeripheral project, I added a code to read and write to the SNV like:

ret_val = osal_snv_read( DATASTORE_MANAGE_ID, sizeof( DATA_Manage ), (void*)&DATA_Manage );

SNV_Success = osal_snv_write( DATASTORE_MANAGE_ID, sizeof( DATA_Manage ), (void*)&DATA_Manage );

the only change I did is trying to change from the properties -> General -> variant from CC2640F128 to CC2650F128, I realized that this caused a compilation error like redefinition the Flash addresses... I saw in the forum that the reason is that when I change the variant it is automatically changing the linker command line to be cc26x0f128.cmd which makes multiple definition then I should choose "none" not to let this linker to be added...

OK I got back to the original situation with CC2640F128 and choosing "none" for linker command line so it is compiled now and the BLE is running and so UART...

and this change and I changed it back only in the application project and not the Stack...

now I have the error:

SNV_Success = osal_snv_write( DATASTORE_MANAGE_ID, sizeof( DATA_Manage ), (void*)&DATA_Manage );

4 = MSG_BUFFER_NOT_AVAIL that is returned from the osal_snv_read !

I have doubt that that something went wrong with flash addresses when I tried to change the variant by the linker!

can be?

please direct me to solve this problem!

Thanks.

  • 0
    TI__Guru** 105180 points
    Hello,

    Where did you add these API calls?
    Yes, as you can see from the sticky CC2640 FAQ thread & Dev Guide (SWRU393), it's not advisable to modify the CPU variant setting.

    Best wishes
  • 0 in reply to JXS
    Expert 2080 points
    OK!

    so it is not depend on the variant...

    I wrote again to the SNV from ID 0x80 to 0x8F, every ID with size of 200 bytes, then I succeede to read!

    OK I am doing these calls in a periodic event after initialization!

    first of all I am doing :
    bool SNV_Initiated = FALSE;

    do
    {
    ret_val = osal_snv_read( DATASTORE_MANAGE_ID, sizeof( DATA_Manage ), (void*)&DATA_Manage );
    }
    while( ( SNV_Initiated == FALSE ) && ( ret_val != SUCCESS ) && ( ret_val != MSG_BUFFER_NOT_AVAIL ) );

    if( ( DATA_Manage.First_Signature != DATASTORE_FIRST_USE_SIGNATURE_VALUE ) || ( ret_val == MSG_BUFFER_NOT_AVAIL ) )
    {
    if( SUCCESS != DATA_Erase() )
    {
    DeviceState = STATE_SNV_ERROR;
    }
    }

    means that I am waiting till the SNV has been finished initiation after the call from the stack project by keeping reading the first 0x80 Item.

    then if did not return Successful, almost 4 = MSG_BUFFER_NOT_AVAIL...

    I already wrote to these Items 0x80-0x8F Yesterday! then I succeeded to read all of them, turning off the sensor tag that I am working with by disconnecting the cable =and the DevPack, then reconnecting and debugging and I succeeded to read back all Items witheout the error 4 = MSG_BUFFER_NOT_AVAIL!

    but today the problem again that it returns 4 = MSG_BUFFER_NOT_AVAIL !!!

    seems that something wrong with the flash?!

    it is critical for me because I need to store important data to the SNV for this product and it is so critical to fail to read back Items which I stored onetime data on them!!

    any advises please?!

    Thanks.