Adding an SPI device to the nrf9151 feather

marjonz

I have been at it just trying to get the thing to compile. I have the following:

in circuitdojo_feather_nrf9151_common-pinctrl.dtsi file, I added:

	spi2_default: spi2_default {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 19)>,
			        <NRF_PSEL(SPIM_MOSI, 0, 21)>,
			        <NRF_PSEL(SPIM_MISO, 0, 22)>;
		};
	};

	spi2_sleep: spi2_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 19)>,
			        <NRF_PSEL(SPIM_MOSI, 0, 21)>,
			        <NRF_PSEL(SPIM_MISO, 0, 22)>;
			low-power-enable;
		};
	};

in circuitdojo_feather_nrf9151_common.dtsi file:

&spi2 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    
    /* Use default pin configuration from the board */
    pinctrl-0 = <&spi2_default>;
    pinctrl-1 = <&spi2_sleep>;
    pinctrl-names = "default", "sleep";

    my_spi_device: my_spi_device@0 {
        compatible = "vendor,my-device";
        reg = <0>;
        spi-max-frequency = <4000000>;
        label = "MYDEVICE_SPI";

        // --- Additional GPIOs defined here ---
        line1-gpios   = <&gpio0 13 GPIO_ACTIVE_LOW>;
        line2-gpios    = <&gpio0 14 GPIO_ACTIVE_LOW>;
        line2-gpios  = <&gpio0 15 GPIO_ACTIVE_LOW>;
        cs-gpios    = <&gpio0 16 GPIO_ACTIVE_LOW>;
    };
};

In my C file, I reference the SPI device via:

#define SPI_MASTER_NODE_ID DT_NODELABEL(my_spi_device)
static const struct device *spi_dev = DEVICE_DT_GET(DT_BUS(SPI_MASTER_NODE_ID));
static const struct spi_dt_spec spi = 
    SPI_DT_SPEC_GET(
        SPI_MASTER_NODE_ID, 
        (SPI_OP_MODE_MASTER | SPI_WORD_SET(8) | SPI_TRANSFER_MSB | SPI_MODE_CPOL | SPI_MODE_CPHA), 
        0
    );

But I find that in the device_generated.h file, it doesn’t generate the property for max_frequency for my device.
So the compilation fails:

C:/nrf_workspace/fleetpin/nfed/fleetpin/build/fleetpin/zephyr/include/generated/zephyr/devicetree_generated.h:12740:38: error: 'DT_N_S_soc_S_peripheral_40000000_S_spi_b000_S_my_spi_device_0_P_spi_max_
frequency' undeclared here (not in a function); did you mean 'DT_N_S_soc_S_peripheral_40000000_S_spi_b000_S_w25q128jv_0_P_spi_max_frequency'?
12740 | #define DT_N_NODELABEL_my_spi_device DT_N_S_soc_S_peripheral_40000000_S_spi_a000_S_my_spi_device_0

marjonz

I found my missing bit, I had to create a binding (yaml) for it, and put in the zephyr/dts/bindings, to be referenced by the build system for generating the macros. I’m surprised there is no “generic” spi device type that could be used for any SPI slave device when generating the overlay.

AchimKraus

Let me recommend to use project specific board overlays for these changes instead of adapting the provided board files directly.

As example for using SPI you may check the usage of the external flash. Beside of the 3 SPI line in pinctrl, the CS pin are provided in

cs-gpios = <&gpio0 n GPIO_ACTIVE_LOW >;

at the SPI node level. If more then one SPI device is on that bus, provide the CS as list

cs-gpios = <&gpio0 n1 GPIO_ACTIVE_LOW >, <&gpio0 n2 GPIO_ACTIVE_LOW >;

the order must be the same as the order of the sub-nodes of that SPI bus.

And maybe, I’m not sure, if you want to use the nRF9151 as bus master or device. The external flash uses the nRF9151 as SPI master.

marjonz

