I got the Zephyr littlefs sample on the nRF5340 DK to build, but never gets to main().

[mperry_at_scram]

I attempted to port the littlefs sample to the nRF5340 Developer Kit. I've gotten it to build but when I flash it there is no log output. When I try to debug it the startup process looks normal but I never hit a breakpoint I set in main().

After searching, I found this post ( littlefs sample on nrf5340dk not running) and tried building and running the modified example "littlefs2" from that thread. Same result: it never seems to get to main().

I succeeded in getting the flash_jesd216 built and running correctly on the nRF5340 DK, as well as my own app to write to the external flash and do a read back to verify. So I know the hardware and my development environment are basically good.

I'm using nRF Connect SDK v2.1.0 installed from the Toolchain Manager (v1.2.0). I'm running Ubuntu 20.04.5 LTS. I have nRF5340 DK hardware rev 2.0.0. I've attached zip archives of both of my attempts at getting this working.

7142.littlefs2.zip1581.littlefs.zip

[mperry_at_scram]

Hi Naeem,

I've examined the zip archive attached to your response. You do not appear to be using a device tree overlay for the nRF5340dk. This makes me think you built your littlefs to use the SoC's internal flash for the littlefs filesystem storage, as I believe that's where the littlefs storage is located without an overlay.

I should have clarified that my goal is to put the littlefs storage on the external flash connected over the QSPI. If you look in the 1581.littlefs.zip archives I attached to my OP I have created an overlay that deletes the node defining the littlefs partition in internal flash storage, and defined one for the QSPI flash storage. I copied this from the overlay for the nRF52840dk in the "boards" sub directory.

Also, in my testing I programmed a different, functional example to flash and saw log output over my serial connection, then programmed my littlefs project and saw no output, without disconnecting the serial port. I also tried connecting both serial ports and pressing the reset button.

[Naeem Maroof]

Hi Mark,

As per your provided information, I have now included the overlay file. I can still build, flash and see complete output. Snapshot from VS Code showing output, the overlay file in the app directory and the compiled DTS is attached. 

*Just a small note, I was not able to extract your complete zip directory as it was complaining about "too long" names. Nonetheless, our project structure is same: starting from little-fs sample and then updating DTS through overlay.

Naeem

[mperry_at_scram]

Hi Naeem,

I'm back from a 10-day vacation and just getting back to this. Can you attach an archive of your project with the overlay file for the littlefs using the QSPI flash? Alternatively, I could try to archive a clean of my second example as the "file names too long" probably applies to generated files.

FWIW since I couldn't get the littlefs library that's "built in" to Zephyr to work I tried incorporating littlefs source code from its original git repository as application code. I did get that to work.

Mark

[Naeem Maroof]

Hi Mark,

mperry_at_scram said:

Can you attach an archive of your project with the overlay file for the littlefs using the QSPI flash?

Yes, sure. Please find attached.

mperry_at_scram said:

I could try to archive a clean of my second example as the "file names too long" probably applies to generated files.

This was solved by placing the downloaded zip file in the c:/ and then extracting it (otherwise it was very long path, containing c:/user/username/downloads/). Moreover, files in the build folder can have long names depending how you named your build folder.

Nonetheless, I was able to extract your project and compare with mine. Interestingly the projects were similar, and now I know why you were not able to see the output. I am able to correctly build, flash and see output from your project.

The problem (in fact not the problem, but confusion / mistake) lies in the build process. I have seen that you built the project for "nrf5340dk_nrf5340_cpuapp_ns", which means that your application is built for non-secure domain, and a trusted firmware (TF-M) will be included that will provide security by separation. 

You can read more about Trusted-Firmware here. If you are interested to build for NS domain, you can look at samples which include TF-M.

At this time, to build, flash and see the output, you may use "nrf5340dk_nrf5340_cpuapp" as your build target, and it will be done.

0535.littlefs_my.zip

Hope it helps. With regards,

Naeem

[David Boden]

Just to declare up-front I'm new to embedded software, but not to programming in general; sorry if I've misunderstood anything. I'm using NRF Connect v2.2.0.

I have the same objective as the original poster, @mperry_at_scram, getting the littlefs filesystem up on the *external* flash.

It's important that we build with `prj_blk.conf`, because this is the config which communicates the intention of using the external 64MB flash for the filesystem rather than the SOC's internal flash.

