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.

CC2652R: NVS Write Time

Part Number: CC2652R
Other Parts Discussed in Thread: SYSCONFIG, SYSBIOS

I'm working with a customer who has done some performance analysis on the NVS. For reference, this is a DMM TI 15.4 Stack + BLE project, and the 15.4 NVS as well as BLE SNV is in use (both abstractions to the same low level FLASH NVS).

The first experiment they ran is as follows:

While using NVS library, we experienced varied write times.

We did following steps:

    1. Defined a structure of 276 bytes
    2. capture current time (t1)
    3. used NV api function (pNV->writeItem) to perform write operation.
    4. capture current time (t2)
    5. calculate time taken for write operation (t2-t1)
    6. Repeat steps 1-5 for longer duration approx. 1hr

(delay given between 2 consecutive writes = 200 msec)

If you look at the yellow highlighted sections, and do the math on the sector size of 8K and structure size of 276 bytes, it makes sense that these likely line up with compaction. However, what is very concerning is the lines highlighted in red that take minutes to complete. The customer decided to perform another experiment with smaller data sizes to investigate further, and it yields some interesting results:

It seems that the longer write times (several minutes), seems to be somehow tied to write structure size. Is there some insight into the write algorithm or configuration that can be undertaken in order to improve performance for the customer's use case?

Thanks,

