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