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.

CC2640 : SNV Problem Due to MASS erase + Programming.

Other Parts Discussed in Thread: CC2640

hi,

i am using the Stack version (ble_cc26xx_2_01_01_44627) and TI rtos version (tirtos_simplelink_2_13_00_06).

Issue : 

Whenever do a fresh start (After MASS erase  + Flash programing) SNV is not working as expected.

Note :
This issue is happen only for MASS ERASE followed by FLASH Programing the stack and APP.


Scenario :
I am writing some data in SNV and read back the same data after the reset (pin (or) POR).

SNV Configuration is Default configuratin (8KB).
Hardware : SMART RF + CC2640 (chip version 2.2)
Stack : SimpleBLEPeripheral
 
Steps Followed to Reproduce ths issue:

Step1 :
Did Mass errase using the Flash programmer.

Step2:
Flashed the Stack and Appliction.

Step 3:
Application writen the data SNV based on Event (button press)
called SNV read and write in  ICALL Aware Task (BLE task).
ex:
  writeStatus = osal_snv_read (0x80, SNV_BUFFER_SIZE, osal_write_buffer);
 
Step 4;
reset the system(pin reset (or) POR), the written value is not retained after the reset (only for first reset).

Step 5:
continue the step 3 and 4 ,  the written value is retained after the reset.

Observations :
1)Whenever do a fresh start (After MASS erase  + Flashing) SNV is not working as expected.

If I am not do MASS erase before Flashig the SNV is working as expected.
 
2)After the MASS + Flash Programming, read the SNV location (my case address -> 1e000) using FLASH programer , in that values at (1e000-1e003) is FF FF FF FF .

3)If i do normal prgraming without MASS ERASE, read the SNV location (my case address -> 1e000) using FLASH programer , in that values at (1e000-1e003) is 00 00 10 00 .

(or)

After the first reset (STEP 4) if i  read the SNV Location the (my case address -> 1e000) using FLASH programer, In this case valeus @(1e000-1e003)  changed from FF FF FF FF to 00 00 01 00.

Observation 2 & 3 have any relation with this issue ? because observation 2 shows FF FF FF FF.


Kindly help me on this, i have to go for the production code.

code snipet ;

