search

aloebs29 / flash_management

Flash management stack for the STM32L432KC MCU and MT29F1G01ABAFDWB SPI NAND flash chip.
MIT License
29 stars 16 forks source link

I'm implementing fatfs on my nand flash MT29F4G01ABAFDWB #4

Open Tejas1017 opened 4 months ago

Tejas1017 commented 4 months ago

Hi, I'm trying to implement fatfs on my nand flash MT29F4G01ABAFDWB, i have wrote low level drivers (im using zephyr rtos). i just want to implement fatfs without an layer that you used in Ur project called dhara , can please give me suggestion or any example that you have referred, that would be really helpful.

aloebs29 commented 4 months ago

You will need some layer between FATFS and your NAND flash device that does wear levelling and bad block management on your flash. Trying to use a FAT file system directly on top of a NAND part will not work well as these memory devices typically ship with some bad blocks, and their write endurance is pretty low (so e.g. your file allocation table will hit that endurance limit pretty quickly).

Dhara was the best solution I found when looking into this. If I recall correctly, Zephyr does not have any flash translation layer suitable for NAND flash (although they might for NOR). Some RTOS'es do support this functionality, notably ThreadX has LevelX.

Tejas1017 commented 4 months ago

thanks for response, in the code, you have a function hdr_get_epoch, and I'm curious about where the magic number used in this function is defined or used. Could you explain where you put that magic number in your code? where in you code you have stored that magic number in your flash

aloebs29 commented 4 months ago

That function actually lives inside of the dhara flash translation layer, so I'm not entirely sure. I didn't touch that library -- just provided the underlying NAND operations. I would recommend checking out that repo's documentation if you're curious about the inner workings.

Tejas1017 commented 4 months ago

Screenshot from 2024-07-31 12-17-45 i'm getting this logs, any suggestion you can give that would be really helpful.

aloebs29 commented 2 months ago

Sorry for the slow response -- so the first mount failing would be expected the first time you run this on a flash device (as no file system exists at that point), hence the fallback to a f_mkfs call. The fact that the f_mkfs call succeeded does not necessarily mean that your underlying flash interactions are working as intended. The subsequent f_mount failing indicates that the underlying flash interactions are not working as intended.

A common failure that folks have reported when adapting this repo to their own projects is related to multi-planar NAND devices. My implementation only supports single-planar NAND devices. Check the other issues (including the closed issues) in this repo for discussions (and examples).