Problems writing/reading struct to NVS

RE: Problems writing/reading struct to NVS

Simon — Fri, 22 Jul 2022 10:08:16 GMT

Earlier you said that CONFIG_PARTITION_MANAGER_ENABLED was set, which means that all the flash partitions in DTS are ignored, including the storage_partition you've attached in the previous reply.

Have you disabled the Partition Manager since then? Could you upload your build folder, so I can check if the partition manager is enabled or not?

Best regards,

Simon

RE: Problems writing/reading struct to NVS

Mike Austin (LPI) — Thu, 14 Jul 2022 04:54:40 GMT

OK, think I've answered a few of my questions:

1. "storage" is defined in the .dts as

storage_partition: partition@7a000 {
			label = "storage";
			reg = <0x0007a000 0x00006000>;
		};

The 0x80000 limit obviously corresponds to the offset of 0x7a000 and size of 0x6000. I'm assuming I can't modify that to increase the storage area, as I'll run into issues with available flash?

2. By moving the offset of user_storage to 0x7a000, I can get the extra space I would need, without running into issues with having to reduce the amount of settings_storage (which I think might be the cause of my BLE advertising issues, but I can't be sure).

The question of why I run into storage issues when I appear to have plenty of space left is still baffling me though. I'm assuming that the API's take care of things so that if I have 2000 bytes of data, I only need to consume 2000 bytes (or thereabouts) of flash. I know when I was using the Cypress chips, their flash was arranged in blocks, and if I wanted to write one byte to flash, I actually needed to use up an entire row (up to 256 bytes depending upon the size of flash in the chip), unless I was able to shoe-horn all my data into a 256 byte array and then write it all to the one row. Just thinking if the reason I get the -28 error when I've got more than 195 strike records has something to do with how the API's are arranging that data in flash

Cheers,

Mike

RE: Problems writing/reading struct to NVS

Mike Austin (LPI) — Wed, 13 Jul 2022 21:24:53 GMT

OK, thanks for all that info. Gotta say, you're up there with Carl on your ability to stick with a problem!! :-)

I put in a call to that calculate free space API to see what was going on. I put this in at the initialisation (prior to actually storing anything in flash) and then again each time I did a write to flash.

With MAX_STRIKE_RECORDS set to 195, I'm expecting to see flash useage of 2036 bytes (this includes the 8 byte allowance for ate_size, for 1 byte for ID and 8 bytes for meta data for each thing I'm writing to flash and the actual data I'm trying to store)

After initialisation, its telling me I have total user storage of 8192 (2 sectors at 4096 per sector). Obviously I really only have one of these available to me, so 4096. The nvs_calc_free_space(&fs) API is saying I have 4088, so there is a little bit of overhead I've not accounted for, but its only 6 bytes. On track so far.

When I do a write of all my various info to flash, as mentioned above I'm expecting to see 2036 bytes consumed, so my free space should drop down to 4088 - 8 - 2036 = 2044. The figure I get is 2044. So, things seem OK. And my code is working, storing things in flash.

Now, if I bump the value of MAX_STRIKE_RECORDS up to 200, I am expecting that the memory I will need will increase to 2089, and my free memory will drop down to 1991 (4088 - 8 - 2089 = 1991). I'm actually seeing a result of 1996 from that API. So close, but not exact.

But the problem is now, that my return value from

val = nvs_write(&fs, LOG_DATA_ID, &lsr_strike_log, sizeof(lsr_strike_log));

is now giving me the value -28, which corresponds to no space left on device. So, even though I have ~ 1900 bytes of space available, its bombing out thinking there isn't enough space.

I then tried increasing my sector count to 3 (currently 2). This means I need 3 x 4096 = 12,288 bytes of user storage (0x3000). So, I change my fixed partitions as follows:

user_storage:
  address: 0x7c000
  size: 0x3000
  placement:
    before: 
    - settings_storage
  region: flash_primary
settings_storage:
  address: 0x7f000
  size: 0x2000
  placement:
    before:
    - end
  region: flash_primary

That causes by build to crash with the following error:

-- Found partition manager static configuration: C:/Nordic/Development/LSR-MAX/LSR-MAX_V0_09/pm_static.yml
Partition 'settings_storage' is not included in the dynamic resolving since it is statically defined.
Partition manager failed: Incorrect amount of gaps found in static configuration. There must be exactly one gap in the static configuration to support placing the dynamic partitions (such as 'app'). Gaps found (2):0x0-0x7c000 0x81000-0x80000 The most common solution to this problem is to fill the smallest of these gaps with statically defined partition(s) until there is only one gap left. Alternatively re-order the already defined static partitions so that only one gap remains.
Failed to partition region flash_primary, size of region: 524288
Partition Configuration:
mcuboot:
  placement:
    before:
    - mcuboot_primary
  size: 49152
mcuboot_pad:
  placement:
    align:
      start: 4096
    before:
    - mcuboot_primary_app
  size: 512
settings_storage:
  placement:
    before:
    - end
  size: 8192
user_storage:
  placement:
    before:
    - settings_storage
  size: 12288

Which seems to suggest I'm not allowed to go past memory location 0x80000. Is that correct?

Anyway, if I peg back my settings_storage to compensate, so my fixed partitions now look like this:

user_storage:
  address: 0x7c000
  size: 0x3000
  placement:
    before: 
    - settings_storage
  region: flash_primary
settings_storage:
  address: 0x7f000
  size: 0x1000
  placement:
    before:
    - end
  region: flash_primary

Everything builds OK. And I can now see I have 8176 bytes of flash just after its all initialised, and then after my first write to flash (I've got MAX_STRIKE_RECORDS set to 200 here), I see I have 6084 bytes free. Seems pretty close to 8176 - 2089 = 6087.

BUT, and this is the bit I don't understand, now my Bluetooth advertising won't work. The call to

err = bt_le_adv_update_data(ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd)); returns an error of -11.

Maybe its got something to do with me reducing the settings_storage to much, I'm not sure.

So, I'm a bit stuck. I can't work out why my flash write bombs out when I've still got plenty of space, and I can't work out how to increase the available space to fix this, without impacting on something else!

Cheers,

Mike

RE: Problems writing/reading struct to NVS

Simon — Wed, 13 Jul 2022 16:31:13 GMT

I didn't get time to look to deeply into this today, but I'll just leave one comment. If I remember correctly, one sector almost always free - it is used during garbage-collection procedrue. So I think you have to subtract one sector, and that is the available area you can use.

Down below I've copied in a reply I made more than a year ago in another ticket:

If you look at the start of the sample zephyr\samples\subsys\nvs\src\main.c, the sector size and sector count is fed into nvs_init(). The sector size and sector count decides how much memory is allocetd for NVS and the offset decides where in flash to place the NVS partition. Other flash procedures will not (and should not) touch the NVS area.

The available memory for the sample zephyr\samples\subsys\nvs can be calculated in the following manner

ate_size = 8, sector_size = 4096 (check this reply for an explanation of these numbers (I used the 52840 during testing as well))
sector_count = 3 (it's set here)

available_sectors = sector count - 1 (subtract 1, since one sector is free and used for garbage collection procedure)

available NVS memory = sector_size * available_sectors - ate_size * available_sectors (read this reply to understnd why we need to subtract ate_size*av. sectors)

available NVS memory = 4096 * 2 - 8 * 2 = 8176

I tested this out, by adding the following code to the sample zephyr\samples\subsys\nvs:
	rc = nvs_init(&fs, flash_dev->name);
	if (rc) {
		printk("Flash Init failed\n");
		return;
	}
	ssize_t free_space = nvs_calc_free_space(&fs);
	printk("Free space: %d (should be %d)\n", free_space, fs.sector_size*(fs.sector_count-1)-(8*2));
	strcpy(buf, "abcdefghijklmnopqstuvwxyzabcdefghijklmnopqstuvwxyabcdefghijklmnopqstuvwxyzabcdefghijklmnopqstuvwxyz");
	printk("Write %d bytes\n", strlen(buf)+1);
	(void)nvs_write(&fs, ADDRESS_ID, &buf, strlen(buf)+1);
	free_space = nvs_calc_free_space(&fs);
	printk("Free space: %d\n", free_space);
I then got the following output:
Free space: 8176 (should be 8176)
Write 100 bytes
Free space: 8068
As you can see, the output corresponds to the calculations.

The free space after writing is not 8176-100=8076, but 8068, which is because each stored record requires 8 bytes of metadata in addition (as mentioned in the NVS documentation), which gives 8176 - 100 - 8 = 8068

Best regards,

Simon

RE: Problems writing/reading struct to NVS

Mike Austin (LPI) — Wed, 13 Jul 2022 03:48:52 GMT

Hi Simon,

Thanks for sticking with me on this!

OK, I'm getting things working, but I'm still coming unstuck when I try and push the size of my data logging array up towards the size I want it. I'm clearly not understanding how the flash is arranged/configured. Or there is something else at play

At the moment, I have the static partitions configured as follows:

user_storage:
  address: 0x7c000
  size: 0x2000
  placement:
    before: 
    - settings_storage
  region: flash_primary
settings_storage:
  address: 0x7e000
  size: 0x2000
  placement:
    before:
    - end
  region: flash_primary

I'm outputting my flash and user info data via UART so I can check everything is OK. This is what I get with the above configuration, and with the number of sectors set to 2.

Sector size = 4096
Sector count = 2
Sector size*count = 8192
User storage = 8192

Now, what I'm writing to flash consists of the following:

	(void)nvs_write(&fs, TOTAL_STRIKE_COUNT_ID, &strike_count_total, sizeof(strike_count_total));
	(void)nvs_write(&fs, STRIKE_SML_ID, &strike_count_sml, sizeof(strike_count_sml));
	(void)nvs_write(&fs, STRIKE_MED_ID, &strike_count_med, sizeof(strike_count_med));
	(void)nvs_write(&fs, STRIKE_LRG_ID, &strike_count_lrg, sizeof(strike_count_lrg));
	(void)nvs_write(&fs, LOG_DATA_ID, &lsr_strike_log, sizeof(lsr_strike_log));

These are defined as:

#define MAX_STRIKE_RECORDS 150

uint16_t strike_count_total = 0;
uint16_t strike_count_sml = 0;
uint16_t strike_count_med = 0;
uint16_t strike_count_lrg = 0;

struct log_data {
	uint8_t	strike_level;  // SML = 1, MED = 2 or LRG = 4
	uint16_t year;
	uint8_t month;
	uint8_t day;
	uint8_t hours;
	uint8_t minutes;
	uint8_t seconds;
};

struct log_data lsr_strike_log[MAX_STRIKE_RECORDS];

What I'm trying to do is make enough flash space available to be able to store all that, but with MAX_STRIKE_RECORDS = 250. At the moment, things go pear shaped with MAX_STRIKE_RECORDS > 195. And I'm not sure why, nor what to do about it. By my reckoning, I have more than enough space, but it almost seems like what I'm trying to store is consuming twice what I think it is.

From here: https://docs.zephyrproject.org/latest/services/storage/nvs/nvs.html it looks like each of the elements being stored in flash needs:

8 bytes of meta-data + 1 byte of id + sizeof(data).

I have 8 elements in total (key, batch, serial, total, sml, med, lrg and log)

Each one of my lsr_strike_log array elements seems to use up 10 bytes of data.

So, by my calcs, the total amount of flash storage for 250 records is:

key = 8 + 1 + 3 = 12

batch = 8 + 1 + 4 = 13

serial = 8 + 1 + 2 = 11

total = 8 + 1 + 2 = 11

sml = 8 + 1 + 2 = 11

med = 8 + 1 + 2 = 11

lrg = 8 + 1 + 2 = 11

log = 8 + 1 + 250x10 = 2509

Which gives me 2589 bytes. I have 4096 in each sector, which seems ample to me. But things bomb out when I go past MAX_STRIKE_RECORDS = 195. This requires 2039 bytes in total. Which is almost exactly half the size of one sector (4096 bytes).

If I set MAX_STRIKE_RECORDS > 195, then when I try and write the log data to flash via:

val = nvs_write(&fs, LOG_DATA_ID, &lsr_strike_log, sizeof(lsr_strike_log));
if (val < 0)
{
	printk("Return val on log data write  = %d\n", val);
}

I get a return value of -28, which equates to:

ENOSPC 28       /**< No space left on device */

So, my questions are:

1. Why, when it looks like I've got more than enough user storage allocated, do I run out of room?

2. How can I increase my user storage so I have enough room for 250 log array elements?

Cheers,

Mike

RE: Problems writing/reading struct to NVS

Simon — Mon, 11 Jul 2022 13:30:38 GMT

I played around with the NVS sample and made it use the Partition Manager (PM) instead of DTS (did this by setting CONFIG_BOOTLOADER_MCUBOOT=y, since PM will be used when child images are added).

I was able to make it work with nrf52dk_nrf52832 and NCS v2.0.0

devzone.nordicsemi.com/.../nvs_5F00_prt_5F00_mngr.zip

If the PM is enabled the macros used (FLASH_AREA_OFFSET() for example), will get info from PM instead of DTS. See

One thing you should be aware of, don't let NVS use the area outside the custom partition. Make sure (sector size)*(sector count) is smaller than user_storage.

Best regards,

Simon

RE: Problems writing/reading struct to NVS

Mike Austin (LPI) — Thu, 07 Jul 2022 23:59:23 GMT

Hi Simon,

Did a bit more digging. The issue is in fact when I try and get the flash page info. I think the BLE thing is a side issue.

I trawled through the DevZone and found this, which seems to be along similar lines to what I'm doing:

Issue with flash partitions in NCS 1.7.0 on nRF9160

This is what my flash initialisation function now looks like:

int16_t flash_initialise(void)
{
    int16_t rc;

	//flash_dev = DEVICE_DT_GET(FLASH_NODE);
	flash_dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_flash_controller));
	if (!device_is_ready(flash_dev)) {
		#ifdef DEBUG_NVS
			printk("Flash device %s is not ready\n", flash_dev->name);
		#endif
		return -EINVAL;
	}
	
	#ifdef DEBUG_NVS
		printk("Flash device %s is ready\n",flash_dev->name);
	#endif

	fs.offset = FLASH_AREA_OFFSET(storage);
	rc = flash_get_page_info_by_offs(flash_dev, fs.offset, &info);
	if (rc !=0) 
	{
		#ifdef DEBUG_NVS		
			printk("Unable to get page info\n");
		#endif
		return rc;
	}
	#ifdef DEBUG_NVS
		printk("Page info OK\n");
	#endif
	fs.sector_size = info.size;
	fs.sector_count = NVS_SECTOR_COUNT;

	rc = nvs_init(&fs, flash_dev->name);
	if (rc !=0) 
	{
		#ifdef DEBUG_NVS
			printk("Flash Init failed\n");
		#endif
		return rc;
	}
	#ifdef DEBUG_NVS
		printk("Flash initialised OK\n");
	#endif

	// Check if data is stored in flash
	rc = check_for_nvs_key();
	return rc;
	
}

