nRF5340 SPI Master Sample Code

RE: nRF5340 SPI Master Sample Code

Susheel Nuguru — Sun, 30 Jul 2023 13:15:55 GMT

[quote user="0x00"]

- The MOSI goes HIGH before that the CS goes down. The MOSI goes HIGH after the 8th Clock cycle.

- The MOSI has a strange behavior in the first 2 clock cycle

[/quote]

It looks to me that it could be an issue with the pull configuration of the SPI pins. We have seem that if the pin pull configuration is not configured correctly then it can be pulled high or low from the sensor.

[quote user="0x00"]Can the SPIM driver used into the fujitsu_fram be used to implement a comunication with the MCP3562?[/quote]

Not sure. We haven't tried it yet. But our SPI peripheral is known to work with thousands of sensors without any issue. So as long as the MCP3562 obeys the SPI specification, I do not see why it should not work. That said, I do not see anyone else trying this combination with our SPI. I would also not rule out any custom board related issues with cross talks effects as well.

RE: nRF5340 SPI Master Sample Code

Simonr — Tue, 25 Jul 2023 11:59:35 GMT

Due to the summer vacation period we are currently understaffed, so delayed replies must be expected. I am sorry about any inconvenience this might cause.

I'm sorry, but I will need to reassign this case to another engineer that knows more about this subject than myself. Hopefully they'll get back to you tomorrow.

Best regards,

Simon

RE: nRF5340 SPI Master Sample Code

0x00 — Fri, 21 Jul 2023 06:30:27 GMT

Morning,

I have a dubt..

Can the SPIM driver used into the fujitsu_fram be used to implement a comunication with the MCP3562?

I'm asking that because when I try to configure teh example to my need (8bit CMD)... something does not work properly.

int mcp3562_maccess(const struct device *spi, struct spi_config *spi_cfg, 
					uint8_t cmd, uint8_t addr, void *data, size_t len)
{
	uint8_t access[1];
	struct spi_buf bufs[] = {
		{
			.buf = access,
		},
		{
			.buf = data,
			.len = len
		}
	};
	struct spi_buf_set tx = {
		.buffers = bufs
	};

	access[0] = (cmd | (addr << 2));

	if (cmd == MCP3562_WRITE_COMMAND || cmd == MCP3562_SREAD_DATA_COMMAND) {
		//access[1] = 0x00;

		bufs[0].len = 1;
		tx.count = 1;

		if (cmd == MCP3562_SREAD_DATA_COMMAND) {
			struct spi_buf_set rx = {
				.buffers = bufs,
				.count = 2
			};

			return spi_transceive(spi, spi_cfg, &tx, &rx);
		}
	} else {
		tx.count = 1;
	}

	return mcp3562_write_bytes(spi, spi_cfg, addr, &tx, len);

}

in access function I modified:

- the array siize from 3 to 1 (because the CMD include the address).

- The bufs[0].len to 1 (because my array contains only 1 command 1 byte)

- The tx.count to 1 (because I need to transmit 1 byte)

When I do this the result is the screenshot below

The read operation of the register 0x00, in this case, forsees the writing of a command byte "01000001".

but:

- The MOSI goes HIGH before that the CS goes down. The MOSI goes HIGH after the 8th Clock cycle.

- The MOSI has a strange behavior in the first 2 clock cycle

- Obviously.. the MISO is silent.

What I'm wrong?

Many Thanks.

RE: nRF5340 SPI Master Sample Code

0x00 — Thu, 20 Jul 2023 14:02:00 GMT

Hi,

I redefined the overlay file as follow:

&spi4 {
    cs-gpios = <&gpio1 12 (GPIO_ACTIVE_LOW)>;
};