AchimKraus Is it not recommended to use a separate SPI for this purpose? SPI1 seems unused, based on the generated device tree, SPI2 and SPI3 are already used (one I understand is for the flash chip, which I’d rather not touch if possible)

MarkoPura

Hi folks, I’m looking for help enabling an additional SPI bus on the Feather header pins on the nRF9151 Feather.

On this board I’m already using:

uart0 (console)
i2c2 (PMIC / sensors)
spi3 (external flash)

spi3 is dedicated to the onboard external flash, so I’m trying to enable a second SPI controller (spi1) and route it to the Feather header pins (SCK/MOSI/MISO on P0.20/P0.21/P0.22). I’m doing this via my application overlay (without modifying upstream board files). I also disable uart1 (not used).

Overlay snippet:

&uart1 {
    status = "disabled";
};

&spi1 {
    status = "okay";
    cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>,
               <&gpio0 18 GPIO_ACTIVE_LOW>;
    pinctrl-0 = <&spi1_default>;
    pinctrl-1 = <&spi1_sleep>;
    pinctrl-names = "default", "sleep";
};

&pinctrl {
    spi1_default: spi1_default {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 0, 20)>,
                    <NRF_PSEL(SPIM_MOSI, 0, 21)>,
                    <NRF_PSEL(SPIM_MISO, 0, 22)>;
        };
    };

    spi1_sleep: spi1_sleep {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 0, 20)>,
                    <NRF_PSEL(SPIM_MOSI, 0, 21)>,
                    <NRF_PSEL(SPIM_MISO, 0, 22)>;
            low-power-enable;
        };
    };
};

This builds fine and spi1 shows up as enabled in the generated zephyr.dts, but at runtime the device hits a bus fault immediately after MCUboot chainloads the application.

Console output:

*** Booting MCUboot v2.1.0-dev-9b4ae4cbc9e2 ***
*** Using nRF Connect SDK v3.1.1-e2a97fe2578a ***
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Image version: v0.0.0
[00:00:00.252,105] <err> os: ***** BUS FAULT *****
[00:00:00.252,136] <err> os:   Precise data bus error
[00:00:00.252,136] <err> os:   BFAR Address: 0x0
[00:00:00.252,166] <err> os: r0/a1:  0x000259f8  r1/a2:  0x00025a04  r2/a3:  0x40009000
[00:00:00.252,166] <err> os: r3/a4:  0x00000014 r12/ip:  0x40842500 r14/lr:  0xfffcf8f0
[00:00:00.252,166] <err> os:  xpsr:  0x01000000
[00:00:00.252,197] <err> os: Faulting instruction address (r15/pc): 0x0001c9f4
[00:00:00.252,227] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:00.252,258] <err> os: Current thread: 0x2000cc98 (unknown)
[00:00:00.315,063] <err> os: Halting system

Has anyone seen similar behavior when enabling a second SPI instance on the nRF9151 feather? Enabling spi1 in the application overlay consistently causes a bus fault during early boot, and I’m trying to understand what I might be missing in terms of configuration or platform setup.

Any guidance or pointers would be greatly appreciated.

marjonz

MarkoPura This is exactly what I’m trying to do too. Happy to add to this thread any findings please? And I will do the same. Was about to test my changes on the HW, but I guess I know now what to expect.

jaredwolff

@MarkoPura do you have this in your config?

# TFM fix
CONFIG_TFM_LOG_LEVEL_SILENCE=y

The TFM initializes UART1 if you don’t have that in your prj.conf. I believe that is what would cause what you’re seeing since you’re trying to use SPI1.

@marjonz you can take a look at what @MarkoPura. It’s a good example of an overlay. You would want to put it in /<your app>/boards/circuitdojo_feather_nrf9151_ns.overlay

marjonz

jaredwolff Thank you @jaredwolff , I will do the change and confirm tomorrow.

marjonz

jaredwolff I had an additional overlay named mydevice.overlay and I just added it to the additional overlay field in the Configuration when editing config, is that wrong?