So, I'm now getting the device via:

flash_dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_flash_controller));

And that appears to be working. But when I then attempt to get the offset for my NVS file system struct, via:

	fs.offset = FLASH_AREA_OFFSET(user_storage);
	rc = flash_get_page_info_by_offs(flash_dev, fs.offset, &info);
	if (rc !=0) 
	{
		#ifdef DEBUG_NVS		
			printk("Unable to get page info\n");
		#endif
		return rc;
	}

I'm still not successfully getting the page info, as I get the error message "Unable to get page info"

Clearly, I'm not really understanding how, with the static partitions definition as opposed to those defined in the .DTS, I should be initialising my flash device.

Cheers,

Mike

RE: Problems writing/reading struct to NVS

Mike Austin (LPI) — Thu, 07 Jul 2022 04:59:11 GMT

Hi Simon,

I'm definitely entering unchartered waters here now!

OK, so this is what my partitions.yml file looked like before:

mcuboot_primary_app:
  address: 0xc200
  end_address: 0x45000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x38e00
  span: *id002
mcuboot_secondary:
  address: 0x45000
  end_address: 0x7e000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x39000
settings_storage:
  address: 0x7e000
  end_address: 0x80000
  placement:
    align:
      start: 0x1000
    before:
    - end
  region: flash_primary
  size: 0x2000