&pinctrl {
	spi_master_default: spi_master_default {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 1, 15)>,
				<NRF_PSEL(SPIM_MISO, 1, 14)>,
				<NRF_PSEL(SPIM_MOSI, 1, 13)>;
		};
	};

	spi_master_sleep: spi_master_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 1, 15)>,
				<NRF_PSEL(SPIM_MISO, 1, 14)>,
				<NRF_PSEL(SPIM_MOSI, 1, 13)>;
			low-power-enable;
		};
	};
};

my_spi_master: &spi4 {
    //label ="MYSPI";
    status = "okay";
	compatible = "nordic,nrf-spim";
	status = "okay";
	pinctrl-0 = <&spi_master_default>;
	pinctrl-1 = <&spi_master_sleep>;
	pinctrl-names = "default", "sleep";
	cs-gpios = <&gpio0 26 GPIO_ACTIVE_LOW>, <&gpio1 12 GPIO_ACTIVE_LOW>;
    mcp3562a: spi-device@0 {
        //spi-max-frequency = <8000000>;
		reg = <0>;
	};
	mcp3562b: spi-device@1 {
        //spi-max-frequency = <8000000>;
		reg = <1>;
	};
};

And I was able to see the interface that moves the signals.

But somenthing don't seems to be correct.

In the screenshot above I'm running the original example fujitsu_fram, the fw is tryng to do a read/write op (stated in the code attached.. but seems to me a Write Op) a 0xAE (10101110):

/* Do one-byte read/write */
		data[0] = 0xAE;
		err = write_bytes(spi, &spi_cfg, 0x00, data, 1);
		if (err) {
			printk("Error writing to FRAM! error code (%d)\n", err);
			return;
		} else {
			printk("Wrote 0xAE to address 0x00.\n");
		}

the write CMD should be the first eight bit (0x01). Followed by 16bit ADDR. Therefore the 0xAE pattern.

The transmission seems ok (since i run it on the Ublox board that hasn't the memory unfortunatly we can't see an answer on the MISO signal).

What it's NOK is that on the MISO line we can see a shadow of the MOSI one (could be a crosstalk between the cables that i used for the oscilloscope.

When I run my variations (Enabling the TESTAPP define on the top of the main file) I try to read of the CONFIG0 (0x01) register of the MCP3562 (ADC), instead of the Fujitsu Memory.

while(1){ //TEST LOOP
            data[0] = 0x00;
            err = mcp3562_read_bytes(spi, &spi_cfg, 0x01, data, 1);
            if (err) {
                printk("Error reading from ADC! error code (%d)\n", err);
                //return;
            } else {
                printk("Read 0x%X from address 0x01.\n", data[0]);
            }
        }

And the below screeshot with the waveforms:

I can see some strange things. In particular the metastable value of the first "1" bit.

I tought that the way to source CMDs to my device is different respect the memory.

If I want to read the CONFIG0 register I need to send the command 01000101 (where CMD[7:6] is Hard Code of the device, CMD[5:2] is the Address of the register and the CMD[1:0] is the Read Command). The CMD includes all informations required.

I tryed to modfy the code to fit the constraints but below another screenshot with the results:

It's not clear to me:
- Why at the start of the word there's a metastable value?

- Why the first "1" (second bit) is, let me say, "castrated".

- Why before and after the CMD the MOSI signal is HIGH.

Another opened point is that the ADC registers has a depth of 8bits (otherwise the sampled datas can be 8/24/32 bits) . How the driver is thougth to manage this situations?

My Code attached.

devzone.nordicsemi.com/.../20230720_2D00_my_5F00_spi_5F00_fujitsu_5F00_fram_2D00_B.zip

many Thanks & Best Regards

RE: nRF5340 SPI Master Sample Code

Simonr — Thu, 20 Jul 2023 06:55:51 GMT

With "the same behavior", I assume you're still seeing these multiple "error: '__device_dts_ord_109' undeclared here (not in a function);" messages, correct? If so I'd recommend checking out this super helpful blog post by Golioth: https://blog.golioth.io/zephyr-devicetree-troubleshooting-generated-files/