static void SimpleBLEPeripheral_taskFxn(UArg a0, UArg a1)
{
  uint8_t writeStatus;
  // Initialize application
  SimpleBLEPeripheral_init();
 
  snvTriggerButtonInit();
 
  writeStatus = osal_snv_read (0x80, SNV_BUFFER_SIZE, osal_write_buffer);
 
  LCD_WRITE_STRING("HELLO", LCD_PAGE3);
 
  LCD_WRITE_STRING_VALUE("VALU 1:", (uint8_t)osal_write_buffer[1], 10, LCD_PAGE6); // USED to check the SNV value After reset
   

              
  if((osal_write_buffer[0] == 0) || (writeStatus != 0))
  {
        osal_write_buffer[0] = 1;
        
        osal_snv_write(0x80, SNV_BUFFER_SIZE, osal_write_buffer);
        
        LCD_WRITE_STRING("writeDone", LCD_PAGE4);
  }
 // Application main loop
  for (;;)
  {

....

// Waits for a signal to the semaphore associated with the calling thread.
    // Note that the semaphore associated with a thread is signaled when a
    // message is queued to the message receive queue of the thread or when
    // ICall_signal() function is called onto the semaphore.
    ICall_Errno errno = ICall_wait(ICALL_TIMEOUT_FOREVER);

    if (errno == ICALL_ERRNO_SUCCESS)
    {
        .....

      //Changed nothing on this section


      }

      // If RTOS queue is not empty, process app message.
      while (!Queue_empty(appMsgQueue))
      {

 if (events & SBP_SNV_WRITE)
    {
         events &= ~SBP_SNV_WRITE;
         osal_snv_write(0x80, SNV_BUFFER_SIZE, osal_write_buffer);
         
         LCD_WRITE_STRING("writeMod", LCD_PAGE5);
    } 

}



Thanks
Jayachandran R


  • Hello Jayachandran,

    What are you programming settings in SmartRF Flash Programmer 2 v1.7.3+ when you do not do a mass erase. Can you attach the log from the flash programmer and confirm the version used? Also, how do you know that your data (ID=0x80) is stored at 1e000-1e003?

    Also, can you post a patch to SimpleBLEPeripheral.c from ble_cc26xx_2_01_01_44627 that reproduces the problem? The code snippet is not sufficient.

    Best wishes
  • Hi JXS,

    The settings remains same except mass erase .Please refer the screen shot.

    We are using the flash programmer 2v1.7.1

    The stack ends at 1f000. so the last page is used for SNV. Its verified with the SNV write and read.

    Also attached the snap shot of flash layout of after mass erase and flash the App and flash layout of mass erase and flash the App and one more reset.

    find the Test code also in the attachment.

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    /*******************************************************************************
    Filename: simpleBLEPeripheral.c
    Revised: $Date: 2016-01-07 16:59:59 -0800 (Thu, 07 Jan 2016) $
    Revision: $Revision: 44594 $
    Description: This file contains the Simple BLE Peripheral sample
    application for use with the CC2650 Bluetooth Low Energy
    Protocol Stack.
    Copyright 2013 - 2015 Texas Instruments Incorporated. All rights reserved.
    IMPORTANT: Your use of this Software is limited to those specific rights
    granted under the terms of a software license agreement between the user
    who downloaded the software, his/her employer (which must be your employer)
    and Texas Instruments Incorporated (the "License"). You may not use this
    Software unless you agree to abide by the terms of the License. The License
    limits your use, and you acknowledge, that the Software may not be modified,
    copied or distributed unless embedded on a Texas Instruments microcontroller
    or used solely and exclusively in conjunction with a Texas Instruments radio
    frequency transceiver, which is integrated into your product. Other than for
    the foregoing purpose, you may not use, reproduce, copy, prepare derivative
    works of, modify, distribute, perform, display or sell this Software and/or
    its documentation for any purpose.
    YOU FURTHER ACKNOWLEDGE AND AGREE THAT THE SOFTWARE AND DOCUMENTATION ARE
    PROVIDED �AS IS� WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
    INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY, TITLE,
    NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL
    TEXAS INSTRUMENTS OR ITS LICENSORS BE LIABLE OR OBLIGATED UNDER CONTRACT,
    NEGLIGENCE, STRICT LIABILITY, CONTRIBUTION, BREACH OF WARRANTY, OR OTHER
    LEGAL EQUITABLE THEORY ANY DIRECT OR INDIRECT DAMAGES OR EXPENSES
    INCLUDING BUT NOT LIMITED TO ANY INCIDENTAL, SPECIAL, INDIRECT, PUNITIVE
    OR CONSEQUENTIAL DAMAGES, LOST PROFITS OR LOST DATA, COST OF PROCUREMENT
    OF SUBSTITUTE GOODS, TECHNOLOGY, SERVICES, OR ANY CLAIMS BY THIRD PARTIES
    (INCLUDING BUT NOT LIMITED TO ANY DEFENSE THEREOF), OR OTHER SIMILAR COSTS.
    Should you have any questions regarding your right to use this Software,
    contact Texas Instruments Incorporated at www.TI.com.
    *******************************************************************************/
    /*********************************************************************
    * INCLUDES
    */
    #include <string.h>
    #include <ti/sysbios/knl/Task.h>
    #include <ti/sysbios/knl/Clock.h>
    #include <ti/sysbios/knl/Semaphore.h>
    #include <ti/sysbios/knl/Queue.h>
    #include <ti/sysbios/BIOS.h>
    #include <ti/sysbios/family/arm/cc26xx/Power.h>
    #include <driverlib/sys_ctrl.h>
    #include "hci_tl.h"
    #include "gatt.h"
    #include "gapgattserver.h"
    #include "gattservapp.h"
    #include "devinfoservice.h"
    #include "simpleGATTprofile.h"
    #if defined(SENSORTAG_HW)
    #include "bsp_spi.h"
    #endif // SENSORTAG_HW
    #if defined(FEATURE_OAD) || defined(IMAGE_INVALIDATE)
    #include "oad_target.h"
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    With regards,

    Thangaraj.p

  • Hi,

    You mention that you are using 8kB of SNV, or OSAL_SNV=2 ( two 4kB pages). Can you check the value at 0x1d000, this is the address of the first SNV page. The 00 00 10 00 is the header that indicates the page is the active page. What is the value for the first page?

    Note that you can refer to the osal_snv_init() procedure in osal_snv.c.

    Best wishes
  • Hi JXS,

    Thanks.

    Yes. we understood the from the document that if we use OSAL_SNV=2 then Last 4kB will be used for SNV and first 4KB use for compaction process if the 80% of data filled in the Last SNV page. Thats why we are checking in the address 0x1e000.

    The 00 00 10 00 is the header that indicates the page is the active page.

    Yes. This is True. The value becomes 0 00 10 00 after reset once after mass erase and falsh the App. That showed on the second image.

    But the first image shows the actual problem.FF FF FF FF after mass erase and falsh the App

    Please check and let us know.

  • Hi Thangaraj,

    I noticed from your screenshots you are using SmartRF Flash Programmer 2 v1.7.1. Can you upgrade to the latest version (v1.7.4) to see if this resolves the issue?

    If you follow the steps 1-4 listed in your original post, what value is shown on the LCD after the first reset?
  • 1
    2
    3
    4
    5
    /*******************************************************************************
    Filename: simpleBLEPeripheral.c
    Revised: $Date: 2016-01-07 16:59:59 -0800 (Thu, 07 Jan 2016) $
    Revision: $Revision: 44594 $
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Hi RachelP ,

    Thanks!

    I have update the SmartRF Flash Programmer  to version v1.7.4. Still i am facing the same issue.

    RachelP [Q] :  If you follow the steps 1-4 listed in your original post, what value is shown on the LCD after the first reset?

    The value of the SNV modified by pressing the RIGHT KEY in SMART RF board, if press one time value will incremented by one and stored to SNV.

    Default Value : 1

    After One RIGHT KEY press  value changed to 2 and stored to SNV.

    After Reset Expected value is : "2"  , But actual value read in LCD is 1  .

    I have attached the Source code of the experiment in this.

    Thanks and regards,

    Jayachandran R

  • Hi Jayachandran,

    I have tested using the file provided and I am not seeing the same issue on my board. If I follow the steps you provided, I see the correct number on the display after the first reset following the mass erase.

    I did see that in your status log, that you are skipping verification of a number of pages that correspond to the stack image. Can you verify that you are reprogramming the stack image and that the SNV area has been completely erased before running the application?

    To check this:

    1. Uncheck the "Disconnect after action finished" Setting

    2. Perform the CC26xx Mass Erase

    3. Flash the device using the settings shown below, your Status log output should show pages 14-31 verified OK.

    4. Read the memory at 0x1d000 and 0x1e000 (the SNV pages) - It should be all F's or all 0's depending on compiler.

    5. Disconnect and reconnect your device and run the application - Is the value retained after reset?

  • hi RachelP,

    Thanks!

    Please find my comments inline.

    To check this:

    1. Uncheck the "Disconnect after action finished" Setting

    2. Perform the CC26xx Mass Erase

    3. Flash the device using the settings shown below, your Status log output should show pages 14-31 verified OK.

    4. Read the memory at 0x1d000 and 0x1e000 (the SNV pages) - It should be all F's or all 0's depending on compiler.

    5. Disconnect and reconnect your device and run the application - Is the value retained after reset?

    -> In this step Disconnect and Reconnect means what ?

    ->if it is  Disconnect and connect using the flash programmer, if yes obviously connect will expect one reset before starting the Application

       then it will work as expected, because we provide two reset before starting the application (one for Disconnect and one for connect).

    -> if it is meant for a  USB power disconnect and connect, then run the application still problem persist.

  • Hi Jayachandran,

    For Step 5, I did mean a USB power disconnect. In Step 4, did you see all F's or 0's at 0x1d000 and 0x1e000?

    Another thing you can try:

    After step 4: On the main tab, uncheck Program and Verify, and select "Specific Pages" in the Erase Options. Enter "29,30" to erase just the SNV pages.

    Can you send me a screenshot of your programming settings with the status log output from Step 3 and a screenshot of what you see at 0x1d000 after programming?
  • Hi rachelP,

    Thanks!

    Please find my comments in line.

    [Q] In Step 4, did you see all F's or 0's at 0x1d000 and 0x1e000?

    Yes, i have seen alll FF at 0xd000 page and all 0s at 0x1e000 page.

    [Q] After step 4: On the main tab, uncheck Program and Verify, and select "Specific Pages" in the Erase Options. Enter "29,30" to erase just the SNV pages.

    After Erasing the Page 29(0x1d000) and  (1e000) are changed to FF.

    Followed Step 5, After the reset changed value is persist that means SNV is working fine.

    could please tell me the reason for this erase cycles after the Flash program ?

    Is this issue with SNV (or) expected behavior of the SNV? Since we are using this SNV with production code.

    if it is a issue when it will be fixed?

    Without this additional step, can we solve the problem in stack?

    Thanks and Regards,

    Jayachandran R

  • Hi Jayachandran,

    I noticed in your screenshot that your log shows "Skip verification of unassigned page 29". This corresponds to the first SNV page. When I run your code with the example SimpleBLEPeripheral stack I am not seeing the same problem and my page 29 is verified ok. There may be an issue with the way you are building the stack. Can you check your hex file to make sure page 29 exists?

    If you follow the steps above that allowed you to run the program successfully, what is at address 0x1d000 after the first reset?

    If you check the "All unprotected pages" box instead of "Pages in image" in the Erase settings, does the SNV work as expected?
  • Hi rachelP,

    Thanks!.

    Yes, page no : 29 is not exist in the stack hex file, since I am not changed any settings and source code during the stack hex build, i made only change is OSAL_SNV = 1.

    Whatever hex build i send to you previously with the Settings OSAL_SNV=1 (since my production software also using the same), if i set OSAL_SNV as default value that is 2, then SNV is working as expected so the problem is not occurring,

    so the problem persist with setting OSAL_SNV = 1 [4KB for SNV page].

    My bad, sorry! for the wrong information provided by me in the initial times of this forum thread,  so here after don't considered about the configuration OSAL_SNV=2, because i need solution for OSAL_SNV=1.

    [Q] If you follow the steps above that allowed you to run the program successfully, what is at address 0x1d000 after the first reset?

    I thing this step not need for OSAL_SNV = 1.

    [Q]If you check the "All unprotected pages" box instead of "Pages in image" in the Erase settings, does the SNV works as expected?

    Still i am facing the same issue.

    But i  followed Step 5, After the reset changed value is persist that means SNV is working fine.

    Thanks & regards,

    Jayachandran r

  • Hi Jayachandran,

    Thanks for clarifying that you are using OSAL_SNV=1. I will look into what could be causing your issues with the 4KB SNV page.
  • Hi Jayachandran,

    The issue is in the way the SNV page is being initialized. You can watch this behavior if you step into the NVOCOP_initNV function in nvocop.c. Since the header is set to all 0's, it reads it as being in the Transfer Page State and doesn't initialize the SNV properly.

    To fix this, make the highlighted changes in nvocop.c:

    /*********************************************************************
     * LOCAL VARIABLES
     */
    #if defined(__IAR_SYSTEMS_ICC__)
    #pragma data_alignment=4096
    #pragma location = ".snvSectors"
    const uint8 NV_FLASH[FLASH_PAGE_SIZE] = {0xFF};
    #elif defined __TI_COMPILER_VERSION || defined __TI_COMPILER_VERSION__
    #pragma location = (SNV_FIRST_PAGE << 12);
    const uint8 NV_FLASH[FLASH_PAGE_SIZE] = {0xFF};
    #else
    #error "Unknown Compiler! Support for SNV not provided!"
    #endif