CC2340R5: NVS initialization at compiling/linking/FW download time

Hi Stefano,

I apologize in advance as I am likely not understanding your use case despite your best efforts.  First, I set the SysConfig -> NVS module as so:

Then I added the persistent variables to my application code:

const uint32_t __attribute__((persistent, location(0x7F000), used)) setting_a = 0xdead;
const uint32_t __attribute__((persistent, location(0x7F004), used)) setting_b = 0xdeaf;
const uint32_t __attribute__((persistent, location(0x7F008), used)) setting_c = 0xbeef;

Here is the map file after building:

0007f000 0007f000 00000004 00000004 rw-
0007f000 0007f000 00000004 00000004 rw- .TI.bound:setting_a
0007f004 0007f004 00000004 00000004 rw-
0007f004 0007f004 00000004 00000004 rw- .TI.bound:setting_b
0007f008 0007f008 00000004 00000004 rw-
0007f008 0007f008 00000004 00000004 rw- .TI.bound:setting_c

And this is the CCS Debugger Memory Map after loading:

0x0007F000 setting_a
0x0007F000 0000DEAD
0x0007F004 setting_b
0x0007F004 0000DEAF
0x0007F008 setting_c
0x0007F008 0000BEEF 

Can you please clarify how these results are different from your expectations?

Regards,
Ryan

Ryan,

first of all I want to thank you for your incredibly quick and helpful reply. Even though it's very late at night here, I simply couldn't go to sleep without investigating further. I was slightly inaccurate in my explanation, when I described my Sysconfig settings, maybe a bit deceived by two factors (and that I, unlike you, have not pasted my Sysconfig screenshot):

1) the 0x800 sector size that is greyed out (hardware dependent) and the region size, which I (wrongly) gave for granted as being understood to be 0x800 when I mentioned I was using only one sector;

2) the fact that I wanted to use the minimum possible amount of flash, at its very end.

So, basically, the only difference between our two setups is that I had set the region size to 0x800 (with region base 0x7F800), while you set it to 0x1000 (with region base 0x7F000).

