Writing/reading data to external flash on the nRF9160DK

[nWre]

Hello Nordic!

I have connected a sensor to the DK via SPI. It outputs a lot of data, a lot... for 1 second of data I get 4096 entries. Each entry is 10 bytes in length.

I want to store 20 seconds of sensor data on the flash memory, that is a total of about 0,8 MB if my calculations are correct.

The sensor has a FIFO-queue so if the write operation is quick enough there shouldn't be any data loss.
Once 20 seconds worth of data is recorded I then want to send this via LTE to server, I'm guessing in chunks.

Questions:
* How do I go about this? Is there a binary write example available?

* What size should the chunks be for this example?

* Once a file is written and done, before going in to the LTE-part of the design, is there any way to extract the bin file for data validation from the DK?

Thank you!

[nWre]

Hi Sebastiaan! Thank you for answering, truly appreciate it! I was to understand that the nRF9160DK has a 64 Mb external flash memory described here:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrf91_dk%2FUG%2Fnrf91_DK%2Fexternal_memory.html

This is indeed done via SPI.

I'm thinking http communication but that is mostly because it's the one I know and have used, does it make much of a difference?

That's a clever solution for getting the data, I will look into that solution.

Many thanks!

[Håkon Alseth]

Since you mention using the nRF9160DK's external flash, it is important that you switch in the lines for the external flash. That is done by re-programming the board controller, with the sequence explained here:

https://devzone.nordicsemi.com/f/nordic-q-a/80836/extend-flash-size-of-nrf9160---single-slot-application/335345#335345

 

create the file my_project/pm_static.yml, which holds something like this (alter sizes to your needs):

settings_storage:
  address: 0x0
  region: external_flash
  size: 0x40000

 

Kind regards,

Håkon

[nWre]

Hi! Thanks Håkon! I'm already using SPI3 for a sensor, can I just add an arbitrary number to the SPI interface? Like SPI4? Are there any examples writing to the external flash? I'd like to create numerous .bin or .hex files which I then send via LTE to server, once acknowledged that they are recieved, I want to free up that memory for other sensor data.

[Håkon Alseth]

Hi,

 

nWre said:

I'm already using SPI3 for a sensor, can I just add an arbitrary number to the SPI interface? Like SPI4?

No, do not do that. This will then point the hardware to a non-existing SPI instance. nRF9160 has from 0 to 3:

https://infocenter.nordicsemi.com/topic/ps_nrf9160/spim.html?cp=2_0_0_5_12_5#topic

If you want to setup more than one sensor, you should do it similar to how it is done on the thingy91:

https://github.com/nrfconnect/sdk-nrf/blob/main/boards/arm/thingy91_nrf9160/thingy91_nrf9160_common.dts#L128-L151

 

nWre said:

Are there any examples writing to the external flash? I'd like to create numerous .bin or .hex files which I then send via LTE to server, once acknowledged that they are recieved, I want to free up that memory for other sensor data.

Once you have setup the external flash area, you can address it directly to the flash-backend that you're using (NVS, littlefs or which ever you chose). The logic you require needs to be added manually in your application.

 

Kind regards,

Håkon

[nWre]

Hi! I have it setup like this in an overlay file:

&spi3 {
	compatible = "nordic,nrf-spim";
	status = "okay";
	sck-pin = <19>;
	mosi-pin = <18>; 
	miso-pin = <17>; 
	cs-gpios = <&gpio0 23 0>,<&gpio0 22 0>,<&gpio0 21 0>; 
	clock-frequency = <10000000>;
	label = "SENSORARRAY";
	sensor8: sensor8@0 {
		compatible = "adi,adxl355";
		status = "okay";
		label = "sensor8";
		spi-max-frequency = <10000000>;
		reg = <0>;
	};

	sensor40: sensor40@1 {
		compatible = "adi,adxl357";
		status = "okay";
		label = "sensor40";
		spi-max-frequency = <10000000>;
		reg = <1>;
	};
	sensor200: sensor200@2 {
		compatible = "adi,adxl375";
		status = "okay";
		label = "sensor200";
		spi-max-frequency = <10000000>;
		reg = <2>;
	};
};

I can communicate with the sensors but they do interfere with each other even when their corresponding cs-pin is set to high(blocking). I don't really understand why but one question I have about this is if