sram_primary:
  address: 0x20000000
  end_address: 0x20010000
  region: sram_primary
  size: 0x10000

So, I created a pm_static.yml file as you suggested. A simple copy and paste of the one Vidar listed threw up some errors associated with gaps in the memory (or something). So, I made my pm_static.yml look like this so that the gaps in memory, as I saw it, were "plugged"

user_storage:
  address: 0x80000
  size: 0x2000
  end_address: 0x82000
  placement:
    before: 
    - settings_storage
  region: flash_primary
settings_storage:
  address: 0x82000
  size: 0x2000
  end_address: 0x84000
  placement:
    before:
    - end
  region: flash_primary

This is giving me 0x2000 of settings_storage and an additional 0x2000 of user_storage, which in theory should be enough.

Then, where I define my flash device, I have:

#define STORAGE_NODE_LABEL user_storage
const struct device *flash_dev;
static struct nvs_fs fs;

// Initialise NVS and check for NVS key
// Presence of key means there is valid data stored in NVS
int16_t flash_initialise(void)
{
    int16_t rc;

	flash_dev = FLASH_AREA_DEVICE(STORAGE_NODE_LABEL);
	if (!device_is_ready(flash_dev)) {
		#ifdef DEBUG_NVS
			printk("Flash device %s is not ready\n", flash_dev->name);
		#endif
		return -EINVAL;
	}
	
	#ifdef DEBUG_NVS
		printk("Flash device %s is ready\n",flash_dev->name);
	#endif

	fs.offset = FLASH_AREA_OFFSET(STORAGE_NODE_LABEL);
	rc = flash_get_page_info_by_offs(flash_dev, fs.offset, &info);
	if (rc !=0) 
	{
		#ifdef DEBUG_NVS		
			printk("Unable to get page info\n");
		#endif
		return rc;
	}
	#ifdef DEBUG_NVS
		printk("Page info OK\n");
	#endif
	fs.sector_size = info.size;
	fs.sector_count = NVS_SECTOR_COUNT;

	rc = nvs_init(&fs, flash_dev->name);
	if (rc !=0) 
	{
		#ifdef DEBUG_NVS
			printk("Flash Init failed\n");
		#endif
		return rc;
	}
	#ifdef DEBUG_NVS
		printk("Flash initialised OK\n");
	#endif

	// Check if data is stored in flash
	rc = check_for_nvs_key();
	return rc;
	
}

