nanoframework / Home

:house: The landing page for .NET nanoFramework repositories.
https://www.nanoframework.net
MIT License
846 stars 75 forks source link

F7 series FileIO caching issue #534

Open hololite opened 4 years ago

hololite commented 4 years ago

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:

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.

hololite commented 4 years ago

Typo above. Should use the FileIO.ReadText API to read the file.

josesimoes commented 4 years ago

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.

josesimoes commented 4 years ago

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.

networkfusion commented 4 years ago

@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?

networkfusion commented 4 years ago

It might also be worth getting in touch with the author of fatFS to see if he would like to fix the core officially

josesimoes commented 4 years ago

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.

networkfusion commented 4 years ago

@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?

josesimoes commented 4 years ago

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...

networkfusion commented 4 years ago

PR submitted for this, but needs checking against targets other than F7...

networkfusion commented 4 years ago

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/

stale[bot] commented 4 years ago

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.

networkfusion commented 4 years ago

Still valid!

networkfusion commented 4 years ago

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???

gligorov commented 4 years ago

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.

stale[bot] commented 4 years ago

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.

josesimoes commented 3 years ago

Still valid

networkfusion commented 2 years ago

Needs revisiting with the new API and later targets.

networkfusion commented 2 years ago

Windows.Storage.Devices will soon be deprecated. This issue needs re-evaluating for System.IO.FileSystem.

josesimoes commented 2 years ago

Windows.Storage.Devices will soon be deprecated. This issue needs re-evaluating for System.IO.FileSystem.

The caching issue is at mcu level so the behaviour is there independently of the managed library wrapping it.

networkfusion commented 2 years ago

image

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