External Flash Sample Issue

colemurray

External Flash Error Busy
Hey Jared,

I’m playing around with the external flash example (no modifications), branch v1.7.x on the v4 feather board. I’m running into an issue with the fs_open operation, and receiving a E_BUSY (-16) error code.

A user near the end of this thread experienced the same error code: https://community.jaredwolff.com/d/31-littlefs-on-external-flash-not-working-mpu-fault

I’ve tried wiping the app flash storage via the flag with no luck. Any thoughts?

stdout

*** Booting Zephyr OS build v2.6.99-ncs1-1  ***
Area 1 at 0x0 on W25Q32JV for 4194304 bytes
[00:00:00.217,407] <inf> littlefs: LittleFS version 2.2, disk version 2.0
[00:00:00.225,067] <dbg> littlefs.littlefs_mount: FS area 1 at 0x0 for 4194304 bytes
[00:00:00.234,649] <inf> littlefs: FS at W25Q32JV:0x0 is 1024 0x1000-byte blocks with 512 cycle
[00:00:00.244,232] <inf> littlefs: sizes: rd 16 ; pr 16 ; ca 64 ; la 32
[00:00:00.252,471] <inf> littlefs: /lfs mounted
[00:00:00.257,629] <dbg> fs.fs_mount: fs mounted at /lfs
/lfs mount: 0
/lfs: bsize = 16 ; frsize = 4096 ; blocks = 1024 ; bfree = 1022
/lfs/boot_count stat: -2
FAIL: open /lfs/boot_count: -16
[00:00:00.277,832] <inf> littlefs: /lfs unmounted
[00:00:00.283,233] <dbg> fs.fs_unmount: fs unmounted from /lfs
/lfs unmount: 0

colemurray

After some playing around, here is some findings:

Flashing the device with bootloader: v2-010421-1502-merged.hex, https://docs.jaredwolff.com/nrf9160-downloads.html, and flash via newtmgr app_update.bin, I experiencing the following

*** Booting Zephyr OS build v2.6.99-ncs1-1  ***
Area 1 at 0x0 on W25Q32JV for 4194304 bytes
[00:00:00.217,407] <inf> littlefs: LittleFS version 2.2, disk version 2.0
[00:00:00.225,067] <dbg> littlefs.littlefs_mount: FS area 1 at 0x0 for 4194304 bytes
[00:00:00.234,649] <inf> littlefs: FS at W25Q32JV:0x0 is 1024 0x1000-byte blocks with 512 cycle
[00:00:00.244,232] <inf> littlefs: sizes: rd 16 ; pr 16 ; ca 64 ; la 32
[00:00:00.252,471] <inf> littlefs: /lfs mounted
[00:00:00.257,629] <dbg> fs.fs_mount: fs mounted at /lfs
/lfs mount: 0
/lfs: bsize = 16 ; frsize = 4096 ; blocks = 1024 ; bfree = 1022
/lfs/boot_count stat: -2
FAIL: open /lfs/boot_count: -16
[00:00:00.277,832] <inf> littlefs: /lfs unmounted
[00:00:00.283,233] <dbg> fs.fs_unmount: fs unmounted from /lfs
/lfs unmount: 0

If build and flash the whole app hex directly from the samples, I experience the following:

*** Booting Zephyr OS build v2.6.99-ncs1-1  ***
Area 1 at 0x0 on W25Q32JV for 4194304 bytes
[00:00:00.217,376] <inf> littlefs: LittleFS version 2.2, disk version 2.0
[00:00:00.225,036] <dbg> littlefs.littlefs_mount: FS area 1 at 0x0 for 4194304 bytes
[00:00:00.234,558] <inf> littlefs: FS at W25Q32JV:0x0 is 1024 0x1000-byte blocks with 512 cycle
[00:00:00.244,140] <inf> littlefs: sizes: rd 16 ; pr 16 ; ca 64 ; la 32
[00:00:00.260,589] <inf> littlefs: /lfs mounted
[00:00:00.265,716] <dbg> fs.fs_mount: fs mounted at /lfs
/lfs mount: 0
/lfs: bsize = 16 ; frsize = 4096 ; blocks = 1024 ; bfree = 1019
/lfs/boots_count stat: 0
        fn 'boots_count' siz 4