My understanding of region vs. sector could be flawed (I considered the region as a superset of multiple fixed-size 0x800/2048 aligned sectors) and the region base where the first (and only, in my original intentions) sector starts. Is this correct? What I still find puzzling is that even if I keep the region base at 0x7F800 and set the region size to 0x1000 (double my original setting), the outcome in the debugger/memory browser is indeed the (expected) one that you show in your reply (the same as if I initialize my defaults at a different address from the NVS region base), but wouldn't this setting overflow the flash boundary, according to the memory map (this is clearly impossible, so it's likely there is something wrong in my reasoning)? By the way, in this case the memory map I get is completely unaffected (expected with the POINTER NVS option, that doesn't affect it) as you can see:

0007f800    0007f800    00000004   00000004    rw- .TI.bound:setting_a
0007f804    0007f804    00000004   00000004    rw-
0007f804    0007f804    00000004   00000004    rw- .TI.bound:setting_b
0007f808    0007f808    00000004   00000004    rw-
0007f808    0007f808    00000004   00000004    rw- .TI.bound:setting_c
20000400    20000400    00000010   00000000    rw-
20000400    20000400    00000010   00000000    rw- .TI.bound:dmaChannel0ControlTableEntry

The Sysconfig-generated ti_drivers_config.c file however, in its NVS section does include what seem to me incorrect values (i.e. potential flash overflow due to region size), is this behavior correct or should Sysconfig check before generating? Would NVS_open() fail in this case?:

/*
 *  =============================== NVS ===============================
 */

#include <ti/drivers/NVS.h>
#include <ti/drivers/nvs/NVSLPF3.h>

NVSLPF3_Object NVSLPF3_objects[1];

static const NVSLPF3_HWAttrs NVSLPF3_hwAttrs[1] = {
    /* CONFIG_NVS_0 */
    {
        .regionBase = (void *) 0x7f800,
        .regionSize = 0x1000
    },
};

#define CONFIG_NVS_COUNT 1

const NVS_Config NVS_config[CONFIG_NVS_COUNT] = {
    /* CONFIG_NVS_0 */
    {
        .fxnTablePtr = &NVSLPF3_fxnTable,
        .object = &NVSLPF3_objects[0],
        .hwAttrs = &NVSLPF3_hwAttrs[0],
    },
};

const uint_least8_t CONFIG_NVS_0_CONST = CONFIG_NVS_0;
const uint_least8_t NVS_count = CONFIG_NVS_COUNT;

**********************************************************************

Going back to your code, even if you keep your region base at 0x7F000, if you set your region size to 0x800 (something that is probably incorrect to do), do you also get my (unexpected and wrong) result of that flawed initialization in the memory browser (I tried it and it does)? i.e.:

0x000 7F000 setting_a
0x000 7F000 0xFE 0xE0 0x0F 0x96
0x000 7F004 setting_b
0x000 7F004 0xFF 0xFF 0xFF 0x96
0x000 7F008 setting_c
0x000 7F008 0xFF 0xFF 0xFF 0x96

The empirical lesson I get from all of this is that the region size must be (at least) twice as large as the sector size (perhaps even despite the above mentioned overflow), to achieve the intended result.

In all honesty, I only examined the TI ARM Clang Compiler User Manual and Migration guide documentation and the NVS driver headers and implementation (which shouldn't be operational at this stage, though), but, clearly, I missed this bit. The NVS.h File reference, in its initial overview, however, only states:

"Each NVS object is used to manage a region of non-volatile memory. The size of the region is specified in the device specific driver's hardware attributes. A sector is the smallest unit of non-volatile storage that can be erased at one time. The size of the sector, or sector size, is hardware specific and may be meaningless for some non-volatile storage hardware. For flash memory devices, the region must be aligned with the sector size. That is, the region must start on a sector boundary. Additionally, the overall size of the region must be an integer multiple of the sector size."

So, from all of the above, it must be that this integer cannot be 1 (or some other reason/mechanism in the toolchain/Sysconfig interaction)?

Apologies if, once again, I'm messing things up and if I'm not very clear in my explanation, but I'm more used to dealing with bare-metal rather than API layers (which is the right way of doing things) and I tend to always re-invent the wheel, so I might get lost on the devil that is in the details.

Thank you once again for your terrific help.

Kind regards,

Stefano

PS my use case is carried on from some compatibility and coherence concerns regarding the MSP430 implementation of my framework, specifically also related to generic corner/edge cases, for example where flash writing cannot occur at runtime because of certain low voltage concerns (failure/corruption issues), but there are can be other reasons for not initializing the defaults at boot, even with checks.

I can use 0x800 as the Region Size as well and get similar results using my SimpleLink F3 SDK v7.20 setup:

The Sector Size is fixed at 0x800 as the flash page size of the CC2340R5 hardware, the Region Size is dependent on the NVS application requirements.  You should not use a Region Base of 0x7F800 and Region Size greater than 0x800, as this would extend beyond the flash memory capabilities of the device, however no error is produced given that Region Type Pointer does not allocate the memory inside of ti_drivers_config.  If using Generated then a Linker issue would occur.

Regards,
Ryan

Ryan,

if you can, please could you hold on for a little while before locking this thread? I'm still finding some erratic behavior on the release LP and I must partially retract what I wrote marking my issue as resolved. This was, in fact, why I had tried to resurrect the preview LP to investigate whether the release LP was defective and then I accidentally left it connected. Basically what happens is that the values are written in Flash correctly at compile/link/load time, but, as soon as the application (the non-BLE) thread is called, something happens so they are overwritten to the erroneous ones I had reported and then a subsequent test NVS_open() that I use to try and overwrite them fails miserably, unlike in other simpler examples that I have produced with the same exact flow. I am trying to investigate further and set up a simple example to reproduce the issue without posting all of my code. I suspect this is happening due to the switch to the TI Clang toolchain, which seems a lot more unforgiving for initializations, compared to the previous original TI compilers/toolchain.

Thank you,

kind regards

Stefano

Hi Stefano,

E2E threads are not locked until after 30 days of inactivity (i.e. since the latest reply).  If you are using the BLE stack, albeit not the BLE application thread itself for your target NVS application, be sure you are using a completely separate NVS instance which does not overlap with the existing BLE usage.

Regards,
Ryan

Ryan,

thanks, yes that was the problem, I was suspicious about the BLE stack/app threads being involved (however I couldn't find any explicit calls anywhere in the code), the giveaway was that the NVS operation was right before the application thread being called (I was inaccurate, of course not WHEN it was called, that's obviously where I set the breakpoint), I initially gave for granted that the BLE stack and the BLE app framework (I'm using both) would use a specific configuration segment of the Flash, but it must be that they are (at least in the examples, from which I have derived my code) using the first instance [0] of the NVS "behind the scenes", no matter what it's called. This happens when doing unit testing in parallel and it doesn't show up, I must have missed this bit somewhere in the documentation, perhaps it could be useful if the issue could be exposed more clearly in Sysconfig or elsewhere, especially when using the BLE stack and NVS together. Now I have created a separate second instance and everything seems to be working the way it should. You saved me from trying to set up a dummy BLE example to reproduce what was going on. Apologies if I have been so inaccurate in my description, but I've been banging my head around this for a while and was even investigating the NVOCMP_NO_RAM_OPTIMIZATION define in the nvocmp.c driver (which does some writing in Flash) but ultimately it had nothing to do with it. I was also looking at some potential probe and voltage issues and even reverted to the preview silicon to dig deeper, since the behavior with the pre-release SDKs might have been different (I can't honestly remember since it was at least from v6.30).

Three more NVS questions, if I may:

1) is it correct to assume that the BLE stack/app FW are always using the first NVS instance (no matter what it's called, it points to [0])?

2) what is the minimum size (if there is a fixed or safe one) of this first NVS instance?

3) looking at the basic_ble and data_stream examples, the first instance is pretty large (16KB) and it is located at the end of the Flash (so I assume it's not overflowing that size). Is it OK to relocate it elsewhere, as long as it's aligned and large enough?

One last, perhaps slightly OT (for this BLE forum) question, which is the most appropriate e2e forum to ask questions regarding the migration from the original TI ARM compilers/toolchains (and also cross-platform implementations) to the new TI ARM Clang toolchain used with the CC2340? I kind of underestimated the compiler/linker/initialization portability issues with my code, also due to certain C version issues which can't be changed, given the huge amount of code from both the BLE stack and the BLE app FW and other bits here and there. I was working with tiny devices and doing a lot of packing and optimization, which doesn't always carry over smoothly.

Thank you so much for your invaluable help,

kind regards

Stefano

Each non-OAD BLE example only allocates one NVS instance, but on-chip and off-chip have a second instance.  For each of these, the first instance is at 0x7C000 with a size of 0x4000.  On-chip OAD adds an instance at 0x32000 with a size of 0x4A000 and off-chip OAD's second instance is external.  Please consult the BLE 5-Stack Users Guide OAD section for explanations.  I have not experimented with moving the NVS area on the CC2340R5 device but it would certainly also require a change to the NVS_BASE definition from cc23x0_app_freertos.cmd

You can address your TI ARM Clang toolchain on the BLE forum and the correct expert will address it accordingly.

Regards,
Ryan

Ryan Brown1,

apologies for this late thank you for your latest reply, enlightening as usual.

Kind regards

Stefano

PS with the help of awesome TI E2Ers like you, I have successfully completed the entire migration of my framework and application code (I still need to optimize BLE power consumption but it shouldn't be a problem) to this new terrific CC2340 HW and SW platform. It's a bit unusual to say this on an engineering forum, but I had to give it a toast to Texas Instruments for this accomplishment. I'm seriously impressed by how easy it is to design something useful, functional and affordable, once you become familiar with the platform. Kudos++ to both the HW and SW Teams behind this amazing 4th-gen device, I was a staunch believer since the June 2022 announcement and I feel totally rewarded.