I use my function flash_initialise to set up my storage*

That all builds OK, and I can flash it to my DK. Problem is, when my code fires up BLE advertising, the advertising fails to start, and I get error code "-EAGAIN" from the call to bt_le_adv_start_legacy(), which gets called as part of bt_le_adv_start().

So, I'm doing something wrong, as when I go back to the dynamic memory allocation using the DTS, the problem goes away.

Can you see anything obvious that I'm doing that would affect the BLE functionality?

* As an aside, the nvs_init() that I call in flash_initialise() shows as deprecated when I build, but my code crashes when I replace that with the suggested alternative nvs_mount(). Not sure why.

Cheers,

Mike

RE: Problems writing/reading struct to NVS

Simon — Wed, 06 Jul 2022 11:28:44 GMT

Ah, okay.

Check the note in the documentation about the Partition Manager:

"When you build a multi-image application using the Partition Manager, the Device Tree Source flash partitions are ignored."

So you should create the storage partition through a pm_static.yml file

Vidar provided one example how to go about this in this reply: RE: Problem to read back flash with NVS when concurrent use with Bluetooth

Then you should be able to access the size and address of the user storage from your application (generated defines will be located in <sample>\build\zephyr\include\generated\pm_config.h I believe), which you can use to set up NVS to store custom data.

