ARMmbed / ARMmbed/flashiap-driver

Confusing documentation

Open
#7 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
5
Forks
3
PR merge metrics
No merged PRs in 30d

Description

I am trying to see if it is possible to use an nRF52 board (actually a UBLOX NINA-B112) and its internal flash to store the BLE Keys for bonding on power reset. The documentation is a bit confusing/fuzzy. It states:

> This driver should only be used on platforms where the FlashIAP implementation is using external flash or in conjunction with a filesystem with wear leveling, that can operate on a page size granularity.

First off, why does a platform require the FlashIAP implementation to use external flash? Doesn't this defeat the entire purpose of using In Application Programming to use the internal flash of the processor? I was under the impression from reading the documentation of FlashIAP, that it uses the internal flash to do reads and writes. So what does having external flash have anything to do with the FlashIAP?

Secondly, it states I need to use a filesystem with wear leveling that can operate on a page size granularity. I would need a FileSystem to mount the FlashIAPBLockDevice in order to use the internal security manager that is built in to store the BLE keys for you. If I used the LittleFileSystem wouldn't I get the wear leveling? Not sure about the page size granularity though.

My point is if I don't have external flash available on the NRF52, will I be able to use this FlashIAP driver with the LittleFileSystem in order to store bonded keys (to be used on resets) using the BLE Security Manager?

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading the FlashIAP, FlashIAPBlockDevice, and LittleFileSystem documentation referenced in the issue, then trace how the BLE Security Manager stores bonded keys on an nRF52. Clarify whether internal flash is supported, what external flash and page-size granularity mean, and whether LittleFileSystem provides the required wear leveling; document the supported setup and limitations.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
embedded-iot
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.