nr52832 + nRF Connect 1.8.0 + External Flash

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Tue, 10 May 2022 18:40:09 GMT

Thanks, Hakon. I'll check this option.

Really appreciate your support..!!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Tue, 10 May 2022 12:57:10 GMT

Hi,

Great to hear that you found the root-cause of the issue!

[quote user="harshal034"]Can there be a cleaner way the this? Or we can use this workaround?[/quote]

You could make your own board file, add a board.c file, similar to this:

https://github.com/nrfconnect/sdk-zephyr/blob/v2.7.99-ncs1-1/boards/arm/thingy52_nrf52832/CMakeLists.txt#L5

https://github.com/nrfconnect/sdk-zephyr/blob/main/boards/arm/thingy52_nrf52832/board.c

where you add a 5 ms delay in case SPI_NOR is selected, and also add a check if the init priority is lower than the spi_nor library.

Kind regards,

Håkon

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Mon, 09 May 2022 22:07:03 GMT

Hi Hakon,

Thanks for the response. I added 6 ms delay in the code before reading the JEDEC ID.

With this change, now when I flash the device or power the board, it works (first time as well).

Can there be a cleaner way the this? Or we can use this workaround?

TIA!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Mon, 09 May 2022 14:21:24 GMT

Hi,

[quote user="harshal034"]and also when we connect power to the board for the first time[/quote]

This is interesting. It does sound like a timing issue.

Could you scope the SPI lines, VDD_NRF and VDD_SPI, to see if the "time delay before write instruction" (tPUW in the flash datasheet) of 5 ms is honored on the very first run?

If you are unsure on how to test the above, or do not have such equipment available, you could (only for testing purposes!!) try to add a k_sleep delay before this sequence:

https://github.com/nrfconnect/sdk-zephyr/blob/v2.7.0-ncs1/drivers/flash/spi_nor.c#L1037-L1055

Kind regards,

Håkon

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Fri, 06 May 2022 17:13:31 GMT

Hi Hakon,

I tried what you suggested and here is the outcome:

Erase and Flash the board using VS Code. ==> Flash chip not detected (E: Device id 00 00 00 does not match config ef 40 14) and device get for Flash failed

Start the debug using VS Code. ==> Flash chip detected and I am able to get the device binding and do erase oeration on Flash chip.

Logs:

Reading symbols from c:\Users\ncs\v1.8.0\toolchain\opt\bin\arm-none-eabi-objdump.exe --syms -C -h -w c:\Users\Documents\Work\build\zephyr\zephyr.hex
Reading symbols from c:/users\ncs\v1.8.0\toolchain\opt\bin\arm-none-eabi-nm.exe --defined-only -S -l -C -p c:\Users\Documents\Work\build\zephyr\zephyr.hex
Launching GDB: "c:\\Users\\ncs\\v1.8.0\\toolchain\\opt\\bin\\arm-none-eabi-gdb.exe" -q --interpreter=mi2 "c:\\Users\\Documents\\\Work\\build\\zephyr\\zephyr.hex"
    Set "showDevDebugOutput": true in your "launch.json" to see verbose GDB transactions here. Helpful to debug issues or report problems
Launching gdb-server: "C:\\Program Files\\SEGGER\\JLink\\JLinkGDBServerCL.exe" -singlerun -nogui -if swd -port 50007 -swoport 50008 -telnetport 50009 -device nRF52832_xxAA -select usb=601005338 -rtos "C:\\Program Files\\SEGGER\\JLink\\GDBServer\\RTOSPlugin_Zephyr.dll"
    Please check TERMINAL tab (gdb-server) for output from C:\Program Files\SEGGER\JLink\JLinkGDBServerCL.exe