If not, please try to describe what behavior you're seeing, as I'm a little confused as to what the issue actually is here.

Best regards,

Simon

RE: nRF5340 SPI Master Sample Code

0x00 — Tue, 18 Jul 2023 09:06:48 GMT

Hi,

Actually with the spi_fujitsu_fram example & 53540DK BSP I can see the SCK & MOSI Signals.

The problem is the CSn signal that is stucked to the High Level (3.3V).

For this signal I have a definition in the nrf5340_cpuapp_common.dts

arduino_spi: &spi4 {
	compatible = "nordic,nrf-spim";
	status = "okay";
	cs-gpios = <&arduino_header 16 GPIO_ACTIVE_LOW>; /* D10 */
	pinctrl-0 = <&spi4_default>;
	pinctrl-1 = <&spi4_sleep>;
	pinctrl-names = "default", "sleep";
};

but this seems not to be enough (because in the Device Tree Visualizer the pin does not appear).

I forced the following definition into the nrf5340dk_nrf5340_cpuapp.overlay.

&spi4 {
    cs-gpios = <&gpio1 12 (GPIO_ACTIVE_LOW)>;
};

With this I can see the CSn pin allocated on the wanted pin. Unfortunatly this don't seems to be enough.

Suggestions?

Many Thanks for your support & Kindness.

Best Regards

RE: nRF5340 SPI Master Sample Code

0x00 — Mon, 17 Jul 2023 15:03:01 GMT

Also with the last example the behaviour is the same.

No signals on the EVK connector.

devzone.nordicsemi.com/.../ncs_2D00_spi_2D00_master_2D00_slave_2D00_example.zip

I tested with the Ublox Nora 106B EVK (clone of the 5340DK).

This is very strange .. I don't believe that the same behavior can affect 3x different projects.

for the ncs-spi-master-slave-example projec & 5340DK board:

For the spi_fujitsu_fram prohject & Ublox NORA 106B EVK:

The Non-Blocking SPI is the same.

Actually I'm blocked and don't understand what the problem is.

Suggestions?

Many Thanks & Best Regards

RE: nRF5340 SPI Master Sample Code

0x00 — Mon, 17 Jul 2023 13:40:06 GMT

Hi,

not relevant progress... unfortunatly.

Actually I built the spi_fujitsu_fram... but I can't see any signal in my oscilloscope.

The board that I'm using its the UBLOX NORA 106 (clone of the 5340DK).

Attached the actual code.

devzone.nordicsemi.com/.../my_5F00_spi_5F00_fujitsu_5F00_fram.zip

I don't understand what I'm doing wrong..

The CSn signal was mapped using the Overlay file because it was not included during the SPI4 configuration.

Abnother example based on NoN-Blocking NRFX driver seems to have the same behavior (Files attached).

devzone.nordicsemi.com/.../selcom_5F00_corrosion_5F00_buddy_5F00_230714_5F00_SPI_5F00_NON_5F00_BLOCKING.7z

In the last example If I put a breakpoint on the row 540 of the main.c file (where the transfer should be happened) I not able to see the signals on the pins GPIO.1.12/13/14/15.

Many Thanks

RE: nRF5340 SPI Master Sample Code

Simonr — Mon, 17 Jul 2023 12:39:32 GMT

We have a few unofficial sample projects on SPIM available made for the nRF5x series devices specifically. An SPIM and SPIS sample using the Async. drivers in Zephyr is available here: https://github.com/too1/ncs-spi-master-slave-example. We also have a somewhat old SPIM sample here for the nRF53 and nRF91.

Have you had any progress over the weekend? Do you have any specific issues as of now that I might help you answer?

Best regards,

Simon

RE: nRF5340 SPI Master Sample Code

0x00 — Fri, 14 Jul 2023 08:01:03 GMT

After several NOK tests...

1- in my board device tree I defined an alias for the SPI that I need to use

