Using External NOR Flash on SDK3.1

[DamoL]

Hello, 

I am in the process of upgrading our product from SDK 1.6.1 to the latest SDK (3.1 at time of writing). I am quite lost on the external flash through using devicetree. I managed it in 1.6.1, but it was a long time ago and things seem a little different. I have also looked on other questions here and they either aren't describing my issue or they are older SDKs with irrelevant information. 

We have a board based on the nrf9160DK, which I have always just used an overlay file to note the changes, and disable things that aren't needed. That has worked for everything else so far. 

From the samples, it looks like I just need to have the SPI enabled, and the have the driver selected, and in the configuration file I basically just need CONFIG_FLASH=y to enable it to work. 

I am pretty sure I have the overlay file correct, it's pretty much the same in SDK1.6.1, except we now use pinctrl. 

&pinctrl {
	uart3_default: uart3_default {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 31)>, <NRF_PSEL(UART_RX, 0, 30)>;
		};
	};

	uart3_sleep: uart3_sleep {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 31)>;
		};
	};

	spi1_default: spi1_default {
		group1 {
			psels = <NRF_PSEL(SPIM_MISO, 0, 4)>,
					<NRF_PSEL(SPIM_MOSI, 0, 3)>,
					<NRF_PSEL(SPIM_SCK, 0, 2)>;
		};
	};

	spi1_sleep: spi1_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_MISO, 0, 4)>;
		};
	};
};

&spi1 {
	compatible = "nordic,nrf-spim";
	status = "okay";
	pinctrl-0 = <&spi1_default>;
	pinctrl-1 = <&spi1_sleep>;
	pinctrl-names = "default", "sleep";
	cs-gpios = < &gpio0 8 GPIO_ACTIVE_LOW >;	//22003 HW P0.08, 21014 HW P0.01
	mx25r64: mx25r6435f@0 {
		compatible = "jedec,spi-nor";
		reg = < 0x0 >;
		spi-max-frequency = <DT_FREQ_M(8)>;
		label = "MX25R64_2";
		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 = < 0x4000000 >;
		has-dpd;
		t-enter-dpd = < 0x2710 >;
		t-exit-dpd = < 0x88b8 >;
	};
};

With the SPI_FLASH sample, I can get this to build, but as soon as I try and debug it, there is an exception in the pre-kernel TF-M ns boot phase. It gets trapped in 

tfm_ns_fault_handler_callback(), which I assume means there is some problem with doing something in the secure/non-secure parts of the code. 

In my other project that I am working on, as soon as I add CONFIG_FLASH, I find the exact same thing happens, so I think that is where the problem lies. I am not totally sure if there are other configuration macros I need, as most of them seem to relate to DFU, and allowing booting from an image on an external flash. 

To be clear, I am using external flash to read/write my own data, I just want the devicetree to sort out the jedec driver, so I can just call functions like flash_read()

Thanks in advance, 

Damien

[Hakon]

Hello,

We have a board based on the nrf9160DK, which I have always just used an overlay file to note the changes, and disable things that aren't needed. That has worked for everything else so far. 

So you have a custom board, and your code fails on newer SDK versions. Does it also fail on the DK? If it also fails on the DK, could you share a minimal sample code to reproduce the issue?

[DamoL]

Well I wouldn't have expected it to, as it uses different pin numbers for peripherals. Also, you can't build it with just the DK alone, you need an overlay file to enable the external flash. 

I was just using the SPI_FLASH sample code for the test originally, then when I tried it on my other project, it didn't matter what was in the main, as soon as I add CONFIG_FLASH, it fails to ever get to main(), so I am sure it is an issue in either the devicetree or the conf. 

I don't actually have a 9160DK to hand. I do have a 9161DK, but that uses a different external flash I believe. I had thought about creating a new board but I remember trying that before and I basically just had to copy all the defconfig /partition files from the DK anyway, so it was only really no different than using an overlay that changed some of the pin numbers.  

[Hakon]

DamoL said:

I don't actually have a 9160DK to hand. I do have a 9161DK, but that uses a different external flash I believe.

If you don't mind you can try to reproduce this on the nrf9161 DK. Since I don't have your custom board it is kinda difficult for me to guess what is going on on your board. Then we will also rule out if the problem is related to that particular flash chip, or if the driver is set up incorrectly somehow.

[DamoL]

Ah, I was in the middle of commenting when you posted this..

I have found a solution, maybe you can help explain what is going on here. I noticed in nrf9160dk_nrf9160_ns.dts file, it states TF-M uses UART1, so it is disabled

/* Disable UART1, because it is used by default in TF-M */
&uart1 {
	status = "disabled";
};

As a test, I just changed my spi1 configuration in the overlay to spi2, and it finds it way to main.c. 

Does this mean I can't use any peripheral with suffix - 1 (spi1 / i2c1 etc) because TF-M uses uart1?

I am sure that isn't the case, but I can't see how you get around that.

Thanks, 

Damien

[Hakon]

DamoL said:

Does this mean I can't use any peripheral with suffix - 1 (spi1 / i2c1 etc) because TF-M uses uart1?

I don't think so, but can you post the zephyr.dts file found in the build folder so I can check?

[DamoL]

Sure, here you go

3051.zephyr.dts

Thanks, 

Damien

[Hakon]

Maybe the problem is that in TFM uart1 is enabled, and that is causing problems since spi1 is also enabled. If you want you can disable TFM logging and then enable spi1 if you want to test if this is actually happening. You can set

CONFIG_TFM_LOG_LEVEL_SILENCE=y