spi nor flash issues with spinlock asserting on nrf52832 with NCS

RE: spi nor flash issues with spinlock asserting on nrf52832 with NCS

tesc — Tue, 14 Jun 2022 10:55:09 GMT

Hi,

I am happy to hear that you solved the initial issue.

Please create a new ticket for the new issue.

Regards,
Terje

RE: spi nor flash issues with spinlock asserting on nrf52832 with NCS

ziv123 — Tue, 14 Jun 2022 09:12:15 GMT

hi tesc

[quote userid="8164" url="~/f/nordic-q-a/88531/spi-nor-flash-issues-with-spinlock-asserting-on-nrf52832-with-ncs/370833#370833"]Have you had similar issues (recursive spinlock or other spinlock issues) earlier, and if so are there other DevZone threads where this has been discussed? Providing links to those would give valuable information to solving the current issue.[/quote]

there is the thread and it can be closed (not sure how to close it without verifying the answer)

https://devzone.nordicsemi.com/f/nordic-q-a/88263/using-spi_nor-driver-with-nrf-sdk-connect-zephyr---driver-not-found

[quote userid="8164" url="~/f/nordic-q-a/88531/spi-nor-flash-issues-with-spinlock-asserting-on-nrf52832-with-ncs/370833#370833"]In general, the "Recursive spinlock" assert happens if the same lock is attempted required twice without being unlocked in the meantime.[/quote]

the problem was actually that in the init (called at POST_KERNAL) the flash driver is not yet powered on by that pin and eventually decided to implement the spi_nor ourselves and copied it and for start just added the power on in the init and changed the call for the init to be at APPLICATION. that solved the issue.

the spinlock happened because the init driver function failed at the POST_KERNAL cause it could not get the id from the flash due to the flash not being powered on, so there was no device instance created, and then in the power_request call with the instance that does not exist it asserted.

but thanks for the explanation regarding the spin-lock, its good to know 🙂

best regards

Ziv

RE: spi nor flash issues with spinlock asserting on nrf52832 with NCS

ziv123 — Tue, 14 Jun 2022 09:11:20 GMT

hi tesc

there is the thread and it can be closed (not sure how to close it without verifying the answer)

https://devzone.nordicsemi.com/f/nordic-q-a/88263/using-spi_nor-driver-with-nrf-sdk-connect-zephyr---driver-not-found

but thanks for the explanation regarding the spin-lock, its good to know 🙂

how ever i have 2 questions and if you prefer than let me know and i will open a new thread for that

when tying to write a page (256 bytes) to the flash at a test in the beginning of the app it take 1ms to write that page but when trying to write within the app it takes 3ms and also i get a BUS FAULT. here is the log:

[00000018] <err> os: ***** BUS FAULT *****
[00000018] <err> os:   Unstacking error
[00000018] <err> os: ***** HARD FAULT *****
[00000018] [1;31m<err> os:   Fault escalation (see below)
[00000018] <err> os: ***** BUS FAULT *****
[00000018] <err> os:   Precise data bus error
[00000018] <err> os:   BFAR Address: 0xfe80fec0
[00000018] <err> os: r0/a1:  0x2000bef0  r1/a2:  0xfe80fec0  r2/a3:  0xfe80ff28
[00000018] <err> os: r3/a4:  0x2000beef r12/ip:  0xfa000000 r14/lr:  0x00016d79
[00000018] <err> os:  xpsr:  0x81000005
[00000018] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
[00000018] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00000018] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
[00000018] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
[00000018] <err> os: fpscr:  0x20001d78
[00000018] <err> os: Faulting instruction address (r15/pc): 0x0003ef10
[00000018] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00000018] <err> os: Fault during interrupt handling

[00000018] <err> os: Current thread: 0x20003210 (unknown)
[00000018] <err> fatal_error: Resetting system
*** Booting Zephyr OS build v2.6.99-ncs1-1  ***