Stuart

  • Stuart,

    This is very interesting. I'll check with the team and one of us will follow up next week.

    -Luis

  • Hello Stuart,

    The Compaction theory makes sense. I am not sure however about what happens in the red slots. It seems to occur at roughly every 50 iterations. 

    1) Which SDK is this?

    2) Can this be reproduced on nvsinternal driver example code?

    C:\ti\simplelink_cc13x2_26x2_sdk_4_10_00_78\examples\rtos\CC26X2R1_LAUNCHXL\drivers\nvsinternal

    3) What is the NVS configuration (including sysconfig settings)? Does BLE SNV and 15.4 NVS use different memory pages?

    4) How is the time capture implemented?

    1. Could there be incorrect timer reading, timer calculations or interrupted timer reading?
    2. Do they use NVS_lock() and NVS_unlock() for each write operation (before and after timestamp)?

  • Eirik V,

    1. The customer is locked to the 3.10 SDK and is receiving direct TI support for some 15.4 customization applied to the 15.4 and DMM projects based off of this SDK.
    2. I don't know if it is reproducible on the nvsinternal driver example. I can spend some time trying.
    3. This is not a sysconfig project. I don't know what you mean by BLE SNV and 15.4 using different memory pages, could you explain?
    4. I need to check with the customer about how the time is captured.

    1. I suppose it is possible there is something wrong with the timer reading. I need to look into this in more detail.
    2. I will ask the customer if NVS_lock/unlock() is used.

    Thanks,

    Stuart

  • Here is the NVS configuration in the board file example that TI provided the customer. I will check with the customer to see if they have made any modifications.

    Looking at the example, it seems that both Internal and External NVS FLASH are defined. The customer only intends to be using internal FLASH. CC26X2R1_LAUNCHXL_NVSCOUNT == 2.

     *  =============================== NVS ===============================
     */
    #include <ti/drivers/NVS.h>
    #include <ti/drivers/nvs/NVSSPI25X.h>
    #include <ti/drivers/nvs/NVSCC26XX.h>
    
    #define NVS_REGIONS_BASE 0x48000
    #define SECTORSIZE       0x2000
    #define REGIONSIZE       (SECTORSIZE * 4)
    
    #ifndef Board_EXCLUDE_NVS_INTERNAL_FLASH
    
    /*
     * Reserve flash sectors for NVS driver use by placing an uninitialized byte
     * array at the desired flash address.
     */
    #if defined(__TI_COMPILER_VERSION__)
    
    /*
     * Place uninitialized array at NVS_REGIONS_BASE
     */
    #pragma LOCATION(flashBuf, NVS_REGIONS_BASE);
    #pragma NOINIT(flashBuf);
    static char flashBuf[REGIONSIZE];
    
    #elif defined(__IAR_SYSTEMS_ICC__)
    
    /*
     * Place uninitialized array at NVS_REGIONS_BASE
     */
    static __no_init char flashBuf[REGIONSIZE] @ NVS_REGIONS_BASE;
    
    #elif defined(__GNUC__)
    
    /*
     * Place the flash buffers in the .nvs section created in the gcc linker file.
     * The .nvs section enforces alignment on a sector boundary but may
     * be placed anywhere in flash memory.  If desired the .nvs section can be set
     * to a fixed address by changing the following in the gcc linker file:
     *
     * .nvs (FIXED_FLASH_ADDR) (NOLOAD) : AT (FIXED_FLASH_ADDR) {
     *      *(.nvs)
     * } > REGION_TEXT
     */
    __attribute__ ((section (".nvs")))
    static char flashBuf[REGIONSIZE];
    
    #endif
    
    /* Allocate objects for NVS Internal Regions */
    NVSCC26XX_Object nvsCC26xxObjects[1];
    
    /* Hardware attributes for NVS Internal Regions */
    const NVSCC26XX_HWAttrs nvsCC26xxHWAttrs[1] = {
        {
            .regionBase = (void *)flashBuf,
            .regionSize = REGIONSIZE,
        },
    };
    
    #endif /* Board_EXCLUDE_NVS_INTERNAL_FLASH */
    
    #ifndef Board_EXCLUDE_NVS_EXTERNAL_FLASH
    
    #define SPISECTORSIZE    0x1000
    #define SPIREGIONSIZE    (SPISECTORSIZE * 32)
    #define VERIFYBUFSIZE    64
    
    static uint8_t verifyBuf[VERIFYBUFSIZE];
    
    /* Allocate objects for NVS External Regions */
    NVSSPI25X_Object nvsSPI25XObjects[1];
    
    /* Hardware attributes for NVS External Regions */
    const NVSSPI25X_HWAttrs nvsSPI25XHWAttrs[1] = {
        {
            .regionBaseOffset = 0,
            .regionSize = SPIREGIONSIZE,
            .sectorSize = SPISECTORSIZE,
            .verifyBuf = verifyBuf,
            .verifyBufSize = VERIFYBUFSIZE,
            .spiHandle = NULL,
            .spiIndex = 0,
            .spiBitRate = 4000000,
            .spiCsnGpioIndex = CC26X2R1_LAUNCHXL_GPIO_SPI_FLASH_CS,
            .statusPollDelayUs = 100,
        },
    };
    
    #endif /* Board_EXCLUDE_NVS_EXTERNAL_FLASH */
    
    /* NVS Region index 0 and 1 refer to NVS and NVS SPI respectively */
    const NVS_Config NVS_config[CC26X2R1_LAUNCHXL_NVSCOUNT] = {
    #ifndef Board_EXCLUDE_NVS_INTERNAL_FLASH
        {
            .fxnTablePtr = &NVSCC26XX_fxnTable,
            .object = &nvsCC26xxObjects[0],
            .hwAttrs = &nvsCC26xxHWAttrs[0],
        },
    #endif
    #ifndef Board_EXCLUDE_NVS_EXTERNAL_FLASH
        {
            .fxnTablePtr = &NVSSPI25X_fxnTable,
            .object = &nvsSPI25XObjects[0],
            .hwAttrs = &nvsSPI25XHWAttrs[0],
        },
    #endif
    };
    
    const uint_least8_t NVS_count = CC26X2R1_LAUNCHXL_NVSCOUNT;

  • 1. The current SDK being used is simplelink_cc13x2_26x2_sdk_3_10_00_53_s

    2. We have not tried on the nvsinternal driver example

    3. Don't know, please explain

    4. 

    1. Timer values are correct, checked with Timestamp_get32() and GPTimerCC26XX_getFreeRunValue

    Both give same values

    2. We are using pNV->writeItem and have not explicitly used NVS_lock/unlock

  • I checked and can see lock/ unlock being used here

  • Hello Virendra/Stuart,

    I read through the NVSCC26XX_write function which so far revealed 2 mechanisms that could affect write duration:

    1) Every write is split up to blocks of 8 bytes to minimize the duration of the critical section. This means the write operation could be interrupted between every block write.

    /* max number of bytes to write at a time to minimize interrupt latency */
    #define MAX_WRITE_INCREMENT 8
    key = HwiP_disable();
    status = FlashProgram((uint8_t*)srcBuf, (uint32_t)dstBuf,
                        writeIncrement);
    HwiP_restore(key);

    2) In theory the NVS_lock/unlock could be used elsewhere in the code to block execution of NVSCC26XX_write. Perhaps you can add another timer function to measure the time it actually takes for the NVSCC26XX_write in case it is actually only pending on writeSem.

        /* Get exclusive access to the Flash region */
        SemaphoreP_pend(writeSem, SemaphoreP_WAIT_FOREVER);
    
       // read time t1
    
       ...
    
       // rad time t2
    
       SemaphoreP_post(writeSem);

  • We tried reading timer values as suggested but were unable to do so as the mentioned code is part of TI library and we are unable to compile it when we put timer related changes to this file.

  • Create a new folder in your IDE project and add (copy) all the driver source files from C:\ti\simplelink_cc13x2_26x2_sdk_3_10_00_53\source\ti\drivers\nvs :

    • NVSCC26XX.c
    • NVSCC26XX.h
    • NVS.c
    • NVS.h

    Then edit the driver function and recompile (rebuild).

  • Console Logs:


    **** Build of configuration Release for project dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs ****

    "C:\\ti\\ccs901\\ccs\\utils\\bin\\gmake" -k -j 4 all -O

    making ../src/sysbios/rom_sysbios.aem4f ...
    gmake[1]: Nothing to be done for 'all'.
    Building file: "../ti/drivers/NVS.c"
    Invoking: ARM Compiler
    Flags: --cmd_file="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/TOOLS/defines/dmm_154sensor_remote_display_app_2_4g_FlashROM.opts" --cmd_file="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/TOOLS/build_components.opt" --cmd_file="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/TOOLS/factory_config.opt" --cmd_file="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/TOOLS/build_config.opts" -mv7M4 --code_state=16 --float_support=FPv4SPD16 -me -O4 --opt_for_speed=0 --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs" --include_path="C:/ti/ccs901/ccs/tools/compiler/ti-cgt-arm_18.12.1.LTS/include" --include_path="C:/ti/xdctools_3_51_02_21_core/packages" --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/154MAC/HighLevel" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/kernel/tirtos/packages" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/devices/cc13x2_cc26x2" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/devices/cc13x2_cc26x2/inc" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/devices/cc13x2_cc26x2/driverlib" --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/Application/154Sensor" --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/Application/154Sensor/2_4g" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/apps/dmm_154sensor_remote_display/source/sensor" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/apps/dmm_154sensor_remote_display/source/sensor/mac_util" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/apps/dmm_154sensor_remote_display/source/sensor/jdllc" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/apps/dmm_154sensor_remote_display/source/sensor/2_4g" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/common" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/common/osal_port" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/common/boards" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/common/boards/2_4g" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/common/inc" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/fh" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/high_level" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/inc" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/rom" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/inc/cc13xx" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/low_level/cc13xx" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/low_level/cc13xx/2_4g" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/tracer" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/services/src" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ti154stack/services/src/saddr" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/remote_display_profile_154" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/provisioning_profile" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/apps/dmm_154sensor_remote_display/source/ble_remote_display/app/" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/apps/dmm_154sensor_remote_display/source/ble_remote_display/" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/apps/dmm_154sensor_remote_display/source/" --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/Startup" --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/PROFILES" --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/Include" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/apps/" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/apps/dmm_wsnnode_remote_display" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/dmm/apps/dmm_wsnnode_remote_display/source/" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/controller/cc26xx/inc" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/inc" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/rom" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/common/cc26xx" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/icall/inc" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/target" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/profiles" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/profiles/dev_info" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/hal/src/target/_common" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/hal/src/target/_common/cc26xx" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/hal/src/inc" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/heapmgr" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/icall/src/inc" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/osal/src/inc" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/services/src/saddr" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/services/src/sdata" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/services/src/nv" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/services/src/nv/cc26xx" --include_path="C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/source/ti/ble5stack/services/src/appasrt" --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/Application/154Sensor/ResideoSensor" --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/Application/154Sensor/ResideoSensor/oad/native_oad" --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/Application/154Sensor/ResideoSensor/ResideoSensorSampleApp" --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/Application/154Sensor/ResideoSensor/oad/crc" --include_path="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/Application/154Sensor/ResideoSensor/SensorEnrollment" --preinclude="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/Application/154Sensor/2_4g/features.h" --define=RESIDEO_SENSOR_CHANGES=1 --define=SCHEDULE_DATAREQ=1 --define=xFEATURE_ENHANCED_ACK --define=xDBG_PINS --define=FREQ_2_4G --define=CC26XX --define=CC26X2
    Flags (cont-d): --define=CC26X2R1_LAUNCHXL --define=DeviceFamily_CC26X2 --define=REMOVE_PWRMAN --define=xDMM_SCHEDULE_FIX --define=CCFG_FORCE_VDDR_HH=0 --define=SET_CCFG_BL_CONFIG_BL_LEVEL=0x00 --define=SET_CCFG_BL_CONFIG_BL_ENABLE=0xC5 --define=SET_CCFG_BL_CONFIG_BL_PIN_NUMBER=0x0D --define=SET_CCFG_BL_CONFIG_BOOTLOADER_ENABLE=0xC5 --define=SUPPORT_PHY_CUSTOM --define=SUPPORT_PHY_2_4_100KBPS2GFSK --define=RESIDEO_15_4_SENSOR=01 --define=NV_RESTORE --define=NVSSPI=1 --define=FEATURE_NATIVE_OAD=1 -g --c99 --gcc --diag_warning=225 --diag_warning=255 --diag_wrap=off --display_error_number --gen_func_subsections=on --abi=eabi --preproc_with_compile --preproc_dependency="ti/drivers/NVS.d_raw" --obj_directory="ti/drivers" --cmd_file="configPkg/compiler.opt"
    "C:/ti/ccs901/ccs/tools/compiler/ti-cgt-arm_18.12.1.LTS/bin/armcl" -@"ti/drivers/NVS_ccsCompiler.opt"
    Finished building: "../ti/drivers/NVS.c"

    making ../src/sysbios/rom_sysbios.aem4f ...
    gmake[2]: Nothing to be done for 'all'.
    Building target: "dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs.out"
    Invoking: ARM Linker
    Flags: --cmd_file="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/TOOLS/defines/dmm_154sensor_remote_display_app_2_4g_FlashROM.opts" --cmd_file="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/TOOLS/build_components.opt" --cmd_file="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/TOOLS/factory_config.opt" --cmd_file="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/TOOLS/build_config.opts" -mv7M4 --code_state=16 --float_support=FPv4SPD16 -me -O4 --opt_for_speed=0 --preinclude="C:/ti/Aali_SRS/dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs/Application/154Sensor/2_4g/features.h" --define=RESIDEO_SENSOR_CHANGES=1 --define=SCHEDULE_DATAREQ=1 --define=xFEATURE_ENHANCED_ACK --define=xDBG_PINS --define=FREQ_2_4G --define=CC26XX --define=CC26X2 --define=CC26X2R1_LAUNCHXL --define=DeviceFamily_CC26X2 --define=REMOVE_PWRMAN --define=xDMM_SCHEDULE_FIX --define=CCFG_FORCE_VDDR_HH=0 --define=SET_CCFG_BL_CONFIG_BL_LEVEL=0x00 --define=SET_CCFG_BL_CONFIG_BL_ENABLE=0xC5 --define=SET_CCFG_BL_CONFIG_BL_PIN_NUMBER=0x0D --define=SET_CCFG_BL_CONFIG_BOOTLOADER_ENABLE=0xC5 --define=SUPPORT_PHY_CUSTOM --define=SUPPORT_PHY_2_4_100KBPS2GFSK --define=RESIDEO_15_4_SENSOR=01 --define=NV_RESTORE --define=NVSSPI=1 --define=FEATURE_NATIVE_OAD=1 -g --c99 --gcc --diag_warning=225 --diag_warning=255 --diag_wrap=off --display_error_number --gen_func_subsections=on --abi=eabi -z -m"dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs.map" -i"C:/ti/ccs901/ccs/tools/compiler/ti-cgt-arm_18.12.1.LTS/lib" --reread_libs --define=FLASH_ROM_BUILD=2 --diag_suppress=16002-D --diag_suppress=10247-D --diag_suppress=10325-D --diag_suppress=10229-D --diag_suppress=16032-D --diag_wrap=off --display_error_number --warn_sections --xml_link_info="dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs_linkInfo.xml" --rom_model
    "C:/ti/ccs901/ccs/tools/compiler/ti-cgt-arm_18.12.1.LTS/bin/armcl" -@"ccsLinker.opt" -o "dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs.out"
    <Linking>
    error: symbol "NVS_config" redeclared with incompatible type:
    "NVS_Config[][struct NVS_Config_
    fxnTablePtr off: 0 (const NVS_FxnTable *)
    object off: 32 (void *)
    hwAttrs off: 64 (const void *)]"
    in "../ti/drivers/NVS.c" at line 44 and:
    "const NVS_Config[2][struct NVS_Config_
    fxnTablePtr off: 0 (const NVS_FxnTable *)
    object off: 32 (void *)
    hwAttrs off: 64 (const void *)]"
    in "../Startup/CC26X2R1_LAUNCHXL.c" at line 808)

    >> Compilation failure

    >> Compilation failure

    >> Compilation failure
    makefile:340: recipe for target 'dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs.out' failed
    fatal error #10192: Failed linktime optimization
    gmake[1]: *** [dmm_154sensor_src_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos_ccs.out] Error 1
    makefile:333: recipe for target 'all' failed
    gmake: *** [all] Error 2

    **** Build Finished ****

  • Hi Erik

    We are getting compilation errors as shown above when we try to compile by your suggested methodology.
    Could you or Stuart do the required and see if you are getting the same results as we are getting?

    I also do not see your response to Stuarts comment,

    "This is not a sysconfig project. I don't know what you mean by BLE SNV and 15.4 using different memory pages, could you explain?"

  • Virendra,

    I have identified the source of the build failure. Please add a const qualifier to the NVS_config[] prototype near the top of NVS.c and NVSCC26XX.c:

    Thanks,

    Stuart

  • Hi Stuart,

    I have done the following 2 experiments as suggested:

    1. Fixed the compilation issue with your resolution, added print at the semaphore under NVSCC26XX.c file. This is with my working code directory.

    2. Took TI base code(release code for sensor on 25th March) and did the same activity(writing into PDM) as we are doing in our application.

    RESULT:

    Experiment 1 - The logs get stuck at similar writes as mentioned in our earlier sessions at somewhere 28th, 52nd, 83rd write and so on. It takes minutes to recover once the logs are stuck. And after that a few more writes and then it is stuck again. And this phenomena keeps repeating. I was unable to furnish the logs as they are getting stuck.

    Experiment 2 - The issue is easily reproduced even with TI base code(sensor release code as of 25th March, 2020). I am attaching the screen capture of the code snippet.

    Adding stub code for easier reference:

    //stub code

    #include <xdc/runtime/Timestamp.h>

    #define USER_DATA_SIZE 512
    #define NVS_WRITE_ITERATION 1000
    /* NV Item ID - User Data information */
    #define SSF_NV_USER_DATA 0x0009

    uint8_t NVS_wrArray[USER_DATA_SIZE];

    /* code snippet to save user data to NVS region*/
    void NVS_DataWrite(void)
    {
    NVINTF_itemID_t id;
    uint8_t nvData[USER_DATA_SIZE];

    /* Setup NV ID */
    id.systemID = NVINTF_SYSID_APP;
    id.itemID = SSF_NV_USER_DATA;
    id.subID = 0;

    // make a local copy of the global data array
    memcpy(&nvData[0], &NVS_wrArray[0], USER_DATA_SIZE);

    /* Read Network Information from NV */
    if ((Main_user1Cfg.nvFps.writeItem != NULL) && (nvData != NULL))
    {
    if (Main_user1Cfg.nvFps.writeItem(id, USER_DATA_SIZE, nvData) != NVINTF_SUCCESS)
    {
    vDebugRTF("\nNVS_ERR\n");
    }
    }
    }

    /**************************Code Snippet**********************************/

    // fill user data
    memset(&NVS_wrArray[0], 0xAF, sizeof(NVS_wrArray));
    // write into NV region
    for (i = 0; i<NVS_WRITE_ITERATION; i++)
    {
    time1 = 0;
    time2 = 0;

    vDebugRTF("\n[i]: ");
    vDebugHexRTF(i, 2);

    time1 = Timestamp_get32();
    NVS_DataWrite();
    time2 = Timestamp_get32();

    vDebugRTF("\nTm_msec:");
    vDebugHexRTF(((time2-time1)/62.5), 8);

    delay = (5000*40) / Clock_tickPeriod;
    Task_sleep(delay);
    }
    /**************************Code Snippet**********************************/

    NOTE: Please enable NV_RESTORE from TOOLS/defines/dmm_154sensor_remote_display_app_2_4g_FlahROM.opts

    NOTE: Please use System_printf instead of vDebugRTF and vDebugHexRTF for printing the logs.

  • In addition to above I am still waiting your response to Stuarts comment,

    "This is not a sysconfig project. I don't know what you mean by BLE SNV and 15.4 using different memory pages, could you explain?"

  • I have also test NVS-Read times. In my program, 3-page(24K Byte) is set.

    In zigbee application, NV-item "ZCD_NV_NWK_ACTIVE_KEY_INFO" is read frequently when zigbee transmiting. The latency of reading this NV-item can increase to 5 or 6 millisecond. But after restart system, the  latency can reduce to 1 ~ 2 millisecond.

  • Aries,

    If you read the nvoctp.c doxygen it states that "Obsolete items marked accordingly but a search for the newest instance of an item is sped up by starting the search at the last entry in the page (higher memory address)". I would expect that older entries takes longer to find as more items are added to nv storage and the list that needs to be traversed grows.

    Virendra Rathore,

    I was not aware that this use the nvoctp (2 page nv implementation, part of stack). The 2 page region is defined by default in the board file (CC26X2R1_LAUNCHXL.c). Seems like this is shared.

  • Hi Erik

    I did not understand your comment, whether you seek any information from us or you are still looking into the issue we raised. Could you please clarify

  • Hello Aftab Ali,

    1)

    I see now that this use the nvoctp (NV driver for CC26x2 devices - On-Chip Two-Page Flash Memory). These files are added to the project by default and you can debug within nvoctp.c. But The following limitations apply to those using NV alongside the BLE5-Stack.

    • NV inmplementations (i.e. NVOCTP) must not be used directly, instead the application should access NV through OSAL SNV. See Using SNV Example Code

    file:///C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/docs/ble5stack/ble_user_guide/html/ble-stack-common/flash_memory-cc13x2_26x2.html?highlight=nvoctp#limitations-and-intended-use 

    2)

    In simplelink_cc13x2_26x2_sdk_3_10_00_53 there seems to be 2 different implementations for ble5stackstack and ti154stack:

    C:\ti\simplelink_cc13x2_26x2_sdk_3_10_00_53\source\ti\ti154stack\source\common\nv

    C:\ti\simplelink_cc13x2_26x2_sdk_3_10_00_53\source\ti\ble5stack\services\src\nv\cc26xx

    This is consolidated in later releases also with the addition of nvocmp (On-Chip Multi-Page Flash Memory).:

    C:\ti\simplelink_cc13x2_26x2_sdk_4_10_00_78\source\ti\common\nv

    There seems to be many fixes that could be relevant. Even though the tips in 1) still apply (use OSAL SNV) you can try to use the latest  version of the driver.

  • Hi Erik

    For the point 1 above, does this also apply to 15.4 implementations for CSF_NV_DEVICELIST_ID, CSF_NV_FRAMECOUNTER_ID and CSF_NV_NETWORK_INFO_ID

  • Hello ,

    How do you define and configure Main_user1Cfg in your test code?

  • Hi Erik,

    please refer the snapshot:

    Erik, please assure that using NV through OSAL SNV and using the latest release will solve the issue.

  • The root cause of this issue has been identified as a known bug in an older version of nvoctp.c. An updated version exists in the 3.10 SDK under:

    source/ti/ti154stack/source/common/nv/nvoctp.c

    The older project local version of this file was replaced resolving the issue.

    Thanks,

    Stuart