/* These aliases are provided for compatibility with samples */
	aliases {
		led0 = &led0;
		led1 = &led1;
		led2 = &led2;
		led3 = &led3;
		pwm-led0 = &pwm_led0;
		sw0 = &button0;
		sw1 = &button1;
		sw2 = &button2;
		sw3 = &button3;
		bootloader-led0 = &led0;
		mcuboot-button0 = &button0;
		mcuboot-led0 = &led0;
		watchdog0 = &wdt0;
		spi-flash0 = &mx25r64;
		spi4 = &spi4;
	};
};

2- I tryed several way to do the binding but the nesting of DEVICE_DT_GET(DT_ALIAS(alias)) was the good one.

void main(void)
{
	const struct device *spi;
	struct spi_config spi_cfg = {0};
	int err;

	printk("fujitsu FRAM example application\n");
	//spi = device_get_binding(DT_LABEL(DT_NODELABEL(spi4)));
	//spi = DEVICE_DT_GET(spi4);
	spi = DEVICE_DT_GET(DT_ALIAS(spi4));

	if (!device_is_ready(spi)) {
		printk("SPI device %s is not ready\n", spi->name);
		return;
	}

	spi_cfg.operation = SPI_WORD_SET(8);
	spi_cfg.frequency = 256000U;


	err = mb85rs64v_read_id(spi, &spi_cfg);
	if (err) {
		printk("Could not verify FRAM ID\n");
		return;
	}

	/* Do one-byte read/write */
	data[0] = 0xAE;
	err = write_bytes(spi, &spi_cfg, 0x00, data, 1);
	if (err) {
		printk("Error writing to FRAM! error code (%d)\n", err);
		return;
	} else {
		printk("Wrote 0xAE to address 0x00.\n");
	}

	data[0] = 0x86;
	err = write_bytes(spi, &spi_cfg, 0x01, data, 1);
	if (err) {
		printk("Error writing to FRAM! error code (%d)\n", err);
		return;
	} else {
		printk("Wrote 0x86 to address 0x01.\n");
	}

	data[0] = 0x00;
	err = read_bytes(spi, &spi_cfg, 0x00, data, 1);
	if (err) {
		printk("Error reading from FRAM! error code (%d)\n", err);
		return;
	} else {
		printk("Read 0x%X from address 0x00.\n", data[0]);
	}

	data[0] = 0x00;
	err = read_bytes(spi, &spi_cfg, 0x01, data, 1);
	if (err) {
		printk("Error reading from FRAM! error code (%d)\n", err);
		return;
	} else {
		printk("Read 0x%X from address 0x01.\n", data[0]);
	}

	/* Do multi-byte read/write */
	/* get some random data, and clear out data[] */
	for (uint32_t i = 0; i < sizeof(cmp_data); i++) {
		cmp_data[i] = k_cycle_get_32() & 0xFF;
		data[i] = 0x00;
	}

	/* write them to the FRAM */
	err = write_bytes(spi, &spi_cfg, 0x00, cmp_data, sizeof(cmp_data));
	if (err) {
		printk("Error writing to FRAM! error code (%d)\n", err);
		return;
	} else {
		printk("Wrote %d bytes to address 0x00.\n",
		       (uint32_t) sizeof(cmp_data));
	}

	err = read_bytes(spi, &spi_cfg, 0x00, data, sizeof(data));
	if (err) {
		printk("Error reading from FRAM! error code (%d)\n", err);
		return;
	} else {
		printk("Read %d bytes from address 0x00.\n",
		       (uint32_t) sizeof(data));
	}

	err = 0;
	for (uint32_t i = 0; i < sizeof(cmp_data); i++) {
		if (cmp_data[i] != data[i]) {
			printk("Data comparison failed @ %d.\n", i);
			err = -EIO;
		}
	}
	if (err == 0) {
		printk("Data comparison successful.\n");
	}
}

3- I silently modified some header's inclusions.

#include <zephyr/device.h>
#include <zephyr/drivers/spi.h>