spi_dev = device_get_binding("SENSORARRAY");

Instead should be separated by child nodes, like this

spi_dev8 = device_get_binding("sensor8");
spi_dev40 = device_get_binding("sensor40");
spi_dev200 = device_get_binding("sensor200");

I've tried this all day but couldn't get any other value from this but null. I've tried aliases, node_label, node_path but nothing. Maybe I'm misunderstanding this and that the master is the dev, not the slaves.

I'm using the same MISO,MOSI and SCLK lines for all three. They also share 3V-input and GRND. Apart from this they have different CS-pins. I've tried them one by one and they're all working, however when I connect more than one sensor, there is interference.

I hope you can clear some of this up for me, I'll keep banging my head against your fine hardware in the meantime ;)

Snowy, gothenburgian regards!

Edit: It appears as though I am not the solderer I thought I was. The interference came from shoddy soldering. I would still like to know the answer to the device binding question though, as of now, it works with getting the spi binding for all three sensors.

[Håkon Alseth]

Hi,

nWre said:

Snowy, gothenburgian regards!

Close to 15 below, and around 20 cm of snow here as well!

 

nWre said:

Edit: It appears as though I am not the solderer I thought I was. The interference came from shoddy soldering. I would still like to know the answer to the device binding question though, as of now, it works with getting the spi binding for all three sensors.

Glad to hear that you found the root cause of the hardware-wise connections.

I have some bad news for you. The sensors that you configure for are not compatible with any sources (note: dts "compatible = "vendor,component"" maps to source files, which are then included in your project):

https://github.com/nrfconnect/sdk-zephyr/tree/main/dts/bindings/sensor

 

adxl345, 362 and 372 are supported by zephyr. I'm not sure that your sensors are compatible 1-to-1 with those drivers, so you might have to interface them manually, using the spi driver directly. Here's a sample a colleague of mine wrote:

https://github.com/sigurdnev/ncs-playground/tree/master/samples/spi_test

 

Snowy regards from Trondheim,

Håkon

[nWre]

It is a rare treat for us to get snow down here and even though the entire community and infrastructure shuts down, I really enjoy it. I miss living in the north.

Ontopic: Yes, I realized that too, so I've written my own drivers by studying the datasheet of the respective component. They are included in my main.c-file. The compatible part is really just a copy paste of the adxl362 and doesn't contain any functionality. The drivers are working flawlessly for 2 of the 3 sensors. I am yet to figure out what causes problem with the third one. I handle the cs-pins manually, putting them high or low before reads/write. On these sensors, a high cs pin blocks data. So reading from 1 sensor, keeping the other two cs pins high, should only give me data stream from that sensor, however, there is a strange interference when doing this. Sorry for rambling, I understand this is impossible for you to help with.

Off to spend the weekend in the woods in a tent, with a stove and multiple beers.
Take care Håkon, I'll return with more rambling questions about writing to external memory in a bit

[Håkon Alseth]

Hi,

 

nWre said:

It is a rare treat for us to get snow down here and even though the entire community and infrastructure shuts down, I really enjoy it. I miss living in the north.

Snow is wonderful, I agree. It brightens the day during these darker winter days.

 

nWre said:

Ontopic: Yes, I realized that too, so I've written my own drivers by studying the datasheet of the respective component. They are included in my main.c-file. The compatible part is really just a copy paste of the adxl362 and doesn't contain any functionality. The drivers are working flawlessly for 2 of the 3 sensors. I am yet to figure out what causes problem with the third one. I handle the cs-pins manually, putting them high or low before reads/write. On these sensors, a high cs pin blocks data. So reading from 1 sensor, keeping the other two cs pins high, should only give me data stream from that sensor, however, there is a strange interference when doing this. Sorry for rambling, I understand this is impossible for you to help with.

I'd recommend using a logic analyzer (saleae or similar if you have available) to decode the SPI traffic (MOSI, MISO, CLK, CSN) to see if there's anything out-of-the-ordinary.

If there's a interference, you could try other GPIOs to see if there might be a hardware related issue on specific GPIOs (soldering or similar?).

nWre said:

Off to spend the weekend in the woods in a tent, with a stove and multiple beers.
Take care Håkon, I'll return with more rambling questions about writing to external memory in a bit

