I am using FreeRTOS version 9.0.0 and FreeRTOS+FAT version 160919 to work with SD card and USB flash drive on LPC1788.
During testing I noticed that if unplug any connected drive and then plug in again it causes lost 40 bytes from the FreeRTOS heap.
The research showed that:
In function FFCreateIOManger (file ffioman.c) structure pxIOManager allocated by ffconfigMALLOC (line 141), then at line 156 allocated EventGroup (those 40 bytes) and its handle is stored in the structure pxIOManager.
Next, in function FFDeleteIOManager structure pxIOManager freed by ffconfigFREE, but previously allocated EventGroup is not freed before it and EventGroup handler is lost. So at the next time you call FFCreateIOManger will create a new EventGroup. It means heap memory leakage by 40 bytes in every reconnect the drive.
It seems that in function FF_DeleteIOManager need to freed EventGroup and make it before freed a structure pxIOManager.
Is that right?
Thanks for the information - will get fixed.
Thank you! When can we expect new release? The last one was more then year ago...
The latest +TCP code, which has evolved a bit since the same release you
are referring to, is now in the main FreeRTOS SVN repository accessible
via SourceForge - with the intent of having it in the main release next
time. We may (?) do the same with the fat code, not sure.
When can we expect new release? The last one was more then year ago...
That's a good sign, there were very few changes since one year ago :-)
But I will prepare a new release, either in the form of a patch, or on sourceforge.
I will come back to this.
Ок, thanks, will wait with impatience!
Hi Sergey, in order not to let you wait: please find attached a patch since 2016 Sep 19.
This is a quick release, not an official one.
A summary of the changes made in the above
0001-Changes-since-160919.patch for FreeRTOS+FAT.
Note that all changes are intended to be downward compatible.
FF_FileSize() can only handle sizes up to 2GB because it returns a signed value.
Old : int32t FFFileSize( FFFILE *pxFile )
New : FFErrort FFGetFileSize( FFFILE *pxFile, uint32t *pulSize )
The old function is still there.
ff_stdio.c) already returned an unsigned value
It will now also call
FF_GetFileSize() to obtain the size.
If it returns
stdioGET_ERRNO() can be called to see if there was an error.
FF_ExtendFile() always immediately called
FF_FlushCache() which is sometimes not desirable.
This will now be configurable with
ffconfigFILE_EXTEND_FLUSHES_BUFFERS, default defined as
#if( ffconfigFILEEXTENDFLUSHESBUFFERS != 0 )
xTempError = FF_FlushCache( pxIOManager );
if( FF_isERR( xError ) == pdFALSE )
xError = xTempError;
#endif /* ffconfigFILE_EXTEND_FLUSHES_BUFFERS */
Some users don't like this automatic flushing of FAT sectors. In stead they want to call
FF_FlushCache() them selves, or wait until
FF_fclose() is being called, which will call
ff_stdio.c) did not work properly on files larger that 2GB.
The offset parameter of
ff_fseek() is a signed 32-bit long:
int ff_fseek( FF_FILE *pxStream, long lOffset, int iWhence )
With this patch :
iWhence = FF_SEEK_SET : lOffset is interpreted as a `uint32_t`
iWhence = FF_SEEK_CUR : lOffset is interpreted as a a signed offset
iWhence = FF_SEEK_END : lOffset must be <= 0
FF_Partition() : Make sure that
ulHiddenSectors is at least 1
FF_CreateIOManger() would call
FF_CreateEvents(), event if
pxIOManager equals NULL
When it fails to create a
pxIOManager, it should not proceed to create the event group.
FF_DeleteIOManager() caused a memory leak, the field
pxIOManager->xEventGroup was not deleted
FF_FlushCache() now has a use hook
See comments in ff_ioman.h
Some users want to perform special actions each time when the +FAT data buffers have been flushed to disk.
FF_Mount() : The field
pxPartition->pcVolumeLabel didn't get zero-terminated
FF_IncreaseFreeClusters() could get blocked under certain circumstances
It was trying to take a lock that was already taken.
ff_sys.c completely tested and updated
This module was rewritten and tested with frequent calls to
FF_FS_Remove() in a random order.
ff_sys.c makes the mapping between the so-called I/O managers and the (virtual) maps where they get mounted.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.