marjonz

jaredwolff I have tried to do as you mentioned, here’s my overlay:

&pinctrl {
    spi1_default: spi1_default {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 19)>,
			        <NRF_PSEL(SPIM_MOSI, 0, 21)>,
			        <NRF_PSEL(SPIM_MISO, 0, 22)>;
		};
	};

	spi1_sleep: spi1_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 19)>,
			        <NRF_PSEL(SPIM_MOSI, 0, 21)>,
			        <NRF_PSEL(SPIM_MISO, 0, 22)>;
			low-power-enable;
		};
	};
};

&uart1 {
    status = "disabled";
};

&spi1 {
    compatible = "nordic,nrf-spim";
    status = "okay";
	pinctrl-0 = <&spi1_default>;
    pinctrl-1 = <&spi1_sleep>;
    pinctrl-names = "default", "sleep";
    epaper_device: epaper_device@0 {
        compatible = "waveshare,epaper-spi-device";
        reg = <0>;
		spi-max-frequency = <4000000>;

        // --- Additional GPIOs defined here ---
        rst-gpios   = <&gpio0 13 GPIO_ACTIVE_LOW>;
        data-command-gpios    = <&gpio0 14 GPIO_ACTIVE_LOW>;
        busy-gpios  = <&gpio0 15 GPIO_ACTIVE_LOW>;
		chip-select-gpios  = <&gpio0 16 GPIO_ACTIVE_LOW>;
        pwr-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
    };
};

but based off the schematic, I can’t find P0.20 coming out of the header? the signal names on the microprocessor sheet, doesn’t seem to match the signal names on the header sheet, so I am assuming it is the same pins as in the 9160 which had matching signals.
so my SCK is on P0.19, MOSI is on P0.21, MISO is on P0.22, which are all available (?) on the header.

I’ve scoped the pins directly to a logic analyzer, and non of them seem to be toggling as I expect them to. no clock or mosi output.

What else could I be missing please?

MarkoPura

Thanks @jaredwolff, that solved it. I had a feeling it was TF-M related, but couldn’t put my finger on the exact cause.

AchimKraus

marjonz Is it not recommended to use a separate SPI for this purpose

That depends more on your requirements. I don’t know them, therefore didn’t recommend, which SPI should be used.
What I recommended and is pretty common, is to use overlay instead of editing/changing the board files themself.

There are then two options to do so:

(Recommended)
Use an overlay in the “boards” folder with that same name as the board your using, e.g. “boards/circuitdojo_feather_nrf9151_ns.overlay”,

(Alternative, maybe when a couple of sub-variants are used)
Use an overlay in the project folder, e.g. “mydevice.overlay” and add that overlay to the build arguments with west (NCS 2.9.2), e.g.

west build -b circuitdojo_feather_nrf9151/nrf9151/ns --pristine -- -DDTC_OVERLAY_FILE="mydevice.overlay"

You may even combine both, but that requires in my experience then either

west build -b circuitdojo_feather_nrf9151/nrf9151/ns --pristine -- -DDTC_OVERLAY_FILE="boards/circuitdojo_feather_nrf9151_ns.overlay;mydevice.overlay"

or to include the boards overlay in “mydevice.overlay”

#include "boards/circuitdojo_feather_nrf9160_ns.overlay"

hope that helps about the overlay.

marjonz

AchimKraus Thank you @AchimKraus , I ended up going with your very last suggestion:

or to include the boards overlay in “mydevice.overlay”

My question lies in the definition of the device, I had to create an entry for my device and place it zephyr/dts/bindings/spi as a yaml file, this was so the build system picked up the new properties (5 or so additional GPIO lines associated with my device on top of the SPI lines), otherwise, the build system wasn’t picking my device and the additional properties wasn’t showing up in devicetree_generated.h.