Finished reading symbols from nm: Time: 186 ms
Finished reading symbols from objdump: Time: 234 ms
Reading symbols from c:\Users\Documents\Work\build\zephyr\zephyr.hex...
(No debugging symbols found in c:\Users\Documents\Work\build\zephyr\zephyr.hex)
WARNING: Cortex-Debug will deprecate use of GDB version 8 after July 2022. Please upgrade to version 9+
0x0001999e in ?? ()
Program stopped, probably due to a reset and/or halt issued by debugger
add symbol table from file "c:/Users/Documents/Work/build/zephyr/zephyr.elf"
(y or n) [answered Y; input not from terminal]
Reading symbols from c:/Users/Documents/Work/build/zephyr/zephyr.elf...
Resetting target
Resetting target
[New Thread 536881256]
[New Thread 536881008]
[New Thread 536880760]
[New Thread 536881504]
[Switching to Thread 536881256]

Thread 2 hit Temporary breakpoint 1, main () at ../src/main.c:24
24	{

Press Reset button on Debug Console. ==> Flash chip detected and I am able to get the device binding and do erase operation on Flash chip.

Logs:

[New Thread 536878976]
[New Thread 536878728]
[New Thread 536878480]
[New Thread 536880512]

Thread
3 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 536881008]
?? () at C:/Users/ncs/v1.8.0/zephyr/arch/arm/core/aarch32\cpu_idle.S:107
107		cpsie	i
Resetting target
[Switching to Thread 536881256]

