We are trying to connect the nrf9160 to a spi flash device. we have a custom board with the following pins connected:
sck: 27
mosi: 28
miso: 30
cs: 29
wp: 31
reset: 26
For the testing, we are using the drivers/spi_flash sample of zephyr.
we use the following overlay:
&spi3 {
compatible = "nordic,nrf-spim";
status = "okay";
sck-pin = <27>;
mosi-pin = <28>;
miso-pin = <30>;
cs-gpios = <&gpio0 29 GPIO_ACTIVE_LOW>;
s25fl128l: s25fl128l@0 {
compatible = "jedec,spi-nor";
label = "S25FL128L";
reg = <0>;
jedec-id = [01 60 18];
spi-max-frequency = <200000>;
wp-gpios = <&gpio0 31 GPIO_ACTIVE_LOW>;
reset-gpios = <&gpio0 26 GPIO_ACTIVE_LOW>;
size = <0x4000000>;
has-dpd;
t-enter-dpd = <4000>;
t-exit-dpd = <25000>;
has-be32k;
};
};
&uart0 {
status = "disabled";
current-speed = <115200>;
tx-pin = <25>;
rx-pin = <24>;
rts-pin = <23>;
cts-pin = <22>;
};
&i2c2 {
compatible = "nordic,nrf-twim";
status = "disabled";
sda-pin = <21>;
scl-pin = <20>;
};
We have disabled the uart and i2s that use these pins in the default design.
To communicate with the nrf9160, we use RTT. We use the following configuration:
CONFIG_STDOUT_CONSOLE=y CONFIG_FLASH=y CONFIG_SPI=y # Enable printing CONFIG_SERIAL=y CONFIG_PRINTK=y CONFIG_CONSOLE=y CONFIG_STDOUT_CONSOLE=y # Enable log CONFIG_LOG=y # Enable rtt CONFIG_USE_SEGGER_RTT=y # Enable rtt shell CONFIG_SHELL=y CONFIG_SHELL_BACKEND_RTT=y # Switch console to rtt, for print statements CONFIG_UART_CONSOLE=n CONFIG_RTT_CONSOLE=y
The sample prints the following code:
JEDEC SPI-NOR SPI flash testing ========================== SPI flash driver S25FL128L was not found!
When checking the signals with a scope, we noticed that the chip select (pin 29) does not have its expected behavior. Instead of becoming active during spi commands, continually switches between high and low, and looks like some sort of serial data.
We have tried to toggle the pin as an gpio, but are unable to control this pin.
We have tried a hello_world sample (without spi/flash), and notice the same behavior on pin 29.
Since our code does not use pin 29 for anything except chip select, we suspect that another program (bootloader? SPM?) configures the pin as an uart, preventing us the use it as a chip select.
Do you know if this assumption is correct, and how we could test and fix this? Or is there another solution to the problem?
