Half size of flash

[robzed]

In the code below, it appears to set up 256K worth of Flash, but start the flash block device at 512K.

Does this mean there is only the 0-0.5M for code/data? What happens to the other 256Kbytes?

Did you ever find out why it was crashing?

#define NANO33BLE_FS_SIZE_KB 256

Inside FS_Nano33BLE.h:

// nRF52840 flash address from 0, length 1MB.
// Better to use max half of flash for LitleFS, must be 0x80000 (512KB)
// FLASH_BASE must be 0x80000, or crash !!!????
#define FLASH_BASE            0x80000

#if USING_LITTLEFS
  static mbed::LittleFileSystem fs(MBED_FS_FILE_NAME);
  static FlashIAPBlockDevice wholeBD(FLASH_BASE, 0x80000);
  static FlashIAPBlockDevice bd(FLASH_BASE, (NANO33BLE_FS_SIZE_KB * 1024));

[khoih-prog]

Hi @robzed

Thanks for your interest in the library and your discussion, which help me to recheck the library using the latest ArduinoCore-mbed core v2.6.1.

The mentioned crash issue has been somehow fixed by the core (I don't have time to check how and where) and now I can use the correct Flash Address start without wasting any flash space.

For example

#define NANO33BLE_FLASH_SIZE         (1 * 1024 * 1024)
...
#define NANO33BLE_FS_START           (NANO33BLE_FLASH_SIZE - (NANO33BLE_FS_SIZE_KB * 1024))
...
static FlashIAPBlockDevice bd(NANO33BLE_FS_START, (NANO33BLE_FS_SIZE_KB * 1024));

That means if you're using only 64KB of Flash for LittleFS, the reserved flash will be only the last 64KB of 1MB Flash. The remaining 1024-64 = 960KB of Flash will be free to use for your program and/or other purpose.

I'll published a new release to reflex this new useful update.

As you know, I currently have too many libraries to manage, update and create, and normally wouldn't have time to recheck the written libraries, unless there are some known bugs or issues reported by users.

The library will be better and better thanks to contributing users like you.

[robzed]

Many thanks for your answer and your work. Every little bit helps makes it easier to use a file system on this chip - although it's theoretically possible to go directly to mbed, as you found, often there is difficulties - so libraries like this one are very important.

For your information I plan to use it in this project: https://github.com/robzed/Nano_33_BLE_Forth - originally I was writing basic Forth BLOCKS support, but half way though I figured I might as well make things easier for myself and use a file system.

[khoih-prog]

Hi @robzed

The new FS_Nano33BLE releases v1.2.0 has just been published. Your contribution is noted in Contributions and Thanks

Please have further test and confirm the issue has been fixed for LittleFS.
There is still issue with FATFS, but I don't have time to find out what wrong with the core yet. Any help is appreciated.

Best Regards,

---

Releases v1.2.0

1. Use correct NANO33BLE_FS_START address without wasting flash space. Check Half size of flash #2
2. Enforce min 64KB / max 512KB of flash used for LittleFS by auto-adjusting NANO33BLE_FS_SIZE_KB if defined smaller than 64KB or larger than 512KB
3. Enforce 512KB of flash used for FATFS by auto-adjusting NANO33BLE_FS_SIZE_KB if defined different from 512KB
4. Update all examples

[khoih-prog]

Just have a quick look at your promising Nano_33_BLE_Forth.

As you correctly said, using FS, even from a wrapper library like this one, is much easier for any users to use your library in the future.

Scanning thru your code, I can see you have very good experience dealing directly with mbed, core, etc. It's extremely helpful and appreciated if you can help solving the FATFS (even it can be deprecated now) crash issue when we use less than 512KB size.