LittleFS mounting stalls the application when the SPI flash is unavailable

Hello

I'm trying to use LittleFS with an external SPI flash, but if the SPI flash isn't available yet at boot time, my application hangs for an uncertain amount of time.

I'd like to control when the filesystem is mounted manually and be able to detect if the SPI flash is unavailable. Is this possible?
I tried commenting out the automount property, but it didn’t solve the issue.

app.overlay : 

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

 /*/delete-node/ &mx25r64;*/

/* /delete-node/ &storage_partition;*/

 / {
     chosen {
         nordic,pm-ext-flash = &mx25r16;
     };

     fstab {
         compatible = "zephyr,fstab";
         lfs1: lfs1 {
             compatible = "zephyr,fstab,littlefs";
             mount-point = "/lfs1";
             partition = <&lfs1_partition>;
             /*automount;*/
             read-size = <16>;
             prog-size = <16>;
             cache-size = <64>;
             lookahead-size = <32>;
             block-cycles = <512>;
         };
     };
 };

&spi2 {
	compatible = "nordic,nrf-spi";
	status = "okay";
	cs-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
	pinctrl-0 = <&spi2_default>;
	pinctrl-1 = <&spi2_sleep>;
	pinctrl-names = "default", "sleep";
	mx25r16: mx25r1635f@0 {
		compatible = "jedec,spi-nor";
		reg = <0>;
		spi-max-frequency = <8000000>;
        jedec-id = [c2 28 15];
        /* 
		sfdp-bfp = [
			e5 20 f1 ff  ff ff ff 03  44 eb 08 6b  08 3b 04 bb
			ee ff ff ff  ff ff 00 ff  ff ff 00 ff  0c 20 0f 52
			10 d8 00 ff  23 72 f5 00  82 ed 04 cc  44 83 68 44
			30 b0 30 b0  f7 c4 d5 5c  00 be 29 ff  f0 d0 ff ff
		];*/
        size = <DT_SIZE_M(16)>;
		has-dpd;
		t-enter-dpd = <10000>;
		t-exit-dpd = <35000>;
	};
};

 &mx25r16 {
	status = "okay";
    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        lfs1_partition: partition@0 {
            label = "lfs1";
            reg = <0x00000000 0x200000>;
        };
    };
};

Booting : 

I: littlefs partition at /lfs1
*** Booting My Application v0.8.9-b328fd29cb96 ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
Starting Bluetooth
I: 2 Sectors of 4096 bytes
I: alloc wra: 0, fa8
I: data wra: 0, 34
I: SoftDevice Controller build revision: 
I: 2d 79 a1 c8 6a 40 b7 3c |-y..j@.<
I: f6 74 f9 0b 22 d3 c4 80 |.t.."...
I: 74 72 82 ba             |tr..    
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF52x (0x0002)
I: Firmware: Standard Bluetooth controller (0x00) Version 45.41337 Build 3074452168
I: No ID address. App must call settings_load()
W: opcode 0xfc0e status 0x42 
Set Tx power err: -5 reason 0x00
Bluetooth initialized
I: Identity: D2:10:69:2F:12:13 (random)

Environment :

nrf sdk 2.9.0

CPU : nRF52840

Parents
  • Hello Aurele,

    Could you please give some more details on how late the SPI flash device is going to be available? Is it some specific system power up delay, or is the device dynamically powered in some way?

    Hieu

  • Hello Hieu,

    Actually, my external SPI flash is shared between multiple CPUs, and some of them may hold the SPI lines.
    I’m aware that this isn't ideal, but unfortunately, I’m not responsible for the hardware design.

    Now, I need to find a solution to ensure that the nRF52 can power on and operate normally, even when the SPI lines are being held by another CPU.

    Best regards,

    Aurélien

  • Hi Aurélien,

    To my understanding, the LittleFS and flash driver are initialized during application initialization, before main().

    I am not able to find documentation or any hints of a dynamic initialization strategy available. I believe that, at the moment, while the file system API supports unmounting, the flash driver doesn't support device deinitialization. 
    The people at the Zephyr Discord might be able to confirm/refute these with better certainty.

    With such a hardware, I am afraid you have to use a manual driver scheme using the nrfx driver and then port a copy of the flash driver and LittleFS library to work with this design.

    That is definitely not trivial.

    I am also a bit concerned if it is safe with the nRF device's SPI pins being in output mode while other MCUs are driving the lines, though this is outside of my expertise.

    Best regards,

    Hieu

Reply
  • Hi Aurélien,

    To my understanding, the LittleFS and flash driver are initialized during application initialization, before main().

    I am not able to find documentation or any hints of a dynamic initialization strategy available. I believe that, at the moment, while the file system API supports unmounting, the flash driver doesn't support device deinitialization. 
    The people at the Zephyr Discord might be able to confirm/refute these with better certainty.

    With such a hardware, I am afraid you have to use a manual driver scheme using the nrfx driver and then port a copy of the flash driver and LittleFS library to work with this design.

    That is definitely not trivial.

    I am also a bit concerned if it is safe with the nRF device's SPI pins being in output mode while other MCUs are driving the lines, though this is outside of my expertise.

    Best regards,

    Hieu

Children
No Data
Related