Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

When using the FatFs module's f_getfree to retrieve the remaining capacity, the correct value cannot be obtained immediately after mounting.

I am trying to retrieve the remaining capacity using the f_getfree function in the FatFs module, but I cannot get the correct value immediately after calling f_mount. After using the system for a while, it eventually becomes possible to retrieve the correct value at some point.

Here are my questions:

(1) Since I assume the FAT should be in a clean state immediately after mounting, why can't I get the correct value right away?
(2) What should I do to ensure the correct value is retrieved?

Parents
  • Hi Koji, 

    As I understand, this question is not directly related to Nordic as  you are asking about the FATFS module which we don't own. 
    I did take a look in the documentation for the f_getfree () function: 
    The f_getfree function gets number of free clusters on the volume. The member csize in the filesystem object indicates number of sectors per cluster, so that the free space in unit of sector can be calcurated with this information. In case of FSINFO structure on the FAT32 volume is not in sync, this function can return an incorrect free cluster count. To avoid this problem, FatFs can be forced full FAT scan by FF_FS_NOFSINFO option.

    Could check if it's the sync problem ?

Reply
  • Hi Koji, 

    As I understand, this question is not directly related to Nordic as  you are asking about the FATFS module which we don't own. 
    I did take a look in the documentation for the f_getfree () function: 
    The f_getfree function gets number of free clusters on the volume. The member csize in the filesystem object indicates number of sectors per cluster, so that the free space in unit of sector can be calcurated with this information. In case of FSINFO structure on the FAT32 volume is not in sync, this function can return an incorrect free cluster count. To avoid this problem, FatFs can be forced full FAT scan by FF_FS_NOFSINFO option.

    Could check if it's the sync problem ?

Children
  • I understand that the FSINFO sector may sometimes contain unreliable values.

    I tried setting FF_FS_NOFSINFO to 2 and 3, but I still couldn't get correct values. When set to 2 or 3, the operation takes tens of times longer compared to when it's set to 0, so it seems that a FAT scan is indeed being performed.

    Could the quality of the SPI bus signals on the custom board be affecting this?

  • As I continued investigating, it seems that putting the CPU to sleep using __WFI causes issues in retrieving values properly afterward. However, after trying several times, it sometimes works again, so I really don’t understand what’s going on. Could putting the CPU to sleep during SPI communication have any negative effects?

Related