By the way, Bluetooth bonding uses NVS as well (settings_storage), so that may interfere with your custom NVS data, in the ticket above that was resolved by creating a separate partition (user_storage).

However, I think it should be possible to use the same partition for both cases, see Concurrent usage of NV and settings on the same partition

Best regards,

Simon

RE: Problems writing/reading struct to NVS

Mike Austin (LPI) — Wed, 06 Jul 2022 05:13:09 GMT

Hi Simon,

Yes, I have partition manager enabled via:

# Partition Manager

CONFIG_PARTITION_MANAGER_ENABLED=y

CONFIG_FLASH_MAP_CUSTOM=y

CONFIG_SRAM_SIZE=64

CONFIG_SRAM_BASE_ADDRESS=0x20000000

Cheers,

Mike

RE: Problems writing/reading struct to NVS

Simon — Mon, 04 Jul 2022 11:59:18 GMT

Sorry for the delay, I was gone on Friday.

Could you check if the partition manager is enabled?

You can do that by searching for CONFIG_PARTITION_MANAGER_ENABLED in <sample>build/zephyr/.config and see if it's set to 'y'.

Partition Manager is enabled when you're including child images (like mcuboot) and the dts partitions will be ignored.

Best regards,

Simon

RE: Problems writing/reading struct to NVS

Mike Austin (LPI) — Wed, 29 Jun 2022 21:04:32 GMT

Hi Simon,