Thread 2 hit Temporary breakpoint 2, main () at ../src/main.c:24
24	{

So, it seems it doesn't work when we Flash the board for the first time and also when we connect power to the board for the first time. After that it works always.

Thanks!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Fri, 06 May 2022 10:09:41 GMT

Hi,

[quote user="harshal034"]2. I tried with Ozone debugger (Run program in debug mode from Ozone) and it detects Flash chip every time. No error message (E: Device id 00 00 00 does not match config ef 40 14). However, I think this behavior is same as pressing Reset button on our board and it works with that too.[/quote]

Resetting and running in vscode should yield the same behavior as with Ozone. This seems strange to me that it only shows itself when you're using the cortex m debug in vscode, which leads me to think that there's something in the way that the plugin itself works that is causing the behavior.

In VScode, when entering debug mode, you should see this appearing:

If you click this image:

It should reset the target and run to main().

Could you confirm if the readout still fails even after a reset in the debugger?

Could you also share the debug console output?

[quote user="harshal034"]Is there a way we can try initializing the Flash device at the run time? Probably mimic what's happening during the boot time (using overlay content)?[/quote]

It is not an easy method to change the ordering, as the spi-nor is initialized before main in reached.

Kind regards,

Håkon

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Thu, 05 May 2022 18:05:05 GMT

Hi Hakon,

1. I tried with erase and flash, but it didn't help.

2. I tried with Ozone debugger (Run program in debug mode from Ozone) and it detects Flash chip every time. No error message (E: Device id 00 00 00 does not match config ef 40 14). However, I think this behavior is same as pressing Reset button on our board and it works with that too.

Issue is when I connect the power for the first time with the board (same as when I program the board using JTAG). Unless I press the reset button, it doesn't detect

I also tried one more thing: reboot the board using sys_reboot(SYS_REBOOT_COLD/WARM) after failing to get the Flash device binding. With this, after cold/warm boot, Flash chip is detected. First cycle after flash fails, but all cycles after sys_reboot are OK.

Is there a way we can try initializing the Flash device at the run time? Probably mimic what's happening during the boot time (using overlay content)?

Any other suggestions?

Thanks!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Wed, 04 May 2022 11:45:06 GMT

Hi,

[quote user="harshal034"]The issue is I see this error, whenever I program it using JTAG and JTAG resets the board, it doesn't detect the SPI. Also, if I disconnect the power of the board and reconnect it, first time, I see the similar issue. After pressing reset button on board, it works.[/quote]

thank you for clarifying!

Q1: Could you confirm if another debug reset puts the device into a good state? If yes, I think I have an idea on what can have happened here.

Q2: Could you try to run this command before flashing the device to see if the issue still appears?

nrfjprog -e

This will erase the nRF first.

If the device now behaves normal after initial programming, I believe it can be related to a reset before flashing the new program. If your old program is also present in flash, it will boot up for a small period of time and can leave the SPI-NOR flash in a mid-sequence operation before the nRF is re-flashed.

Kind regards,

Håkon

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Tue, 03 May 2022 18:32:42 GMT

Hi Hakon,

Thanks for keeping a tab on this.

Few points to consider:

I tried with slower speed 1M, and it didn't help. Our routing is not so long, Flash is right next to the BLE module.
I checked the datasheet of Flash and I believe the parameters in overlay are correct. Also, it works always when I reset the board using the reset button on the board.
The issue is I see this error, whenever I program it using JTAG and JTAG resets the board, it doesn't detect the SPI. Also, if I disconnect the power of the board and reconnect it, first time, I see the similar issue. After pressing reset button on board, it works.

Not sure what's going on here.

Is there a way we can init the external lash at run time (not from the overlay)? I may be reiterating but our usecase is to use external flash for OTA purpose.

Thanks!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Tue, 03 May 2022 13:24:29 GMT

Hi,

[quote user="harshal034"]E: Device id 00 00 00 does not match config ef 40 14[/quote]

This is an actual read out over the SPI bus, where as a part of the initialization of the SPI NOR flash device, the nRF reads out its ID and compares it to the one you've set in the .overlay file.

If this is all zero's, it means that the nRF is having issues reading your flash device. It can be many reasons why, for instance that the SPI speed is too high, creating issues for the GPIOs themselves to comply with the electrical specifications (ie. too much capacitance on the lines). This is easily testable by reducing the SPI speed.

Please use a oscilloscope to verify if the toggling of the SPI signal is reaching GND and VDD levels and providing a nice and clean signal.

As previously mentioned, your current speed is 8 MHz, which is too high if your routing is long. Reducing this to 1 MHz should help that scenario.

Have you for instance double checked the timing parameters that you provided in the .overlay files with the electrical specifications of the flash itself? Parameters " t-enter-dpd = <3000>;" and "t-exit-dpd = <30000>;" ?

Kind regards,

Håkon

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Mon, 02 May 2022 20:47:20 GMT

Hi Hakon,

Thanks for the info.

Using SPIM with "CONFIG_SOC_NRF52832_ALLOW_SPIM_DESPITE_PAN_58=y" did compile the code and I don't see earlier error during boot. However, it definitely fails write transactions with warning:

W: Transaction aborted since it would trigger nRF52832 PAN 58

So, as you suggest, we shouldn't be using SPIM but we will have to stick with the SPI driver.

Do you have any other suggestions to get rid off below error during boot:

E: Device id 00 00 00 does not match config ef 40 14

I am still able to communicate with the Flash using SPI APIs, but I do see this error every time I reboot the board now. Please note, we want this to work since we are planning to use External flash for OTA in our next stage of development.

Thanks!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Mon, 02 May 2022 12:00:56 GMT

Hi,

My apologies, you are right.

The issue stems from this erratum on the nRF52832:

https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev3/ERR/nRF52832/Rev3/latest/anomaly_832_58.html#anomaly_832_58

Which can be overridden by setting:

CONFIG_SOC_NRF52832_ALLOW_SPIM_DESPITE_PAN_58=y

However; this can be problematic if you run into the scenario as described in the erratum. You can use NRF_SPIM for testing purposes, to see if the same issue occurs, but I would not recommend using it in cases where you do not know if you can potentially receive only 1 byte over SPI.

Kind regards,

Håkon

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Fri, 29 Apr 2022 21:23:26 GMT

Hi Hakon,

Thanks for the guidance. However, deleting the build folder didn't help.

Changing compatible to nrf-spim still gives the linking error:

ncs\v1.8.0\zephyr\drivers\flash\spi_nor.c:1230: undefined reference to `__device_dts_ord_68'

Current data of prj.conf for SPI:

#for SPI

CONFIG_SPI=y

CONFIG_FLASH=y

CONFIG_SPI_NOR=y

CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096

Anything else that I can try?

Thanks!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Thu, 28 Apr 2022 09:12:11 GMT

Hi,

It should map this to the underlying driver that is used.

Did you delete the build folder and regenerate the project? It might not be that the build system was able to catch the change in the .overlay file.

Kind regards,

Håkon

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Tue, 26 Apr 2022 18:08:31 GMT

Hi Hakon,

I think changing to NRF_SPIM should resolve the problem but by changing that I am facing linking error:

ncs\v1.8.0\zephyr\drivers\flash\spi_nor.c:1230: undefined reference to `__device_dts_ord_68'

I believe I need to change the prj.conf as well for this, but not sure with what. This is what I've right now and works for NRF_SPI:

#for SPI

CONFIG_SPI=y

CONFIG_FLASH=y

CONFIG_SPI_NOR=y

CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096

Thanks!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Tue, 26 Apr 2022 07:26:09 GMT

Hi,

[quote user="harshal034"]

I tried changing the max freq to:

spi-max-frequency = <10000000>;

[/quote]

This is 10M, meaning that the SPIM will run at 8 MHz, which can be problematic if your routing includes longer traces.

Could you try switching from "NRF_SPI" to "NRF_SPIM" peripheral?

This is done by changing the "compatible" member in the .overlay:

compatible = "nordic,nrf-spim";

"NRF_SPI" is the older non-DMA capable peripheral.

Kind regards,

Håkon

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Mon, 25 Apr 2022 17:25:00 GMT

Hi Hakon,

I tried changing the max freq to:

spi-max-frequency = <10000000>;

But it didn't help. In our next stage of development, we are planning to use this external flash for OTA since our application size is more and we may not be able to fit it in internal flash. I am worried that, if we can't resolve this issue, it may create problem in OTA.

Is there anything else that I can check?

Thanks!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Mon, 25 Apr 2022 07:40:52 GMT

Hi,

[quote user="harshal034"]E: Device id 00 00 00 does not match config ef 40 14[/quote]

This means that the nRF isn't able to successfully communicate with the SPI-flash, as its trying to read its ID.

[quote user="harshal034"]

I've already shared my overlay file with you earlier.

I tried to look for some related issues on Nordic portal and found similar issue:

https://devzone.nordicsemi.com/f/nordic-q-a/75401/full_modem_update-failed-to-get-flash-device-mx25r64

https://devzone.nordicsemi.com/f/nordic-q-a/41888/device-id

https://devzone.nordicsemi.com/f/nordic-q-a/84742/zephyr-spi-nor-device-id-does-not-match/353015#353015

But what I am seeing is little weird since it works after reset but not immediately after flash+reset.

Tried adding "external_flash_pins_routing" in overlay but it says unknown label.

[/quote]

Most of these threads are related to other products, like the usage of the external flash on the nRF9160-DK, which requires specific handling to switch in the flash IC. On the nRF52-DK, you should just choose unused GPIOs and it should automatically try to communicate directly with your external device.

Could you try relaxing the max. frequency to 1MHz and see if this has any impact on the reliability?

Kind regards,

Håkon

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Fri, 22 Apr 2022 17:10:06 GMT

HI Hakon,

Thanks, adding CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096 in prj.conf is now giving me the correct PAGE SIZE. Here is how my updated prj.conf looks like for SPI:

CONFIG_SPI=y
CONFIG_FLASH=y
CONFIG_SPI_NOR=y
CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096

But this doesn't solved my problem of not detecting device for the first time. I just noticed that whenever I flash the chip it prints one extra error:

E: Device id 00 00 00 does not match config ef 40 14

and then it fails to detect the device. If I reset the device, using reset device, it works. In VS Code, I am using nrf52dk_nrf52832 for build.

I've already shared my overlay file with you earlier.

I tried to look for some related issues on Nordic portal and found similar issue:

https://devzone.nordicsemi.com/f/nordic-q-a/75401/full_modem_update-failed-to-get-flash-device-mx25r64

https://devzone.nordicsemi.com/f/nordic-q-a/41888/device-id

https://devzone.nordicsemi.com/f/nordic-q-a/84742/zephyr-spi-nor-device-id-does-not-match/353015#353015

But what I am seeing is little weird since it works after reset but not immediately after flash+reset.

Tried adding "external_flash_pins_routing" in overlay but it says unknown label.

&external_flash_pins_routing {
	status = "okay";
};

Is there anything else that I can try/configure?

Thanks!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Fri, 22 Apr 2022 08:21:02 GMT

[quote user="harshal034"]

Thank you very much for the reference. It helped and I've setup my flash with it. However, I've a couple of issues. Could you please guide?

1. Wrong page size info:

Page size I am getting is: 65536. For W25Q80DV, page size is 256 bytes. Chip size is correct.

[/quote]

I believe the erase sector on your flash is 4k aligned?

Could you try adding this config?

CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096

[quote user="harshal034"]

2. Fails to get the Device in first attempt.

When I flash the device for the first time using JTAG (I use VS Code so whenever I flash the program it resets the chip), it always fail to get the device.

[/quote]

Since it works after a reset, it indicates that everything else is running as intended, meaning that the physical setup etc is OK.

Could you try setting the page size to 4k and see if this issue still happens?

Kind regards,

Håkon

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Thu, 21 Apr 2022 18:26:54 GMT

Hi Hakon,

Thank you very much for the reference. It helped and I've setup my flash with it. However, I've a couple of issues. Could you please guide?

1. Wrong page size info:

Page size I am getting is: 65536. For W25Q80DV, page size is 256 bytes. Chip size is correct.

W25Q80DV SPI flash testing
==========================
Using W25Q80DV, chip size: 1048576 bytes (page: 65536)

2. Fails to get the Device in first attempt.

When I flash the device for the first time using JTAG (I use VS Code so whenever I flash the program it resets the chip), it always fail to get the device.

W25Q80DV SPI flash testing
==========================
SPI flash driver W25Q80DV was not found!

However, if I reset my device using reset button it gets the driver and can write/read the chip.

W25Q80DV SPI flash testing
==========================
Using W25Q80DV, chip size: 1048576 bytes (page: 65536)

Test 1: Flash erase
Flash erase succeeded!

Test 2: Flash write
Attempting to write 4 bytes
Data read matches data written. Good!!

Reference:

Overlayfile

arduino_spi: &spi2 {
	compatible = "nordic,nrf-spi";
	status = "okay";
	sck-pin = <27>;
	mosi-pin = <26>;
	miso-pin = <28>;
	cs-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;

	w25q80dv: w25q80dv@0 {
		compatible = "jedec,spi-nor";
		label = "W25Q80DV";
		reg = <0>;
		spi-max-frequency = <40000000>;
		//wp-gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
		//hold-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
		size = <0x800000>;
		has-dpd;
		t-enter-dpd = <3000>;
		t-exit-dpd = <30000>;
		jedec-id = [ef 40 14];
	};
};

SPI flash test Code: (ref: samples/drivers/spi_flash)

void spi_test_flash_api(void)
{
#define FLASH_NAME "W25Q80DV"
#define FLASH_TEST_REGION_OFFSET (0xff000)
#define FLASH_SECTOR_SIZE (4096)
#define FLASH_DEVICE DT_LABEL(DT_INST(0, jedec_spi_nor))

        const uint8_t expected[] = {0x55, 0xaa, 0x66, 0x99};
        const size_t len = sizeof(expected);
        uint8_t buf[sizeof(expected)];
        const struct device *flash_dev;
        int rc;
        
        const char *const spiName = "W25Q80DV";

        printk("\n" FLASH_NAME " SPI flash testing\n");

        printk("==========================\n");

        flash_dev = device_get_binding(FLASH_NAME);
        if (!flash_dev)
        {
                printk("SPI flash driver %s was not found!\n",
                       FLASH_NAME);
                return;
        }

#ifdef CONFIG_FLASH_PAGE_LAYOUT
        struct flash_pages_info pages_info;
        size_t page_count, chip_size;
        page_count = flash_get_page_count(flash_dev);
        (void)flash_get_page_info_by_idx(flash_dev, 0, &pages_info);
        chip_size = page_count * pages_info.size;
        printk("Using %s, chip size: %u bytes (page: %u)\n",
               FLASH_NAME, chip_size, pages_info.size);

#endif

        /* Write protection needs to be disabled before each write or
         * erase, since the flash component turns on write protection
         * automatically after completion of write and erase
         * operations.
         */
        printk("\nTest 1: Flash erase\n");

        rc = flash_erase(flash_dev, FLASH_TEST_REGION_OFFSET,
                         FLASH_SECTOR_SIZE);
        if (rc != 0)
        {
                printk("Flash erase failed! %d\n", rc);
        }
        else
        {
                printk("Flash erase succeeded!\n");
        }


        printk("\nTest 2: Flash write\n");
        printk("Attempting to write %zu bytes\n", len);
        rc = flash_write(flash_dev, FLASH_TEST_REGION_OFFSET, expected, len);
        if (rc != 0)
        {
                printk("Flash write failed! %d\n", rc);
                return;
        }

        memset(buf, 0, len);
        rc = flash_read(flash_dev, FLASH_TEST_REGION_OFFSET, buf, len);
        if (rc != 0)
        {
                printk("Flash read failed! %d\n", rc);
                return;
        }

        if (memcmp(expected, buf, len) == 0)
        {
                printk("Data read matches data written. Good!!\n");
        }
        else
        {
                const uint8_t *wp = expected;
                const uint8_t *rp = buf;
                const uint8_t *rpe = rp + len;

                printk("Data read does not match data written!!\n");
                while (rp < rpe)
                {
                        printk("%08x wrote %02x read %02x %s\n",
                               (uint32_t)(FLASH_TEST_REGION_OFFSET + (rp - buf)),
                               *wp, *rp, (*rp == *wp) ? "match" : "MISMATCH");
                        ++rp;
                        ++wp;
                }
        }
}

Thanks!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Wed, 20 Apr 2022 07:26:12 GMT

Hi,

Yes, you should if configured correctly.

I was able to find a smaller variant of this flash here:

https://github.com/nrfconnect/sdk-zephyr/blob/v2.7.99-ncs1-1/boards/arm/sparkfun_thing_plus_nrf9160/sparkfun_thing_plus_nrf9160_common.dts#L135-L155

You'll have to adjust the naming, size, and "jedec-id" to match yours.

Kind regards,

Håkon

RE: nr52832 + nRF Connect 1.8.0 + External Flash

embeddedER — Tue, 19 Apr 2022 16:46:51 GMT

Thanks, Hakon.

I just tested our Winbond Flash (W25Q80DV) over SPI with basic read and write using SPI APIs. As I check the datasheet, W25Q80DV supports the JEDEC, does that mean we should be able to use the flash APIs if we configure overlay and conf files as you suggested?

Thanks!

RE: nr52832 + nRF Connect 1.8.0 + External Flash

Håkon Alseth — Tue, 19 Apr 2022 13:49:08 GMT

Hi,

You can try with the zephyr/samples/drivers/spi_flash for instance.

You will need to add a $my_board.conf file and a $my_board.overlay file. I'm assuming that you're using the nRF52-DK as a basis here.

The nrf52dk_nrf52832.conf should hold:

CONFIG_SPI_NOR=y

And the .overlay should hold your spi configuration and the spi-nor device that you have.

Here's an example on how the nRF9160-DK has setup a SPI-NOR flash overlay:

https://github.com/nrfconnect/sdk-zephyr/blob/v2.7.99-ncs1-1/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160_common_0_14_0.dtsi#L42-L65

Pin numbering, device name, and spi instance will differ from your wanted setting.

Kind regards,

Håkon