Is this the correct way, or should I create that new yaml file in my project folder? I just don’t know how the build system will pick it up if it was in my project folder, as it seems to only parse the zephyr (upstream project of nRF) when doing the build and searching for the possible devices.

AchimKraus

marjonz Is this the correct way, or should I create that new yaml file in my project folder?

I used to put the bindings in the project folder, e.g. “<prj>/dts/bindings/<type>/<dev>.yaml”.

marjonz

Thank you. I’ve done that. I’m just fixing the remaining stuff on my driver port for my device, and soldered the header pins to the feather, will wire up my end device to the feather today. Thank you very much for the guidance and responses.

marjonz

I reviewed the schematic, so in the 9151, there is not P0.19 exposed, but P0.20. I’m changing it in my code now and retesting.

jaredwolff

FYI: If you’re using the CD Zephyr Tools VSCode plugin I’ve added the ability to pull in both dts and conf overlays which use the -DDTC_OVERLAY_FILE and -DEXTRA_CONF_FILE under the hood. Latest version is v0.5.7

marjonz

jaredwolff i am using what was recommended on the CD Feather 9151 page, which was the nRF Connect plug in I think. The page seems different now, I am installing the CD Zephyr Tools now and will try that.

EDIT: Installed it and when running it complains of “git” being missing, yet I have it installed and in path, i.e. opening a Terminal and running git --version yields git version 2.47.1.windows.2
I also noticed, I’ll need to sort out my project tree again.
I might continue with the nRF Connect plugin for now and revisit your plug in later.

marjonz

I am seriously struggling to get anything out of the SPI1 bus, MOSI and SCLK are not responding despite the calls to

#define DEVICE_NODE_ID DT_NODELABEL(my_device)
static const struct device *spi_dev = DEVICE_DT_GET(DT_BUS(DEVICE_NODE_ID));
static const struct spi_dt_spec spi = 
    SPI_DT_SPEC_GET(
        DEVICE_NODE_ID, 
        (SPI_OP_MODE_MASTER | SPI_WORD_SET(8) | SPI_TRANSFER_MSB),  // SPI MODE0
        0
    );

#define TX_BUFFER_SIZE 120 
static uint8_t tx_buf_data[TX_BUFFER_SIZE] = { 0 };
static struct spi_buf tx_buf = 
{
    .buf = tx_buf_data,
    .len = sizeof(tx_buf_data),
};

spi_write_dt(&spi, &tx); // Nothing comes out of the bus, scoped with logic analyzer

The overlay looks like this (and I can see in the device tree plugin that the fields are populated correctly):

&pinctrl {
    spi1_default: spi1_default {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 20)>,
			        <NRF_PSEL(SPIM_MOSI, 0, 21)>,
			        <NRF_PSEL(SPIM_MISO, 0, 22)>;
		};
	};

	spi1_sleep: spi1_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 20)>,
			        <NRF_PSEL(SPIM_MOSI, 0, 21)>,
			        <NRF_PSEL(SPIM_MISO, 0, 22)>;
			low-power-enable;
		};
	};
};

&uart1 {
    status = "disabled";
};

&spi1 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    // cs-gpios  = <&gpio0 16 GPIO_ACTIVE_LOW>;
    pinctrl-0 = <&spi1_default>;
    pinctrl-1 = <&spi1_sleep>;
    pinctrl-names = "default", "sleep";
    my_device: my_device@0 {
        compatible = "manufacturer,my-spi-device";
        reg = <0>;
		spi-max-frequency = <4000000>;

        // --- Additional GPIOs defined here ---
        rst-gpios   = <&gpio0 13 GPIO_ACTIVE_LOW>;
        data-command-gpios    = <&gpio0 14 GPIO_ACTIVE_LOW>;
        busy-gpios  = <&gpio0 15 GPIO_ACTIVE_LOW>;
		chip-select-gpios  = <&gpio0 16 GPIO_ACTIVE_LOW>;
        pwr-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
    };
};

marjonz

Nevermind, it seems to work now. Please close this thread