nanoframework
F7 series FileIO caching issue
Environment: STM32F76xx with micro sd card, nanoclr 1.3.0.3. (Note: this issue is seen on microsd file, I did not test it on flash) Repro steps:
- On the micro sd card, create a simple file with a few text using notepad or vi on your computer.
- Place the sd card on the board
- Try to read the file using FileIO.ReadFile()
- The result is empty string
Another way to test it is to run the Scenario3_WriteAndReadTextInAFile.cs from sample repo. The last section of the codes compares the written and read strings and they are different, which is not expected.
This occurs in the STM32F7 series because of caching issues. It works just fine on STM32F4 and other that don't have cache.
Issue has been raised in ChibiOS forum and a possible fix discussed. Waiting from a follow from their end. Post here.
Update from ChibiOS issue and not what we would like to hear: they wont be providing a fix for this.
This requires patching or a fix implemented at our end.
@josesimoes I would recommend we either use the version in the contrib repo and patch that, or have a seperate repo for fatfs (perhaps shared with freertos targets... thoughts?
It might also be worth getting in touch with the author of fatFS to see if he would like to fix the core officially
The required fix is very target specific so I don't thing there is nothing to be "fixed" upstream… It's really up to us.
My 1st thought is to have our FatFS glue layer for ChibiOS to take care of these tiny details.
@josesimoes any further thoughts on this?
perhaps https://community.st.com/s/question/0D50X00009fFoAe/stm32f7-sdcard-access-from-qspi-image and https://github.com/micropython/micropython/issues/1677 could be of help?
At this times I think the best option is to patch the (already) modified Fats from ChibiOS. The remedy is clear: clear and flush cache on write and read operations. Exactly the same that what coded for the Spiffs driver for F7 (see Orgpal3 board).
The root cause is definitely the combination of DMA and F7 cache. DMA can't be disabled, so...
PR submitted for this, but needs checking against targets other than F7...
There is some good advice on how to align DMA buffers in the description of http://elm-chan.org/fsw/ff/doc/dread.html and another possible (although probably less desirable) fix at https://os.mbed.com/users/NirT/code/F7DISCO_Demo/file/c00e6c923941/patch/FatFs/st_readme.txt/
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
Reading files has been no issues for me in quite a while! however I have not been able to test writes. Is this still an issue???
Yes, the latest image when using write, it fails in some cases. For example, I had to add some pause to make it work with the latest image:
var myFile = media.CreateFile($"BackUP_{DateTime.UtcNow.Millisecond}.txt", CreationCollisionOption.ReplaceExisting); Thread.Sleep(256); FileIO.WriteText(myFile, currentConfig);
without the extra timeout between these calls, the WriteText would fail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Windows.Storage.Devices will soon be deprecated. This issue needs re-evaluating for System.IO.FileSystem.
Windows.Storage.Deviceswill soon be deprecated. This issue needs re-evaluating forSystem.IO.FileSystem.
The caching issue is at mcu level so the behaviour is there independently of the managed library wrapping it.
It seems that something like this needs adding to the mcuconf.h file:
/*
* Memory attributes settings.
*/
#define STM32_NOCACHE_ENABLE TRUE
#define STM32_NOCACHE_MPU_REGION MPU_REGION_6
#define STM32_NOCACHE_RBAR 0x30010000U
#define STM32_NOCACHE_RASR MPU_RASR_SIZE_64K