/lfs/boots_count read count 8: 4
/lfs/boots_count seek start: 0
/lfs/boots_count write new boot count 9: 4
/lfs/boots_count close: 0
Settings: before: status 8, interval: 20
Settings: after: status 9, interval: 20
[00:00:00.550,140] <inf> littlefs: /lfs unmounted
[00:00:00.555,450] <dbg> fs.fs_unmount: fs unmounted from /lfs
/lfs unmount: 0

but the device will no longer run on battery as described here https://community.jaredwolff.com/d/326-ps-en-pin-enabled-in-bootloader-during-boot

The bootloader in the project dir is commit b514a3190821b7721dd6ffcd9940474ebe7a8832 (HEAD, tag: v1.7.99-ncs3-1, tag: v1.7.99-ncs3, manifest-rev)

jaredwolff

Hmmm my output on the v1.7.x branch of NFED is a bit different than yours.

*** Booting Zephyr OS build v2.6.99-ncs1-1  ***
Area 1 at 0x0 on W25Q32JV for 4194304 bytes
[00:00:00.211,364] <inf> littlefs: LittleFS version 2.2, disk version 2.0
[00:00:00.219,848] <inf> littlefs: FS at W25Q32JV:0x0 is 1024 0x1000-byte blocks with 512 cycle
[00:00:00.229,492] <inf> littlefs: sizes: rd 16 ; pr 16 ; ca 64 ; la 32
[00:00:00.320,587] <inf> littlefs: /lfs mounted
/lfs mount: 0
/lfs: bsize = 16 ; frsize = 4096 ; blocks = 1024 ; bfree = 1006
/lfs/boot_count stat: 0
        fn 'boot_count' siz 4
/lfs/boot_count read count 16: 4
/lfs/boot_count seek start: 0
/lfs/boot_count write new boot count 17: 4
/lfs/boot_count close: 0
[00:00:00.461,181] <err> settings: set-value failure. key: config error(-2)
Settings: before: status 8, interval: 20
Settings: after: status 9, interval: 20
[00:00:00.801,391] <inf> littlefs: /lfs unmounted
/lfs unmount: 0

The latest version of NFED is 31ef076c57d2a8e33946148297eb4592e5f713a0. You should update (git pull then west update) and try again.

colemurray

jaredwolff
I wasn’t able to get both the battery working and LFS on the v1.7.x branch. Tried a complete project start from scratch with no luck.

I did upgrade and use the v1.9.x branch, and was able to run the example.
However, I am experiencing the same issue as the other thread when enabling the CONFIG_NETWORKING=y flag.

Repro:

Clean init repo with Zephyr tools
Select branch v1.9.x
change project external flash
modify prj.conf with CONFIG_NETWORKING=y
build & flash hex
observe -16 EBUSY error

colemurray

After comparing against the zephyr samples, it appears the root cause here is a missing call fs_file_t_init(&file); prior to opening the file. This would leave the struct uninitialized and cause undefined behavior.

static inline void fs_file_t_init(struct fs_file_t *zfp)
{
	*zfp = (struct fs_file_t){ 0 };
}

I am no longer experiencing issues after adding this function call and appears to be required as stated in the documentation.

https://github.com/circuitdojo/nrf9160-feather-examples-and-drivers/blob/v1.9.x/samples/external_flash/src/main.c#L142
https://docs.zephyrproject.org/latest/services/file_system/index.html#c.fs_file_t_init

jaredwolff

Hmm very weird behavior just by turning on networking! I seem to remember having the same issues previously but it manifested differently. My solution was to init struct fs_file_t by setting it to {0} (Which is what that fs_file_t_init seems to be doing)

Thanks for following up colemurray. Sorry I couldn’t get you to a solution sooner.