Filesystem Trouble - Converting FAT_FS to NVS partitions.

Hello Folks,

I've got a thorny problem that I've spent an entire day minimizing before even trying to post about it here.

Before diving in, however, here are my environment details.

===================

Board:

MAIN TARGET: xiao_ble_sense

PROTOTYPE TARGET: nrf52840dk_nrf52840

Toolchain Version:

nRF Connect SDK v2.5.0

Host Operating System:

Win 11 (May prove relevant)

===================

Context:

I am working on a system for configuring my device's settings (stored as JSON in the device's persistent memory). A previous iteration used a USB-mounted ExFat FileSystem.

The current iteration uses Bluetooth, and that part of the project is working as intended.

I'm running into trouble configuring NVS partitions in regions that used to be FAT_FS.

Problem Statement:

Partitions which were previously part of an ExFat Filesystem can't be set up as NVS partitions in the specific case when the application is threaded.

Specifics:

Consider the following Three applications (yes, really), which serve similar purposes, but with slightly different mechanics

  • mass
    • This application sets up a USB Mass Storage Device on the external flash region of the target device
    • based on zephyr/samples/subsys/usb/mass
  • nvs
    • This application sets up a custom nvs partition on the external flash of the target device, reads the current contents, then writes a fixed string back into that partition
    • based on zephyr/samples/subsys/nvs
  • nvs_aem
    • This application does the exact same thing as nvs (above)
    • based on zephyr/samples/subsys/nvs but with app_event_manager structuring added (module, event).
    • The difference: the methods to setup_flash and perform NVS read&write operations are called from a module which reacts to the app main setting state to ready.

A completely new board (either dev kit or xiao) will exhibit the following behavior when programmed with one of these applications:

EITHER OF: {nvs, nvs_aem}

An NVS partition will be established at the specified location, and the app behaves exactly as expected (specified above).

On first boot, read fails (nothing is in the storage)

On resets, the config data is loaded, and persists across Power Cycles

mass

A filesystem is created and mounted in the external flash. It appears in USB device lists.

When attempting to connect to the computer, it will specify "you need to format the disk before you can use it"

If you allow the Host OS to format the flash region, you will have a working filesystem which persists across boots and power downs.

If you disallow the Host OS to format the flash region, you are unable to access the region via USB.

Here's where things get interesting!

If you take a device that is programmed with mass, and you program it with one of the other applications, you can observe the following:

mass into nvs:

On FIRST BOOT:

Flash setup succeeds.

Read fails (errno 2: ENOENT). This makes sense, since NVS storage is different than file-system, so hasn't been given the right metadata.

Write succeeds new data into the NVS (As expected)

On SUBSEQUENT BOOTS:

Flash setup succeeds

Read (from NVS) succeeds

Write (from NVS) succeeeds)

WORKS AS EXPECTED

mass into nvs_aem:

On FIRST AND SUBSEQUENT BOOTS:

Flash Setup fails.

(errno 13: EACCES) Permission Denied. This is where I'm stuck

My Request for Assistance:

  • I need a way to recover my boards from whatever it is mass did to them. I'd like my DevKit to be functional with nvs and nvs_aem.
    • I need to be able to update the devices I have under test, but it won't be possible since they all have a USB Ex_Fat filesystem occupying their full external flash region.
  • I would also like to know why nvs is able to ignore what mass did, while nvs_aem cannot.

The Applications Themselves: WARNING! The mass app may damage your board. (I don't know how to recover what it did to my boards)

Building The Apps:

All three of the attached apps follow an identical structure

/boards (overlay files)

/scripts (WEST BUILD COMMANDS WITHIN BASH SCRIPTS)

/src

prj.conf (Shared between xiao and dk builds)

My recommendation for building each app is to open the app root directory in an nRF Connect terminal, and run the associated bash script for your target board (xiao for xiao_ble_sense, dk for nrf52840dk_nrf52840).

WARNING! The "mass" app may be harmful to your board's flash storage, and I don't know how to recover from this state.

mass_app.zip 

nvs_aem_app.zip 

nvs_app.zip

Thank you very much for any advice you can provide!

Wishing you all the best,

    - Finn

Parents
  • I have to ask one of our colleagues who is more experienced in partitioning and security. Let me come back to you when I have more pointers on this.

    Edit: Showing this info to my colleague says that you are very good devzone user and you do your homework before posting issues here. And looking at the content of this issue, it looks like your description is very informative. Still have not found the valid answer for it so please hang on.

Reply
  • I have to ask one of our colleagues who is more experienced in partitioning and security. Let me come back to you when I have more pointers on this.

    Edit: Showing this info to my colleague says that you are very good devzone user and you do your homework before posting issues here. And looking at the content of this issue, it looks like your description is very informative. Still have not found the valid answer for it so please hang on.

Children
No Data
Related