• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 55 subscribers
  • Views 546 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.

CC2652R7: The TI/Matter lock-app insists on starting the .nvs linker section at address 0xaa000.

Steve Kranz
Intellectual 620 points

Part Number: CC2652R7
Other Parts Discussed in Thread: SYSCONFIG

Question:
How do I instruct the lock-app build process to start the .nvs linker section at address 0xa8000 instead? The default value of 0xaa000 works fine for the 0x4000 bytes of internal NV defined for the lock-app (chip.syscfg) but in my case I’m defining an additional 0x2000 region that starts at address 0xa8000. This results in a total .nvs linker section of size 0x6000 instead of the default 0x4000 and yet the link step insists on starting the .nvs section at the default 0xaa000 instead of the 0xa8000. The result is that I get the following build failure.

FAILED: chip-LP_CC2652R7-lock-example.out chip-LP_CC2652R7-lock-example.out.map …. address 0xb0000 of ./chip-LP_CC2652R7-lock-example.out section `.nvs' is not within region `FLASH'

Details:
The following ‘grep’ command shows that something in the build system attempted to start the .nvs section starting at address 0xaa000. The 0x6000 bytes won’t fit if started there.

$ cd ~/TI/matter/examples/lock-app/cc13x2x7_26x2x7
$ grep "\.nvs" out/debug/chip-LP_CC2652R7-lock-example.out.map           
 .rodata.nvsCC26XXHWAttrs
 .rodata.nvsSPI25XHWAttrs
.nvs            0x00000000000aa000     0x6000
 *(.nvs)
 .nvs           0x00000000000aa000     0x6000 obj/BUILD_DIR/gen/sysconfig/sysconfig.ti_drivers_config.c.o
 .bss.nvsCC26XXObjects
 .bss.nvsSPI25XObjects

The .nvs section needs to instead start at address 0xa8000 which is exactly the address that I indicated within chipsys.cfg for the additional nv region I defined.

Here are how the two regions are defined in my chip.syscfg

$ cd ~/TI/matter/examples/lock-app/cc13x2x7_26x2x7
$ grep "NVS1.internal" chip.syscfg
NVS1.internalFlash.$name      = "ti_drivers_nvs_NVSCC26XX0";
NVS1.internalFlash.regionBase = 0xA8000;
NVS1.internalFlash.regionSize = 0x2000;

$ grep "NVS2.internal" chip.syscfg
NVS2.internalFlash.$name      = "ti_drivers_nvs_NVSCC26XX1";
NVS2.internalFlash.regionBase = 0xAA000;
NVS2.internalFlash.regionSize = 0x4000;

Summary:
Since I have 0x6000 bytes of internal flash defined in chip.syscfg, and the starting address for the collection is 0xa8000, I will expect the lock-app build process to define the .nvs linker section to start at 0xa8000 (and not continue to use the default value of 0xaa000). Any ideas?

  • 0
    TI__Guru**** 223727 points

    Hi Steve,

    You will need to modify the cc13x2x7_cc26x2x7_freertos_ota.lds command linker file as well to account for this change in NV memory allocation.  I will ask the Matter Software R&D Team whether it is possible to allocate an additional flash page for NV.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 620 points

    Thank you Ryan. I made the change you suggested to my *.lds and things seem to be building/running for me now. I have 0x6000 bytes of internal NV defined, starting at location 0xA8000, instead of the default 0x4000 bytes starting at 0xAA000.

    Here are more details regarding my settings:

    $ grep ".nvs" ~/matter/src/platform/cc13x2_26x2/cc13x2x7_cc26x2x7_freertos_ota.lds
        .nvs (0xA8000) (NOLOAD) : AT (0xA8000) ALIGN(0x2000) {
            *(.nvs)

    $ grep "NVS" ~/matter/examples/lock-app/cc13x2x7_26x2x7/chip.syscfg
    const NVS         = scripting.addModule("/ti/drivers/NVS");
    const NVS1        = NVS.addInstance();
    const NVS2        = NVS.addInstance();
    const NVS3        = NVS.addInstance();
    NVS1.$name                    = "CONFIG_NVSINTERNAL";
    NVS1.internalFlash.$name      = "ti_drivers_nvs_NVSCC26XX1";
    NVS1.internalFlash.regionBase = 0xA8000;
    NVS1.internalFlash.regionSize = 0x4000;
    NVS2.$name                    = "SensorNV";
    NVS2.internalFlash.$name      = "ti_drivers_nvs_NVSCC26XX2";
    NVS2.internalFlash.regionBase = 0xAC000;
    NVS2.internalFlash.regionSize = 0x2000;
    NVS3.$name               = "CONFIG_NVSEXTERNAL";
    NVS3.nvsType             = "External";
    NVS3.$hardware           = system.deviceData.board.components.MX25R8035F;
    NVS3.externalFlash.$name = "ti_drivers_nvs_NVSSPI25X0";
    const NVSSPI25XDevice                         = scripting.addModule("/ti/drivers/nvs/NVSSPI25XDevice", {}, false);
    const NVSSPI25XDevice1                        = NVSSPI25XDevice.addInstance({}, false);
    NVSSPI25XDevice1.$name                        = "CONFIG_NVS_SPI_0";
    NVS3.externalFlash.spiFlashDevice             = NVSSPI25XDevice1;
    NVSSPI25XDevice1.slaveSelectPinInstance.$name = "CONFIG_GPIO_0";
    NVSSPI25XDevice1.sharedSpiInstance = SPI1;
    NVSSPI25XDevice1.slaveSelect.$suggestSolution = "boosterpack.38";

    $ grep ".nvs" ~/matter/examples/lock-app/cc13x2x7_26x2x7/out/debug/chip-LP_CC2652R7-lock-example.out.map
     .rodata.nvsCC26XXHWAttrs
     .rodata.nvsSPI25XHWAttrs
    .nvs            0x00000000000a8000     0x6000

    Thanks again,

    Steve