Take care, hope you have a wonderful weekend!

 

Kind regards,

Håkon

[nWre]

Hi again Håkon! Hoppas allt är bra med dig!

I've flashed the sequence you linked earlier with the prog/debug-switch on nrf52:

/ {
        board-control {
                external_flash_pins_routing: switch-ext-mem-ctrl {
                        compatible = "nordic,nrf9160dk-optional-routing";
                        control-gpios = <&gpio0 19 GPIO_ACTIVE_HIGH>;
                        status = "okay";
                };
        };
};

I've also added the SPI-code that you linked:

&spi3 {
	status = "okay";
	sck-pin = <13>;
	mosi-pin = <11>;
	miso-pin = <12>;
	cs-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
	mx25r64: mx25r6435f@0 {
		compatible = "jedec,spi-nor";
		reg = <0>;
		spi-max-frequency = <8000000>;
		label = "MX25R64";
		jedec-id = [c2 28 17];
		sfdp-bfp = [
			e5 20 f1 ff  ff ff ff 03  44 eb 08 6b  08 3b 04 bb
			ee ff ff ff  ff ff 00 ff  ff ff 00 ff  0c 20 0f 52
			10 d8 00 ff  23 72 f5 00  82 ed 04 cc  44 83 68 44
			30 b0 30 b0  f7 c4 d5 5c  00 be 29 ff  f0 d0 ff ff
		];
		size = <67108864>;
		has-dpd;
		t-enter-dpd = <10000>;
		t-exit-dpd = <35000>;
	};
};

Should the CS-GPIOS match? Now that this config is done, should I be able to use say, LittleFS to write to the external memory by pointing it towards the MX25R64 in the device tree? Is there any other config I should do?

Kind regards
nWre

[Håkon Alseth]

Hi nWre!

 

nWre said:

Hi again Håkon! Hoppas allt är bra med dig!

All good here, thanks! Hope you had a wonderful trip!

 

nWre said:

I've flashed the sequence you linked earlier with the prog/debug-switch on nrf52:

nWre said:

I've also added the SPI-code that you linked:

 

The "board-control" is setting a pin on the nRF52840 on the DK to route the ext-flash to the nRF91, while the next is a direct setting of which nRF9160 GPIO on the is connected to the /CS pin on the external-flash itself.

 

They should match the hardware layout of the nRF9160-DK, which they do by default.

 

nWre said:

Now that this config is done, should I be able to use say, LittleFS to write to the external memory by pointing it towards the MX25R64 in the device tree? Is there any other config I should do?

Define it in your pm_static.yml, here from addr offset 0, size 256kB in region "external_flash":

littlefs_storage:
  address: 0x0
  device: MX25R64
  end_address: 0x40000
  region: external_flash
  size: 0x40000

 

Remember to re-generate your build after altering the pm_static.yml!

 

Kind regards,

Håkon

[nWre]

Seems like the namespace littlefs_storage is not accepted when I try to build the project. I get this:

'PM_littlefs_storage_ID' undeclared here (not in a function); did you mean 'littlefs_storage'?

I'm trying to use the example from Zephyr

/* Matches LFS_NAME_MAX */
#define MAX_PATH_LEN 255

#define PARTITION_NODE DT_NODELABEL(mx25r6435f)

#if DT_NODE_EXISTS(PARTITION_NODE)
FS_FSTAB_DECLARE_ENTRY(PARTITION_NODE);
#else  /* PARTITION_NODE */
FS_LITTLEFS_DECLARE_DEFAULT_CONFIG(storage);
static struct fs_mount_t lfs_storage_mnt = {
	.type = FS_LITTLEFS,
	.fs_data = &storage,
	.storage_dev = (void *)FLASH_AREA_ID(storage),
	.mnt_point = "/lfs",
};
#endif /* PARTITION_NODE */