before them are without the path (and was no good).

With this modifications the building process was good.

Now I need to port in my application... I hope this will be smoothy.

Attached my template

.devzone.nordicsemi.com/.../spi_5F00_fujitsu_5F00_fram_2D00_Revisited.zip

Opened to suggestions.

RE: nRF5340 SPI Master Sample Code

0x00 — Fri, 14 Jul 2023 07:50:32 GMT

This thread spi-config-overlay-issue-with-spi_fujitsu_fram-zephyr-example seems very similar to my cas.

But the reference is, probably, too old and maybe the solution needs to be ported to the new Zephyr.

From the docs (docs.zephy api-reference) seems that when a DEVICE_DT_GET(node_id) occurs if no such device was allocated, this will fail at linker time. If you get an error that looks like undefined reference to __device_dts_ord_<N>, that is what happened.

In my output:

C:\ncs\v2.2.0\zephyr\include\zephyr\device.h:83:41: error: '__device_dts_ord_spi4_ORD' undeclared (first use in this function); did you mean '__device_dts_ord_64'?

RE: nRF5340 SPI Master Sample Code

0x00 — Thu, 13 Jul 2023 14:52:35 GMT

I tryed, under suggestion, to build the example named spi_fujitsu_fram (for 5340DK & Ublox boards) the problem is different but similar:

