Accessing little file storage data over BLE

I'm attempting to store log data on my nRF52832 using the little file storage, and then allow a client to access this over BLE.  From what I can tell, the data transfer can be handled using the MCUmgr, as described here.

I've implemented the lfs example (v2.0.0\zephyr\samples\subsys\fs\littlefs) in my code, and am updating and writing the boot count to my file.  My mount point is /lfs and the variable I am writing is /boot_count, as per the example.

My iOS app developer is trying to read the info I am storing in my file storage, but is consistently getting errors back when he tries to access my file storage.  This is the outcome of his testing:

I have tried with and without an extension, also with and without the folder/mount point.  Here are some of my test results:

/lfs/boot_count               MGMT_ERR_ENOENT
/lfs/boot_count.              MGMT_ERR_ENOENT
/lfs/boot_count.txt         MGMT_ERR_ENOENT
/lfs/boot_count.000       MGMT_ERR_ENOENT
/lfs/boot_count.0000     MGMT_ERR_ENOENT
/boot_count                    MGMT_ERR_ENOENT
/boot_count.                   MGMT_ERR_ENOENT
/boot_count.txt              MGMT_ERR_ENOENT
/boot_count.000             MGMT_ERR_ENOENT
/boot_count.0000           MGMT_ERR_ENOENT
boot_count.0000            MGMT_ERR_EINVAL
boot_count.000               MGMT_ERR_EINVAL
boot_count.txt                MGMT_ERR_EINVAL
boot_count                      MGMT_ERR_EINVAL

Also tried to escape the ‘/’:

//lfs//boot_count            MGMT_ERR_ENOENT
//boot_count                   MGMT_ERR_ENOENT
\\lfs\\boot_count            MGMT_ERR_EINVAL

Can anyone explain how the file storage and data is configured, and what my App developer needs to be searching for in order to be able to read the info I am storing on my device?

Cheers,

Mike

  • Hi Mike,

    MGMT_ERR_ENOENT is what you would get if you try to open a file that does not exist, so the path or mount point seems to be wrong.

    If you don't make progress, I suggest experimenting a bit with the SMP Server Sample. That support a number of different backends, including Bluetooth and serial. For instance, by taking that sample from nRF Connect SDK SDK 2.1.2 and building with two additional configuration files (overlay-fs.conf and overlay-serial.conf) I got a working sample that makes it easy to demonstrate. Here I am both writing and reading back a file using mcumgr (serial here for simplicity, but the transport should not matter):

    $ echo "Test test" > test.txt
    $ mcumgr -c acm0 fs upload test.txt /lfs1/test.txt
    10
    Done
    $ mcumgr -c acm0 fs download /lfs1/test.txt test_readback.txt
    0
    10
    Done
    $ cat test_readback.txt 
    Test test
    

    PS: The first time you use a COM port with MCUmgr with a serial port you need to configure it. For my setup this was right, but you may need to do something differently:

    mcumgr conn add acm0 type="serial" connstring="dev=/dev/ttyACM0,baud=115200,mtu=512"

    Einar

  • Hi Einar,

    Thanks - turns out my App developer was doing something wrong.  We've got this part of it working now.

    A question for you on using lfs - we are trying to log data into the file storage so that we have a record of events.  Our hardware spends most of its time in SYSTEM_OFF mode.  When triggered by a GPIO, it will wake up, record date/time and event type and event value, write this to file storage, then go back into deep sleep.

    I'm still building all this functionality, but what I wanted to know is whether its possible to append new data to the existing data within my file on littlefs, or do I need to read in the contents of the file into a local struct, update the data, then write the whole lot back to the file before going back into deep sleep?

    Cheers,

    Mike

  • Hi Mike,

    I am no littlefs expert, but if I understand the question correctly, then yes, you can append as well as update or overwrite (parts of) files, or a combination of that. (This is conceptually seen from the littlefs APIs though, so when you close the file and it is actually written to flash, it will be re-written to a new physical location).

Related