Hi Raghid, I included your bug fix in a pull request over at GitHub.

@Raghid, please use github pull requests to mbedmicro/mbed repository. Thanks for understanding

Hi Raghid, I've been working for a while on a STM32F407 USB data logger, based on FAT FS Chan R011.a lib and STM USB HOST device lib 2.2.0. I suppose I've a problem by using the F_SYNC function. In my application I've to call the F_SYNC always after the F_WRITE function to reduce data losting risk, but sometimes, the F_SYNC function takes a lot of time to flush all data, about 800 ms to flush around 80 bytes, and it's not a good behaviour for me. So I would more information about the original problem !!! Witch kind of problem this BUG FIX has solved? According you, can this BUG FIX help me to solve my problem?

Thank you, Fabio

Hi Fabio. If you look at ffconf.h, there's two extra macros: FLUSH_ON_NEW_CLUSTER and FLUSH_ON_NEW_SECTOR. Setting one or the other to 1 (not both) will cause FatFs to automatically flush periodically so you don't have to call f_sync(). The bug fix referenced here fixed an issue where the macros couldn't be disabled, so it's not related to your issue.

Hi Neil, thanks for your answer. I'm testing the behaviour of my application with macro FLUSH_ON_NEW_CLUSTER enabled and I hope this setup can help me. I tried also to use the other macro FLUSH_ON_NEW_SECTOR but I saw on debug that F_WRITE function doesn't call the internal F_SYNC, bacause the part of code where the variable "need_sync" is set to 1, is never executed. I don't know why. If it works in CLUSTER macro mode, it should work also in SECTOR macro mode, isn't it? Is possible to understand how many sectors are present on each cluster?

Thank you again, Fabio