now i do have in the app another driver that uses spi (at the same time (getting samples and writing samples to flash), but it uses a different instance of spi so i don't see why it shell create such a delay .. here is my complete .dts file:

// Copyright (c) 2022 Nordic Semiconductor ASA
// SPDX-License-Identifier: Apache-2.0

/dts-v1/;
#include <nordic/nrf52832_qfaa.dtsi>

/ {
	model = "halo_ep2";
	compatible = "halo-ep2";

	chosen {
		zephyr,sram = &sram0;
		zephyr,flash = &flash0;
		zephyr,code-partition = &slot0_partition;
		nordic,pm-ext-flash = &augu_flash_is25lp128;
	};

	sensors_on: sensors_on_node {
		compatible = "augury,gpio-power";
		power_gpios = <&gpio0 22 GPIO_ACTIVE_LOW>;
		label = "SENSORS_ON";
		status = "okay";
		#power_resource-cells = <0>;
	};

	flash_on: flash_on_node {
		compatible = "augury,gpio-power";
		power_gpios = <&gpio0 23 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
		label = "FLASH_ON";
		status = "okay";
		#power_resource-cells = <0>;
	};	

    leds {
        compatible = "gpio-leds";
        led0_red: led_0 {
            gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
            label = "RED_LED_0";
        };
        led1_orange: led_1 {
            gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
            label = "ORANGE_LED_1";
        };
        led2_green: led_2 {
            gpios = <&gpio0 27 GPIO_ACTIVE_HIGH>;
            label = "GREEN_LED_2";
        };							
    };

	aliases {
		led0-red = &led0_red;
		led1-orange = &led1_orange;
		led2-green = &led2_green;

	};
};

	&adc {
		status ="okay";
	};

	&gpiote {
		status ="okay";
	};

	&gpio0 {
		status ="okay";
	};


	&spi1 {
		compatible = "nordic,nrf-spim";
		status = "okay";
		sck-pin = <20>;
		mosi-pin = <14>;    // p0.14
		miso-pin = <16>;    // p0.16
		cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
		iis3dwb@0 {
			compatible = "st,iis3dwb";
			reg = <0>;
			int1_gpios = <&gpio0 11 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;
			int2_gpios = <&gpio0 12 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;
			label = "IIS3DWB";
			power_resources = <&sensors_on>;
			spi-max-frequency = <8000000>;
		};
	};

	&spi2 {
		status = "okay";
		sck-pin = <5>; // gpio 0 pin 5
		mosi-pin = <4>; // gpio 0 pin 4
		miso-pin = <2>; // gpio 0 pin 2
		compatible = "nordic,nrf-spi";
		cs-gpios = <&gpio0 3 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
		augu_flash_is25lp128: augu_flash_is25lp128@0 {
			compatible = "issi,augu_flash_is25lp128";
			reg = <0>;
			label = "AUGU_FLASH_IS25LP128";
			power_resources = <&flash_on>;
			jedec_id = [9d 60 18];
			spi-max-frequency = <8000000>; //<133000000>;
			page_size = <256>;
			block_size = <65536>;
			size = <0x8000000>;
		};
	};
	&flash0 {
		partitions {
			compatible = "fixed-partitions";
			#address-cells = <1>;
			#size-cells = <1>;

			mbr_partition: partition@0 {
				label = "mbr";
				reg = <0x00000000 0x00001000>;
			};
			boot_partition: partition@1000 {
				label = "mcuboot";
				reg = <0x1000 0xc000>;
			};
			slot0_partition: partition@d000 {
				label = "image-0";
				reg = <0xd000 0x6c800>;
			};
			slot1_partition: partition@79800 {
				label = "image-1";
				reg = <0x79800 0x800>;
			};
			storage_partition: partition@7a000 {
				label = "storage";
				reg = <0x7a000 0x6000>;
			};
		};
	};

(running the app on another baord with nrd52840, with nand flash that writes 2k each time, works well, so i don't know if it is a performance issue or something else.. i will also mention that the RAM take on the nrf52832 with zephyr and all is high:

[567/572] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      253604 B     419328 B     60.48%
            SRAM:       60282 B        64 KB     91.98%
        IDT_LIST:          0 GB         2 KB      0.00%
[568/572] Generating zephyr/mcuboot_primary_app.hex
[569/572] Generating zephyr/mcuboot_primary.hex
[570/572] Generating ../../zephyr/app_update.bin, ../../zephyr/app_signed.hex, ../../zephyr/app_test_update.hex, ../../zephyr/app_moved_test_update.hex
[571/572] Generating ../../zephyr/dfu_application.zip
[572/572] Generating zephyr/merged.hex

any idea why i get the BUS FAULT ?

the other question i will leave for now it is also regarding a try to improve the current spi_nor_write function but anyhow it will not solve the 3ms issue and if it will remain on 1ms per page write as seen in the first test then we will be ok

hope to read from you soon

best regards

Ziv

RE: spi nor flash issues with spinlock asserting on nrf52832 with NCS

tesc — Fri, 03 Jun 2022 09:46:16 GMT

Hi,

[quote user=""]we again fall on assertions of spinlock[/quote]

Have you had similar issues (recursive spinlock or other spinlock issues) earlier, and if so are there other DevZone threads where this has been discussed? Providing links to those would give valuable information to solving the current issue.

In general, the "Recursive spinlock" assert happens if the same lock is attempted required twice without being unlocked in the meantime. Trying to acquire a lock that you already have, will assert and give this error. This may happen for instance if the lock is needed from two different places running in different interrupt contexts on the same core.

[quote user=""]and there is my addition to the spi_nor_configure function in the copied driver[/quote]

I assume we are talking about changes to zephyr/drivers/flash/spi_nor.c.

Based on the log, you never reach ' LOG_INF("passed id test");', which means your custom augu_power_request function might be at fault. I would either do a debug session putting breakpoints various locations in that function, or simply add some debug output (logging) at some locations in that function, to establish how far it gets.

For instance you could add to this portion a TEMPORARY log message (remember to remove it after debugging) just to confirm the step is passed:

	int err = onoff_request(&data->onoff_mgr, &power_client);
	if (err < 0) {
		LOG_ERR("failed in power resource request: err = %d\n", err);
		return err;
	} else {
	    LOG_ERR("succeeded in power resource request");
	}

By the way, I do notice in your added code, you are not checking the return value of the device_get_binding call:

	const struct device* power_dev = device_get_binding("FLASH_ON");
    int ret = augu_power_request(power_dev);

If the returned power_dev is NULL, because of some error in configuration or other, then you are sending a NULL reference to augu_power_request which could make things break. Checking the value (either before calling augu_power_request or inside augu_power_request before using it) would be a good idea.

Regards,
Terje