Electronics > Microcontrollers

STM32 interrupt affecting functionality of FatFS (Elm Chan)

(1/3) > >>

Hi everyone,

I am currently working on a project where NOR External Flash is connected to the MCU via QSPI. I am utilizing FatFS (Elm Chan) to store data in memory as files. When data access is needed, a USB connection between the device and PC enables the device to function as a Mass Storage Device.

However, I am encountering an intermittent issue where FatFS stops working, returning an error code of FR_INVALID_OBJECT. This error is difficult to replicate consistently, but I suspect it might be caused by a frequently called ISR. Additionally, I joined this project at a later stage and discovered that this ISR is unusually long. My plan is to eventually optimize the ISR by moving certain tasks to the main program execution to shorten it, though this is not my immediate priority.

Do you think that ISR could be causing this or there is something else I should be looking for ?

Did you try disabling the ISR to see if the error continues to occur?

Yes, when I disable this long IRQ then device appears to be working but I can't be sure as the issue is random. Sometimes device can work up to an few hours without any issues and sometimes it happens after few minutes.

This is what I found on the FatFS document web-site:

--- Quote ---If a write operation to the FAT volume is interrupted due to an accidental failure, such as sudden blackout, wrong media removal and unrecoverable disk error, the FAT structure on the volume can be broken.
--- End quote ---

This is in case of media removal and similar situations but I was wondering can this happen because of the long IRQ. Maybe IO driver somehow fails and I get the same issue as reported here. One thing I notice is that the File System is broken after this issue and I see a lot of dummy files with strange names.

Just to clarify, are you using FatFS at the same time as the host is connected via USB? If so, then this is not something that would ever work.

If FatFS and USB access to the flash is separated, then what specific interrupts you think cause this?

Are you writing the FLASH device within the ISR? I went around this a while ago and posted loads here :)


The simplest way to implement FatFS / USB MSC is to do the whole FLASH write inside the ISR so that ISR may hold up lower priority stuff for the write time which might be say 15ms! But apparently (see the various threads of mine) this is what SD cards do and it is the max compatibility mode.

The "proper solution" is to write a "driver" for the FLASH (or equiv) so that the USB MSC ISR is short, but this is really hard unless you have tons of RAM for caching writes, or you return a Busy state to the Host so it keeps retrying (which is poorly documented and often doesn't work).

--- Quote ---are you using FatFS at the same time as the host is connected via USB? If so, then this is not something that would ever work.

--- End quote ---

Why not?

The USB MSC stuff is done in the USB ISR. The Host (Windows usually) just sees a block device, 512 byte blocks (best done with a FLASH which actually has 512 byte blocks, obviously, but you can do blocking/deblocking as in hard disks) and knows nothing about the embedded code.

The internal filesystem access is done with FatFS which provides the embedded code with a file-based "view" of the block device. Usually FAT12 unless you have 8MB or more, IIRC, and then FAT16.

There will always be things to watch if both internal code and USB MSC are active concurrently, but there are ways to handle that. These are notes from my project manual:


The 2MB FAT filesystem is accessible to both a user application program running in the XXX and via USB as a removable mass storage media visible to the USB Host (Windows etc).
Read speed varies from 300kbytes/sec to 2Mbytes/sec, depending on various factors. Write speed is around 30kbytes/sec - the FLASH programming speed.

File System Limitations
The 4MB FLASH device has an endurance of 100k writes, on a per-byte basis. The FAT directory area is written on every file write and this thus gets the most wear. Care must therefore be exercised when writing code which does file write operations. There is no limit on reading operations since no "last-accessed" timestamp gets written - FAT12/FAT16 file systems have only the "last-modified" timestamp.
Only "8.3" filenames (names in the format xxxxxxxx.xxx) are supported e.g.
but not filename2.txt3 because >8 or >3 in the filename and the extension, respectively, are not allowed. Wiki article: https://en.wikipedia.org/wiki/8.3_filename

However, nothing stops a USB Host (e.g. Windows) creating whatever filenames and directory structures it is able to according to its own operating system limitations. Within the FAT12 drive it can create more or less anything. If the Host creates a non-8.3 filename, it will be visible to user code under its 8.3 alternate filename which the Host must create, by convention.

All files accessible to user code must be in the root of the drive. Subdirectories (folders) are not supported. If a USB Host creates a subdirectory, this will not be accessible to user code although its name will be visible to the get_file_list() and get_file_properties() functions.

Host Operating System Caching issues
It is important to realise that the USB Host sees the 2MB of FLASH as no more than a number of 512 byte sectors representing a FAT12 removable storage device, which it owns entirely. It can perform whatever operations it wants to in there, without regard to whether the XXX internal software understands it. The XXX system software is viewing this 2MB FLASH block from the other side and uses the FatFS embedded filesystem module
to interpret the data as a FAT12 filesystem.

Looking at this in the opposite direction (XXX to USB Host), files created or modified by the XXX do not immediately become visible to the USB Host. This is due to Host operating system architecture; for example Windows assumes nobody else is changing the data on a removable drive, and almost never checks for changes. It checks if it detects that the media has been removed or mounted. See file_usb_eject() and file_usb_insert() functions on how to make XXX file changes visible to the USB Host.

Files created or modified by the USB Host should become visible to XXX code immediately, assuming the data is actually written and the directory updated. This does not always happen because the OS may not flush the data to the USB drive. This was particularly true for older versions of Windows (before winXP).

Filenames are not case-sensitive. All filenames created by user applications are converted to uppercase.
The FLASH device used for the filesystem implements a per-sector pre-read on writes and performs the write only if the data is different. This increases the write speed by around 50x if the data has not changed. It can sometimes appear confusing in that a file writes extremely fast; this is because is has not been changed, or only a few bytes were changed! This is sometimes visible with XXX firmware updates.


My FatFS build was for 8.33 only, no LFN, and there were complicated reasons for that related to RTOS usage. Frankly no embedded code needs LFN anyway :)

There are ways to do a concurrent access filesystem but not with a removable USB device profile. You need to implement an ethernet storage device, IIRC, like a Synology network drive.


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod