This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

spi nor flash issues with spinlock asserting on nrf52832 with NCS

hello Nordic

i am working with nrf52832, ncs 1.7.1

we have to turn on the power before trying to read jedec and to avooide changing ncs spi_nor or using SYS_INIT we decided to take the spi_nor driver and copy it and create our own flash driver based on the spi_nor driver.. however after inserting the pin change to the init function we again fall on assertions of spinlock and i do need some help with understanding this issue please

there is my .dts

// 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 = <2048>;
			block_size = <131072>;
			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>;
			};
		};
	};

there is myboard.conf

# SPI Flash
CONFIG_SPI=y

# Enable flash operations.
CONFIG_FLASH_MAP=y
CONFIG_FLASH_TESTS=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_AUGU_FLASH_IS25LP128=y

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
CONFIG_BT_RX_STACK_SIZE=1024

# CONFIG_MAIN_STACK_SIZE=1024
CONFIG_MPSL_SIGNAL_STACK_SIZE=640

CONFIG_IDLE_STACK_SIZE=128
CONFIG_ISR_STACK_SIZE=1024
# keep CONFIG_HEAP_MEM_POOL_SIZE=16384 because this is needed by usb /nrfx modules
# CONFIG_HEAP_MEM_POOL_SIZE=16384
# CONFIG_HEAP_MEM_POOL_SIZE=10240
# CONFIG_HEAP_MEM_POOL_SIZE=8192
# CONFIG_HEAP_MEM_POOL_SIZE=4096
# CONFIG_HEAP_MEM_POOL_SIZE=3600
# CONFIG_HEAP_MEM_POOL_SIZE=2048
CONFIG_HEAP_MEM_POOL_SIZE=1024

CONFIG_NRFX_SPIM=y
CONFIG_NRFX_SPIM1=y
# CONFIG_SPI_0_NRF_SPIM

CONFIG_SOC_NRF52832_ALLOW_SPIM_DESPITE_PAN_58=y

# CONFIG_SERIAL=n

# Configurations set based on thread analyzer output.
# CONFIG_SDC_RX_STACK_SIZE=324
CONFIG_BT_HCI_TX_STACK_SIZE_WITH_PROMPT=y
CONFIG_BT_HCI_TX_STACK_SIZE=640


# Disable features not needed
# CONFIG_TIMESLICING=n
# CONFIG_MINIMAL_LIBC_MALLOC=n

# Disable Bluetooth features not needed
# CONFIG_BT_DEBUG_NONE=y
# CONFIG_BT_ASSERT=n
# CONFIG_BT_DATA_LEN_UPDATE=n
CONFIG_BT_PHY_UPDATE=n
# CONFIG_BT_GATT_CACHING=n
# CONFIG_BT_GATT_SERVICE_CHANGED=n
# CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=n
# CONFIG_BT_SETTINGS_CCC_LAZY_LOADING=y
# CONFIG_BT_HCI_VS_EXT=n


# Disable Bluetooth controller features not needed
CONFIG_BT_CTLR_PRIVACY=n
CONFIG_BT_CTLR_PHY_2M=n
# Reduce Bluetooth buffers
CONFIG_BT_BUF_EVT_DISCARDABLE_COUNT=1
CONFIG_BT_BUF_EVT_DISCARDABLE_SIZE=43
CONFIG_BT_BUF_EVT_RX_COUNT=2

CONFIG_BT_CONN_TX_MAX=2
CONFIG_BT_L2CAP_TX_BUF_COUNT=2
CONFIG_BT_CTLR_RX_BUFFERS=1
CONFIG_BT_BUF_ACL_TX_COUNT=3
CONFIG_BT_BUF_ACL_TX_SIZE=27

there is my prj.conf

CONFIG_NUM_COOP_PRIORITIES=5
CONFIG_NUM_PREEMPT_PRIORITIES=10

CONFIG_NEWLIB_LIBC=y
CONFIG_CMSIS_DSP=y
CONFIG_CMSIS_DSP_FASTMATH=y
CONFIG_CMSIS_DSP_TRANSFORM=y
CONFIG_CMSIS_DSP_FILTERING=y
CONFIG_CMSIS_DSP_SUPPORT=y

CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
CONFIG_CBPRINTF_FP_SUPPORT=y

#Allow use of legacy devicetree macros
# CONFIG_LEGACY_DEVICETREE_MACROS=y

CONFIG_NO_OPTIMIZATIONS=n       #Compiler optimizations will be set to -O0 independently of other options.
CONFIG_SIZE_OPTIMIZATIONS=y     #Compiler optimizations will be set to -Os independently of other options.
CONFIG_SPEED_OPTIMIZATIONS=n    #Compiler optimizations will be set to -O2 independently of other options.
CONFIG_DEBUG_OPTIMIZATIONS=n    #Compiler optimizations will be set to -Og independently of other options.

CONFIG_TINYCBOR=y
CONFIG_CBOR_FLOATING_POINT=y

# BLE Related Configs
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME_DYNAMIC=y
CONFIG_BT_TPS=y
CONFIG_BT_DIS=y
CONFIG_BT_DIS_PNP=n
CONFIG_BT_DIS_SERIAL_NUMBER=y
CONFIG_BT_DIS_FW_REV=y
CONFIG_BT_DIS_HW_REV=y
CONFIG_BT_DIS_SW_REV=n
CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

# Below is setup to let DIS information be read from settings
CONFIG_SETTINGS_RUNTIME=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_NONE=y
CONFIG_BT_SETTINGS=y
CONFIG_BT_DIS_SETTINGS=y
CONFIG_BT_DIS_STR_MAX=50
CONFIG_BT_GATT_CACHING=n
CONFIG_BT_HCI_VS_EXT=n
CONFIG_BT_LL_SW_SPLIT=y

# I2C Related Configs
CONFIG_I2C=y
CONFIG_I2C_0=n
CONFIG_I2C_GPIO=y

# ADC Related Configs
CONFIG_ADC=y
CONFIG_ADC_ASYNC=y

# Enable mcumgr.
CONFIG_MCUMGR=y

CONFIG_ASSERT=y
CONFIG_WATCHDOG=y


# Ensure an MCUboot-compatible binary is generated.
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="root-rsa-2048.pem"   #mcuboot key
CONFIG_MCUBOOT_IMAGE_VERSION="1.1.3"
CONFIG_MCUBOOT_IMG_MANAGER=y

# Allow for large Bluetooth data packets.
CONFIG_BT_L2CAP_TX_MTU=252
CONFIG_BT_BUF_ACL_RX_SIZE=256
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_USER_DATA_LEN_UPDATE=y


# Enable the Bluetooth (unauthenticated) and shell mcumgr transports.
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n

# Enable flash operations.
CONFIG_FLASH=y
CONFIG_FLASH_JESD216_API=n
CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=n

# Enable the LittleFS file system.
CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_LITTLEFS=y

# Required by the `taskstat` command.
CONFIG_THREAD_MONITOR=y

# Enable statistics and statistic names.
CONFIG_STATS=y
CONFIG_STATS_NAMES=y

# Enable all core commands.
CONFIG_MCUMGR_CMD_FS_MGMT=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y
CONFIG_MCUMGR_CMD_STAT_MGMT=y


# sensors
CONFIG_NRFX_GPIOTE=y
CONFIG_NRFX_PPI=y
CONFIG_NRFX_TIMER0=y
CONFIG_NRFX_TIMER1=y
CONFIG_NRFX_TIMER2=y
CONFIG_NRFX_TIMER3=y
CONFIG_NRFX_TIMER4=y
CONFIG_SPI=y
CONFIG_SPI_ASYNC=y


CONFIG_GPIO=y

# LOG
CONFIG_LOG=y
CONFIG_LOG_PRINTK=y
CONFIG_LOG_BUFFER_SIZE=2048
CONFIG_LOG_BACKEND_FORMAT_TIMESTAMP=n

# enable console over SEGGER RTT
CONFIG_CONSOLE=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=8192

CONFIG_SENSOR=y
CONFIG_TEMP_NRF5=y
CONFIG_IIS3DWB=y
CONFIG_IIS3DWB_CALC_REAL_ODR=y
CONFIG_IIS3DWB_TRIGGER_OWN_THREAD=y
CONFIG_IIS3DWB_FIFO_TH=36
CONFIG_IIS3DWB_TEMPERATURE_SUPPORT=y
CONFIG_IIS3DWB_FIFO_DATA_READY_INT_PIN_1=y


CONFIG_AUGU_GPIO_POWER=y 


CONFIG_FPU=y
CONFIG_PM_DEVICE=y

and there is my addition to the spi_nor_configure function in the copied driver (the rest is unchanged, also copied jesd216.h and flash_priv.h to my flash driver's folder)

static int spi_nor_configure(const struct device *dev)
{
	const struct spi_nor_config *cfg = dev->config;
	uint8_t jedec_id[SPI_NOR_MAX_ID_LEN];
	int rc;

	/* Validate bus and CS is ready */
	if (!spi_is_ready(&cfg->spi)) {
		return -ENODEV;
	}

	/* Might be in DPD if system restarted without power cycle. */
	exit_dpd(dev);

	const struct device* power_dev = device_get_binding("FLASH_ON");
    int ret = augu_power_request(power_dev);
    if( 0 > ret )
    {
        LOG_ERR("failed in augu_power_request for flash");
        return ret;
    }
	/* now the spi bus is configured, we can verify SPI
	 * connectivity by reading the JEDEC ID.
	 */

	rc = spi_nor_read_jedec_id(dev, jedec_id);
	if (rc != 0) {
		LOG_ERR("JEDEC ID read failed: %d", rc);
		return -ENODEV;
	}
	LOG_INF("passed id test");
#ifndef CONFIG_SPI_NOR_SFDP_RUNTIME
	/* For minimal and devicetree we need to check the JEDEC ID
	 * against the one from devicetree, to ensure we didn't find a
	 * device that has different parameters.
	 */

	if (memcmp(jedec_id, cfg->jedec_id, sizeof(jedec_id)) != 0) {
		LOG_ERR("Device id %02x %02x %02x does not match config %02x %02x %02x",
			jedec_id[0], jedec_id[1], jedec_id[2],
			cfg->jedec_id[0], cfg->jedec_id[1], cfg->jedec_id[2]);
		return -EINVAL;
	}
#endif
	augu_power_release(power_dev);
	return 0;

there is the augu_power_request function code 

int augu_power_request(const struct device *dev)
{
    struct power_resource_data *data = (struct power_resource_data *)dev->data;
    struct onoff_client power_client;

	sys_notify_init_spinwait(&power_client.notify);

	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;
	}

    int res = 0;
	do {
		err = sys_notify_fetch_result(&power_client.notify, &res);
		if (!err && res) {
			LOG_ERR("failed in power resource request: res = %d\n", res);
			return res;
		}
	} while (err);

    return 0;
}

and there is the log

ASSERTION FAIL [z_spin_lock_valid(l)] @ WEST_TOPDIR/zephyr/include/spinlock.h:129

  Recursive spinlock 0x5a7

[00000026] <err> os: r0/a1:  0x00000004  r1/a2:  0x00000081  r2/a3:  0x00000000
[00000026] <err> os: r3/a4:  0x00000002 r12/ip:  0x80000000 r14/lr:  0x00013429
[00000026] <err> os:  xpsr:  0x61000000
[00000027] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
[00000027] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00000028] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
[00000028] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
[00000028] <err> os: fpscr:  0x00000000
[00000029] <err> os: Faulting instruction address (r15/pc): 0x00038c48
[00000029] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00000029] <err> os: Current thread: 0x200030b0 (unknown)
[00021409] <err> fatal_error: Resetting system
ASSERTION FAIL [z_spin_lock_valid(l)] @ WEST_TOPDIR/zephyr/include/spinlock.h:129

  Recursive spinlock 0x5a7

[00000026] <err> os: r0/a1:  0x00000004  r1/a2:  0x00000081  r2/a3:  0x00000000
[00000026] <err> os: r3/a4:  0x00000002 r12/ip:  0x80000000 r14/lr:  0x00013429
[00000026] <err> os:  xpsr:  0x61000000
[00000026] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
[00000027] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00000027] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
[00000028] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
[00000028] <err> os: fpscr:  0x00000000
[00000028] <err> os: Faulting instruction address (r15/pc): 0x00038c48
[00000028] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00000029] <err> os: Current thread: 0x200030b0 (unknown)
[00012501] <err> fatal_error: Resetting system
ASSERTION FAIL [z_spin_lock_valid(l)] @ WEST_TOPDIR/zephyr/include/spinlock.h:129

  Recursive spinlock 0x5a7

hope to read from you soon

best regards

Ziv

  • Hi,

    we again fall on assertions of spinlock

    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.

    and there is my addition to the spi_nor_configure function in the copied driver

    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

  • hi tesc

    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.

    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

    In general, the "Recursive spinlock" assert happens if the same lock is attempted required twice without being unlocked in the meantime.

    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. 

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

    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

  • hi tesc

    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.

    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

    In general, the "Recursive spinlock" assert happens if the same lock is attempted required twice without being unlocked in the meantime.

    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 Slight smile

    best regards

    Ziv

  • Hi,

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

    Please create a new ticket for the new issue.

    Regards,
    Terje

Related