LittleFS mounting stalls the application when the SPI flash is unavailable

[Aurele]

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

[Hieu]

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

[Aurele]

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

[Hieu]

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

[Aurele]

Hello Hieu 

Thank you for the reply. I think you're right — I'll ask the people on the Zephyr Discord if they have any ideas on how to handle this.

Actually, this only applies to a specific situation, but I need to ensure there's a backdoor or fallback for every corner case, and maintain robustness since this will be embedded in an industrial product.

Hieu said:

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.

I completely agree — I think this is unsafe, and such an hardware design should not exist. I will ask the firmware team responsible for the other CPU accessing the SPI flash to release the SPI lines as soon as they no longer receive any refresh indication from my side.

Thank you very much

[Hieu]

H Aurélien,

I just want to put down another idea I just thought of. Is it OK if one of the MCUs serve as an agent and serve the SPI Flash content to other MCUs? It might be a safer solution.