I seem to have this working now. Only problem is, I'm not able to get everything I want stored in NVS as I am running out of room. And I'm not sure how to make more space, or indeed if I can.

My struct takes up 12 bytes per array element, and I am trying to have capacity for up to 250 array elements. At the moment, I hit a wall around 167. I've got a few other bytes of info I store in NVS that are separate to this array - they take up about 15 bytes in total.

This is how the flash is allocated in my .dts file (this is the default for the nRF52-DK)

&flash0 {

	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0xc000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0x0000C000 0x32000>;
		};
		slot1_partition: partition@3e000 {
			label = "image-1";
			reg = <0x0003E000 0x32000>;
		};
		scratch_partition: partition@70000 {
			label = "image-scratch";
			reg = <0x00070000 0xa000>;
		};
		storage_partition: partition@7a000 {
			label = "storage";
			reg = <0x0007a000 0x00006000>;
		};
	};
};

And this is how I have my flash device set up in my code (based on the example code)

int16_t flash_initialise(void)
{
    int16_t rc;

	flash_dev = FLASH_AREA_DEVICE(STORAGE_NODE_LABEL);
	if (!device_is_ready(flash_dev)) {
		#ifdef DEBUG_NVS
			printk("Flash device %s is not ready\n", flash_dev->name);
		#endif
		return -EINVAL;
	}
	printk("Flash device %s is ready\n",flash_dev->name);

	fs.offset = FLASH_AREA_OFFSET(storage);
	rc = flash_get_page_info_by_offs(flash_dev, fs.offset, &info);
	if (rc !=0) 
	{
		#ifdef DEBUG_NVS		
			printk("Unable to get page info\n");
		#endif
		return rc;
	}
	#ifdef DEBUG_NVS
		printk("Page info OK\n");
	#endif
	fs.sector_size = info.size;
	fs.sector_count = 2U;

	rc = nvs_init(&fs, flash_dev->name);
	if (rc !=0) 
	{
		#ifdef DEBUG_NVS
			printk("Flash Init failed\n");
		#endif
		return rc;
	}
	#ifdef DEBUG_NVS
		printk("Flash initialised OK\n");
	#endif

	// Check if data is stored in flash
	rc = check_for_nvs_key();
	return rc;
	
}

As I understand it, the available flash storage size is 0x6000, which is about 24kB. And I have allocated two sectors, each of 4096 bytes.

So, I'm not sure why I'm running into storage problems.

Sorry if this sounds like a pretty basic question, but I can't seem to find any info that would help me understand why I'm running out of storage space and how to increase it

Cheers,

Mike

RE: Problems writing/reading struct to NVS

Simon — Fri, 24 Jun 2022 16:36:05 GMT

[quote user="Mike Austin (LPI)"]I’ll update this thread in a week or so when I’ve had a chance to do some more testing[/quote]

Sounds good👍

RE: Problems writing/reading struct to NVS

Mike Austin (LPI) — Thu, 23 Jun 2022 19:30:12 GMT

Hi Simon,

I’m just about to get back into this part of it after struggling with issues around GPIO/System OFF/MCUBoot for nearly a month.

I’ll update this thread in a week or so when I’ve had a chance to do some more testing

Cheers,

Mike

RE: Problems writing/reading struct to NVS

Simon — Thu, 23 Jun 2022 14:34:41 GMT

Hello Mike,

What is the current state on this issue?

Best regards,

Simon

RE: Problems writing/reading struct to NVS

Mike Austin (LPI) — Wed, 20 Apr 2022 22:48:55 GMT

Thanks Haakonsh.

If I simplify what I'm trying to write to NVS, it seems to work OK. I changed my data structure to just a simple array:

uint16_t lsr_strike_log[9];

And if I write/read this to NVS, I can see that the data is being stored. I'm still getting weird values for the return value from nvs_write() and nvs_read() though.

This is the log info I see when writing the simple array:

If I try and write my struct to NVS in the form I ultimately want to, I crash my DK and it keeps rebooting.

In my code I initialse NVS before I initialise anything to do with BLE, so not sure if the BLE initialisation then changes what I've done when setting up NVS?

Thanks and regards,

Mike

RE: Problems writing/reading struct to NVS

haakonsh — Wed, 20 Apr 2022 14:20:45 GMT

I think NVS might already be initialized by the bluetooth stack, it uses it to store certain settings. I'll do some digging and see what I can find.