weston-embedded / uc-fs Goto Github PK

I have an application using Micrium FS with journaling disabled, running in a STM32F750 MCU.
The file system runs in a NOR Flash 32MB.
I have no issues using the file system inside the microcontroller.
However, the same NOR Device is accessed by USB in MSC Class. A standard flash unit is mapped in Windows or MacOS.
The problem is that Windows/Mac does not recognize the volume formatted by micrium and vice-versa. Micrium cannot recognize the volume formatted by Micrium.
In the AddNOR function, Micrium always detects some blocks as invalid (random number of blocks) and mark the flash to be low level formatted.

I tryied to Google for this problem or related without results.
Is there any kind of incompatibility of Micrium FAT with the standard FAT that makes impossible to Windows/MacOS to recognize the partition/volume?
Is there something I'm missing here?

Now I need a romFS， Can I use uC-FS to implement it？
Is there an example?

It is not an issue in fact, but I wandered how to support hardware ECC, maybe some changes should be a better way to support HW ECC.

Current source code logic in fs_dev_nand_ctrlr_gen.c:SecWr,

1. write sector data
2. calculate ECC of sector + OOS data (p_ctrlr_data->CtrlrExtPtr->ECC_Calc)
3. SparePack OOS data
4. write OOS to OOB (ECC included after OOS)

I suppose the following process can be followed to support HW ECC:

1. write sector data
2. SparePack OOS data
3. write OOS to OOB
4. p_ctrlr_data->CtrlrExtPtr->ECC_Calc
   in this callback function, get ECC from HW like STM32 MCU FSMC register (it calculates ECC for each certain bytes data written)
5. write ECC to OOB

With these changes, both software ECC and HW ECC can be supported.

I don't know if it makes sense. Thanks!

if (end_of_file == DEF_NO) { /* If EOF not found, too many clus's in chain ... /
FS_TRACE_INFO(("FS_FAT_ChkFile(): Extra clusters linked to file.\r\n"));
/ ... #### del extra clus's. */
}

Whether to support bad block management?

How can I port this library for stm32? I want use this library instead of elmchan-FATFS

The read/write driver sometimes passes an unaligned reference, which causes DMA to write data at an offset.
In FS_FAT_FileRd function if reading from other than the beginning of sector is required:

if (sec_cur_pos != 0u) {
        FSVol_RdLockedEx
...
p_dest_08 += size_rd; //the pointer may not be aligned!
...
 while (size_rem > 0u) //and if a whole sector should be read next
...
FSVol_RdLockedEx( p_file->VolPtr, /* Rd full sec's.         */
                             (void *)p_dest_08 //then we transmit non-aligned address for reading

If we read/write sectors using DMA then data will be read at an offset.

I worked around it this way: in SD card driver I check if the address is aligned, if it is - pass it to DMA as is, otherwise - use a temporary buffer of one section size. then I just copy data from it to my non-aligned buffer

The same thing happens when you write

This may not be a file system problem but a driver problem.
And maybe you have a better solution

Sometimes buffers supplied from driver functions aren't aligned at address multiples of FS_CFG_BUF_ALIGN_OCTETS (from fs_cfg.h).
A couple of examples:

• FSDev_SD_Card_SetBusWidth() passes the buffer "scr" to FSDev_SD_Card_SendSCR(), which is eventually passed to my FSDev_SD_Card_BSP_CmdStart() function. "scr" is allocated on the stack and not aligned.
• FSDev_SD_Card_SetBusWidth() passes the buffer "sd_status" to FSDev_SD_Card_SendSDStatus(), which is eventually passed to my FSDev_SD_Card_BSP_CmdStart() function. "sd_status" is allocated on the stack and not aligned.