-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: C:/Users/cirincione/nordic/spi_fujitsu_fram
-- Found Python3: C:/ncs/toolchains/v2.2.0/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter 
-- Cache files will be written to: C:/ncs/v2.2.0/zephyr/.cache
-- Zephyr version: 3.2.99 (C:/ncs/v2.2.0/zephyr)
-- Found west (found suitable version "0.14.0", minimum required is "0.7.1")
-- Board: thingy53_nrf5340_cpuapp
-- Found host-tools: zephyr 0.15.1 (C:/ncs/toolchains/v2.2.0/opt/zephyr-sdk)
-- Found toolchain: zephyr 0.15.1 (C:/ncs/toolchains/v2.2.0/opt/zephyr-sdk)
-- Found Dtc: C:/ncs/toolchains/v2.2.0/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6") 
-- Found BOARD.dts: C:/ncs/v2.2.0/zephyr/boards/arm/thingy53_nrf5340/thingy53_nrf5340_cpuapp.dts
-- Generated zephyr.dts: C:/Users/cirincione/nordic/spi_fujitsu_fram/build/zephyr/zephyr.dts
-- Generated devicetree_generated.h: C:/Users/cirincione/nordic/spi_fujitsu_fram/build/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: C:/Users/cirincione/nordic/spi_fujitsu_fram/build/zephyr/dts.cmake
Parsing C:/ncs/v2.2.0/zephyr/Kconfig
Loaded configuration 'C:/ncs/v2.2.0/zephyr/boards/arm/thingy53_nrf5340/thingy53_nrf5340_cpuapp_defconfig'
Merged configuration 'c:/Users/cirincione/nordic/spi_fujitsu_fram/prj.conf'
Configuration saved to 'C:/Users/cirincione/nordic/spi_fujitsu_fram/build/zephyr/.config'
Kconfig header saved to 'C:/Users/cirincione/nordic/spi_fujitsu_fram/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 12.1.0
-- The CXX compiler identification is GNU 12.1.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/ncs/toolchains/v2.2.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
-- Found partition manager static configuration: C:/ncs/v2.2.0/zephyr/boards/arm/thingy53_nrf5340/pm_static_thingy53_nrf5340_cpuapp.yml
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/cirincione/nordic/spi_fujitsu_fram/build
-- west build: building application
[1/181] Generating include/generated/version.h
-- Zephyr version: 3.2.99 (C:/ncs/v2.2.0/zephyr), build: v3.2.99-ncs1
[2/181] Generating misc/generated/syscalls.json, misc/generated/struct_tags.json
[3/181] Generating include/generated/kobj-types-enum.h, include/generated/otype-to-str.h, include/generated/otype-to-size.h
[4/181] Generating include/generated/driver-validation.h
[5/181] Generating include/generated/syscall_dispatch.c, include/generated/syscall_list.h
[6/181] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
[7/181] Generating include/generated/offsets.h
[8/181] Building C object zephyr/arch/arch/arm/core/aarch32/cortex_m/CMakeFiles/arch__arm__core__aarch32__cortex_m.dir/irq_init.c.obj
[9/181] Building C object zephyr/arch/arch/arm/core/aarch32/cortex_m/CMakeFiles/arch__arm__core__aarch32__cortex_m.dir/fpu.c.obj
[10/181] Building ASM object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/cpu_idle.S.obj
[11/181] Building ASM object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/nmi_on_reset.S.obj
[12/181] Building C object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/irq_manage.c.obj
[13/181] Building C object zephyr/arch/arch/arm/core/aarch32/cortex_m/CMakeFiles/arch__arm__core__aarch32__cortex_m.dir/fault.c.obj
[14/181] Building C object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/fatal.c.obj
[15/181] Building C object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/nmi.c.obj
[16/181] Building ASM object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/isr_wrapper.S.obj
[17/181] Building ASM object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/swap_helper.S.obj
[18/181] Building C object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/thread.c.obj
[19/181] Building C object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/prep_c.c.obj
[20/181] Building ASM object zephyr/arch/arch/arm/core/aarch32/cortex_m/CMakeFiles/arch__arm__core__aarch32__cortex_m.dir/exc_exit.S.obj
[21/181] Building C object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/swap.c.obj
[22/181] Generating linker_zephyr_pre0.cmd
[23/181] Building ASM object zephyr/arch/arch/arm/core/aarch32/cortex_m/CMakeFiles/arch__arm__core__aarch32__cortex_m.dir/vector_table.S.obj
[24/181] Building C object zephyr/arch/arch/arm/core/aarch32/cortex_m/CMakeFiles/arch__arm__core__aarch32__cortex_m.dir/thread_abort.c.obj
[25/181] Building ASM object zephyr/arch/arch/arm/core/aarch32/cortex_m/CMakeFiles/arch__arm__core__aarch32__cortex_m.dir/reset.S.obj
[26/181] Building C object zephyr/arch/arch/arm/core/aarch32/cortex_m/CMakeFiles/arch__arm__core__aarch32__cortex_m.dir/scb.c.obj
[27/181] Building C object zephyr/arch/arch/arm/core/aarch32/cortex_m/cmse/CMakeFiles/arch__arm__core__aarch32__cortex_m__cmse.dir/arm_core_cmse.c.obj
[28/181] Building ASM object zephyr/arch/arch/arm/core/aarch32/cortex_m/CMakeFiles/arch__arm__core__aarch32__cortex_m.dir/fault_s.S.obj
[29/181] Building C object zephyr/arch/common/CMakeFiles/isr_tables.dir/isr_tables.c.obj
[30/181] Generating linker_zephyr_pre1.cmd
[31/181] Linking C static library zephyr\arch\arch\arm\core\aarch32\libarch__arm__core__aarch32.a
[32/181] Building C object zephyr/arch/arch/arm/core/aarch32/mpu/CMakeFiles/arch__arm__core__aarch32__mpu.dir/arm_mpu.c.obj
[33/181] Building C object zephyr/arch/arch/arm/core/aarch32/mpu/CMakeFiles/arch__arm__core__aarch32__mpu.dir/arm_core_mpu.c.obj
[34/181] Linking C static library zephyr\arch\arch\arm\core\aarch32\cortex_m\cmse\libarch__arm__core__aarch32__cortex_m__cmse.a
[35/181] Generating ../../../include/generated/libc/minimal/strerror_table.h
[36/181] Building C object zephyr/soc/arm/common/cortex_m/CMakeFiles/soc__arm__common__cortex_m.dir/arm_mpu_regions.c.obj
[37/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdlib/strtol.c.obj
[38/181] Building C object zephyr/boards/arm/thingy53_nrf5340/CMakeFiles/boards__arm__thingy53_nrf5340.dir/board.c.obj
[39/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdlib/atoi.c.obj
[40/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdlib/abort.c.obj
[41/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdlib/strtoul.c.obj
[42/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdlib/strtoull.c.obj
[43/181] Linking C static library zephyr\arch\common\libisr_tables.a
[44/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdlib/bsearch.c.obj
[45/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdlib/strtoll.c.obj
[46/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/string/strerror.c.obj
[47/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdlib/malloc.c.obj
[48/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdlib/qsort.c.obj
[49/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/string/strncasecmp.c.obj
[50/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdlib/exit.c.obj
[51/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/string/strspn.c.obj
[52/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/string/string.c.obj
[53/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdout/sprintf.c.obj
[54/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdout/stdout_console.c.obj
[55/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/string/strstr.c.obj
[56/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/math/sqrt.c.obj
[57/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/math/sqrtf.c.obj
[58/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/time/gmtime.c.obj
[59/181] Building C object zephyr/lib/libc/minimal/CMakeFiles/lib__libc__minimal.dir/source/stdout/fprintf.c.obj
[60/181] Linking C static library zephyr\arch\arch\arm\core\aarch32\cortex_m\libarch__arm__core__aarch32__cortex_m.a
[61/181] Linking C static library zephyr\boards\arm\thingy53_nrf5340\libboards__arm__thingy53_nrf5340.a
[62/181] Linking C static library zephyr\arch\arch\arm\core\aarch32\mpu\libarch__arm__core__aarch32__mpu.a
[63/181] Linking C static library zephyr\soc\arm\common\cortex_m\libsoc__arm__common__cortex_m.a
[64/181] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/crc7_sw.c.obj
[65/181] Building C object CMakeFiles/app.dir/src/main.c.obj
FAILED: CMakeFiles/app.dir/src/main.c.obj 
C:\ncs\toolchains\v2.2.0\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DKERNEL -DNRF5340_XXAA_APPLICATION -DNRF_SKIP_FICR_NS_COPY_TO_RAM -DUSE_PARTITION_MANAGER=1 -D__PROGRAM_START -D__ZEPHYR__=1 -IC:/ncs/v2.2.0/zephyr/include -Izephyr/include/generated -IC:/ncs/v2.2.0/zephyr/soc/arm/nordic_nrf/nrf53 -IC:/ncs/v2.2.0/zephyr/soc/arm/nordic_nrf/common/. -IC:/ncs/v2.2.0/nrf/include -IC:/ncs/v2.2.0/nrf/tests/include -IC:/ncs/v2.2.0/modules/hal/cmsis/CMSIS/Core/Include -IC:/ncs/v2.2.0/modules/hal/nordic/nrfx -IC:/ncs/v2.2.0/modules/hal/nordic/nrfx/drivers/include -IC:/ncs/v2.2.0/modules/hal/nordic/nrfx/mdk -IC:/ncs/v2.2.0/zephyr/modules/hal_nordic/nrfx/. -isystem C:/ncs/v2.2.0/zephyr/lib/libc/minimal/include -isystem c:/ncs/toolchains/v2.2.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/include -isystem c:/ncs/toolchains/v2.2.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/include-fixed -isystem C:/ncs/v2.2.0/nrfxlib/crypto/nrf_cc312_platform/include -fno-strict-aliasing -Os -imacros C:/Users/cirincione/nordic/spi_fujitsu_fram/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee --sysroot=C:/ncs/toolchains/v2.2.0/opt/zephyr-sdk/arm-zephyr-eabi/arm-zephyr-eabi -imacros C:/ncs/v2.2.0/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=C:/Users/cirincione/nordic/spi_fujitsu_fram=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/ncs/v2.2.0/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/ncs/v2.2.0=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT CMakeFiles/app.dir/src/main.c.obj -MF CMakeFiles\app.dir\src\main.c.obj.d -o CMakeFiles/app.dir/src/main.c.obj -c ../src/main.c
In file included from C:\ncs\v2.2.0\zephyr\include\zephyr\toolchain\gcc.h:88,
                 from C:\ncs\v2.2.0\zephyr\include\zephyr\toolchain.h:50,
                 from C:\ncs\v2.2.0\zephyr\include\zephyr\sys\errno_private.h:10,
                 from C:\ncs\v2.2.0\zephyr\lib\libc\minimal\include\errno.h:32,
                 from c:\Users\cirincione\nordic\spi_fujitsu_fram\src\main.c:7:
../src/main.c: In function 'main':
C:\ncs\v2.2.0\zephyr\include\zephyr\device.h:83:41: error: '__device_dts_ord_DT_N_ALIAS_spi_1_ORD' undeclared (first use in this function)
   83 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)
      |                                         ^~~~~~~~~
C:\ncs\v2.2.0\zephyr\include\zephyr\device.h:209:37: note: in expansion of macro 'DEVICE_NAME_GET'
  209 | #define DEVICE_DT_NAME_GET(node_id) DEVICE_NAME_GET(Z_DEVICE_DT_DEV_ID(node_id))
      |                                     ^~~~~~~~~~~~~~~
C:\ncs\v2.2.0\zephyr\include\zephyr\device.h:226:34: note: in expansion of macro 'DEVICE_DT_NAME_GET'
  226 | #define DEVICE_DT_GET(node_id) (&DEVICE_DT_NAME_GET(node_id))
      |                                  ^~~~~~~~~~~~~~~~~~
c:\Users\cirincione\nordic\spi_fujitsu_fram\src\main.c:153:15: note: in expansion of macro 'DEVICE_DT_GET'
  153 |         spi = DEVICE_DT_GET(DT_ALIAS(spi_1));
      |               ^~~~~~~~~~~~~
C:\ncs\v2.2.0\zephyr\include\zephyr\device.h:83:41: note: each undeclared identifier is reported only once for each function it appears in
   83 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)
      |                                         ^~~~~~~~~
C:\ncs\v2.2.0\zephyr\include\zephyr\device.h:209:37: note: in expansion of macro 'DEVICE_NAME_GET'
  209 | #define DEVICE_DT_NAME_GET(node_id) DEVICE_NAME_GET(Z_DEVICE_DT_DEV_ID(node_id))
      |                                     ^~~~~~~~~~~~~~~
C:\ncs\v2.2.0\zephyr\include\zephyr\device.h:226:34: note: in expansion of macro 'DEVICE_DT_NAME_GET'
  226 | #define DEVICE_DT_GET(node_id) (&DEVICE_DT_NAME_GET(node_id))
      |                                  ^~~~~~~~~~~~~~~~~~
c:\Users\cirincione\nordic\spi_fujitsu_fram\src\main.c:153:15: note: in expansion of macro 'DEVICE_DT_GET'
  153 |         spi = DEVICE_DT_GET(DT_ALIAS(spi_1));
      |               ^~~~~~~~~~~~~
[66/181] Linking C static library zephyr\lib\libc\minimal\liblib__libc__minimal.a
[67/181] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/crc8_sw.c.obj
[68/181] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/crc32_sw.c.obj
[69/181] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/crc16_sw.c.obj
[70/181] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_packaged.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\v2.2.0\opt\bin\cmake.EXE' --build 'c:\Users\cirincione\nordic\spi_fujitsu_fram\build'

 *  The terminal process terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it.

Also in this case the issue seems to be on undeclarated object.

How is possible that a sample code included into the SDK release does not compile? what can I ever do wrong?

Many Thanks