void memtest(void)
{
	struct fs_mount_t *mp =
#if DT_NODE_EXISTS(PARTITION_NODE)
		&FS_FSTAB_ENTRY(PARTITION_NODE)
#else
		&lfs_storage_mnt
#endif
		;
	unsigned int id = (uintptr_t)mp->storage_dev;
	char fname[MAX_PATH_LEN];
	struct fs_statvfs sbuf;
	const struct flash_area *pfa;
	int rc;

	snprintf(fname, sizeof(fname), "%s/boot_count", mp->mnt_point);

	rc = flash_area_open(id, &pfa);
	if (rc < 0)
	{
		printk("FAIL: unable to find flash area %u: %d\n",
			   id, rc);
		return;
	}

	printk("Area %u at 0x%x on %s for %u bytes\n",
		   id, (unsigned int)pfa->fa_off, pfa->fa_dev_name,
		   (unsigned int)pfa->fa_size);

	/* Optional wipe flash contents */
	if (IS_ENABLED(CONFIG_APP_WIPE_STORAGE))
	{
		printk("Erasing flash area ... ");
		rc = flash_area_erase(pfa, 0, pfa->fa_size);
		printk("%d\n", rc);
	}

	flash_area_close(pfa);

	/* Do not mount if auto-mount has been enabled */
#if !DT_NODE_EXISTS(PARTITION_NODE) || \
	!(FSTAB_ENTRY_DT_MOUNT_FLAGS(PARTITION_NODE) & FS_MOUNT_FLAG_AUTOMOUNT)
	rc = fs_mount(mp);
	if (rc < 0)
	{
		printk("FAIL: mount id %u at %s: %d\n",
			   (unsigned int)mp->storage_dev, mp->mnt_point,
			   rc);
		return;
	}
	printk("%s mount: %d\n", mp->mnt_point, rc);
#else
	printk("%s automounted\n", mp->mnt_point);
#endif

	rc = fs_statvfs(mp->mnt_point, &sbuf);
	if (rc < 0)
	{
		printk("FAIL: statvfs: %d\n", rc);
		goto out;
	}

	printk("%s: bsize = %lu ; frsize = %lu ;"
		   " blocks = %lu ; bfree = %lu\n",
		   mp->mnt_point,
		   sbuf.f_bsize, sbuf.f_frsize,
		   sbuf.f_blocks, sbuf.f_bfree);

	struct fs_dirent dirent;

	rc = fs_stat(fname, &dirent);
	printk("%s stat: %d\n", fname, rc);
	if (rc >= 0)
	{
		printk("\tfn '%s' siz %u\n", dirent.name, dirent.size);
	}

	struct fs_file_t file;

	fs_file_t_init(&file);

	rc = fs_open(&file, fname, FS_O_CREATE | FS_O_RDWR);
	if (rc < 0)
	{
		printk("FAIL: open %s: %d\n", fname, rc);
		goto out;
	}

	uint32_t boot_count = 0;

	if (rc >= 0)
	{
		rc = fs_read(&file, &boot_count, sizeof(boot_count));
		printk("%s read count %u: %d\n", fname, boot_count, rc);
		rc = fs_seek(&file, 0, FS_SEEK_SET);
		printk("%s seek start: %d\n", fname, rc);
	}

	boot_count += 1;
	rc = fs_write(&file, &boot_count, sizeof(boot_count));
	printk("%s write new boot count %u: %d\n", fname,
		   boot_count, rc);

	rc = fs_close(&file);
	printk("%s close: %d\n", fname, rc);

	struct fs_dir_t dir;

	fs_dir_t_init(&dir);

	rc = fs_opendir(&dir, mp->mnt_point);
	printk("%s opendir: %d\n", mp->mnt_point, rc);

	while (rc >= 0)
	{
		struct fs_dirent ent = {0};

		rc = fs_readdir(&dir, &ent);
		if (rc < 0)
		{
			break;
		}
		if (ent.name[0] == 0)
		{
			printk("End of files\n");
			break;
		}
		printk("  %c %u %s\n",
			   (ent.type == FS_DIR_ENTRY_FILE) ? 'F' : 'D',
			   ent.size,
			   ent.name);
	}

	(void)fs_closedir(&dir);

out:
	rc = fs_unmount(mp);
	printk("%s unmount: %d\n", mp->mnt_point, rc);
}

Önsker deg en nydelig helg!

[Håkon Alseth]

Hi,

 

Here's a modified littlefs sample, with nrf9160dk ext flash support:

ncs1_7_nrf9160dk_ext_flash_littlefs.zip

 

Kind regards,

Håkon