This littlefs sample is really two samples in one, which is definitely a source of confusion.

@Naeem Maroof , when I run your example when building against board `nrf5340dk_nrf5340_cpuapp` (notice no `_ns` suffix) then I get this, which works. However, it's using the *internal* flash (notice `FS at flash-controller`...):

```

*** Booting Zephyr OS build v3.2.99-ncs1 ***

Sample program to r/w files on littlefs

Area 6 at 0xfa000 on flash-controller@39000 for 24576 bytes

I: LittleFS version 2.5, disk version 2.0

I: FS at flash-controller@39000:0xfa000 is 6 0x1000-byte blocks with 512 cycle

I: sizes: rd 16 ; pr 16 ; ca 64 ; la 32

I: /lfs mounted

/lfs mount: 0

/lfs: bsize = 16 ; frsize = 4096 ; blocks = 6 ; bfree = 3

... logs indicating successful execution...

```

In your zip file you've included the file `nrf5340dk_nrf5340_cpuapp_ns.overlay` (with `_ns` suffix), which I don't think was what you intended? (again, sorry if I've misunderstood)

If I copy this to `nrf5340dk_nrf5340_cpuapp.overlay` (without `_ns` suffix) and build / flash then I get:

```

I: littlefs partition at /lfs1

I: LittleFS version 2.5, disk version 2.0

I: FS at mx25r6435f@0:0x0 is 16 0x1000-byte blocks with 512 cycle

I: sizes: rd 16 ; pr 16 ; ca 64 ; la 32

E: WEST_TOPDIR/modules/fs/littlefs/lfs.c:4196: Invalid block count (32 != 16)

W: can't mount (LFS -22); formatting

E: ***** USAGE FAULT *****

E: Stack overflow (context area not valid)

E: r0/a1: 0x00000000 r1/a2: 0x00000667 r2/a3: 0x00000000

E: r3/a4: 0x00000000 r12/ip: 0x00000020 r14/lr: 0x00004525

E: xpsr: 0x00000000

E: Faulting instruction address (r15/pc): 0x00004235

E: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0

E: Current thread: 0x20000418 (unknown)

E: Halting system

```

Hooray, this is trying to use the external flash, `FS at mx25r6435f@0:0x0`... but is failing due to "Invalid block count". I'd be grateful if you could confirm that you see the same thing, and I'd appreciate any pointers towards fixing it that might spring to mind.

As a side-issue, which I'm not concerned about myself, if I build for board `nrf5340dk_nrf5340_cpuapp_ns` with `prj_blk.conf` then it tries to use the internal SOC flash and this prompts a different error, which I've seen elsewhere on the forums.

```

I: littlefs partition at /lfs1

I: LittleFS version 2.5, disk version 2.0

I: FS at flash-controller@39000:0xf8000 is 6 0x1000-byte blocks with 512 cycle

I: sizes: rd 16 ; pr 16 ; ca 64 ; la 32

E: WEST_TOPDIR/modules/fs/littlefs/lfs.c:1234: Corrupted dir pair at {0x0, 0x1}

W: can't mount (LFS -84); formatting

```

It would be really useful to get the Zephyr sample updated with the nrf5340 configurations just so that anyone who is trying to do the same thing doesn't need to see all of this :) github.com/.../boards

[Naeem Maroof]

Hello David,

Apologies for delayed response.

You are very much right for all the items you have mentioned.

We can see that "prj_blk.conf" has configurations related to disk access; so yes, we need to use these configurations if we are using off-chip storage.

Regarding the overlay file, we need to include the file with correct name as of the target.

Nonetheless, when building for _ns target, TFM is included. So you need to see what do you want.

I do not have a SDCard with me, but looks like the formatting problem of the card. 

(Formatting of SD card)

Good to know that it is working for you and thank you for your input.

Regards,

Naeem

[David Boden]

It works when I run the sample in littlefs2.zip provided by Sigurd Hellesvik attached to this thread:  littlefs sample on nrf5340dk not running 

This sample only has a prj.conf and is significantly different than the latest version of the littlefs sample. The sample looks to have changed significantly, the latest being https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/fs/littlefs

I suspect there's a problem with the sample distributed with the latest nRF Connect SDK when trying to run prj_bulk.conf with an NRF5340 DK board, after copying the overlay configuration files over from the NRF52 examples.