Understanding the MOD5441X file system

[SeeCwriter]

A few years ago I needed to reserve space in the MOD5441X flash memory for SNMP files. Following an example program, I modified the memory range from:

0xC0040000 0xC2000000

to:

0xC0040000 0xC1F80000

This should have reserved 512k for the file system.

I'm looking at this again because if I use SSL, the certificate and key are also stored in this file system and I want to make sure I have enough room.

I used function FS_DisplayEffsSpaceStats() from file FS_FileSystemUtils.cpp from one of the example programs:

Code: Select all

BYTE FS_DisplayEffsSpaceStats()
{
   FS_SPACE space;
   volatile int rv;
   iprintf( "Retrieving flash usage...\r\n" );
   rv = fs_getfreespace( fs_getdrive(), &space );

   if ( rv == FS_NOERR )
   {
      iprintf( "EFFS Flash memory usage (bytes):\r\n" );
      iprintf( "%lu total, %lu free, %lu used, %lu bad\r\n", space.total, space.free, space.used, space.bad );
   }
   else
   {
      iprintf( "\r\n*** Error in fs_getfreepace(): " );
      FS_DisplayEffsErrorCode( rv );
   }

   return rv;
}

The output is:

Retrieving flash usage...
EFFS Flash memory usage (bytes):
131072 total, 121856 free, 9216 used, 0 bad

Why is it reporting a size of only 131072?
What is the size of the certificate and key files?

Using v2.9.4 of the tools.

[pbreed]

Where are you changing you addresses?

[SeeCwriter]

Through the Eclipse project settings: C/C++ Build/Settings/Tool Settings/NetBurner Compcode/General

[TomNB]

Changing those values just reserves space. You need to edit the MX29GL256F.h and set the parameters correctly (if you based your code on the example in \nburn\examples\StandardStack\EFFS\EFFS-STD-HTTP). Take your time and make sure you read through all the settings and comments, otherwise you may corrupt the flash or get inconsistent results. The effs std example allocates 1MB. I would check your allocation sizes with the fsmem.exe utility in pcbin. A second manual on how the fs works, as well as fsmem, is in \nburn\docs\EFFS\EFFS-STD-R1p91.pdf.

[SeeCwriter]

Correct. I copied MX29GL256F.h to my project directory and modified it by replacing the defines for FS_SIZE and DESCSIZE as shown below. Did I do it incorrectly?

Code: Select all

/* WARNING: These settings are for MX29GL256F bottom boot block flash
 * components used on the Mod54415 and Mod54417.
 */
#define BLOCKSIZE  ( 128*1024 )   // flash physical "sector" size
#define SECTORSIZE ( 1*1024 )     // file system sectors per BLOCK
#define SECTORPERBLOCK (BLOCKSIZE/SECTORSIZE)

/*
 * Specify the total amount of flash memory in the system, and the amount
 * allocated to be used by the file system (the rest is used by the
 * application.
 */
#define FLASH_SIZE ( 32*1024*1024 )       // size of total flash in the system, 32MB
//#define FS_SIZE    ( 25*1024*1024 )       // amount allocated to file system, including descriptor blocks
#define FS_SIZE    ( 4*BLOCKSIZE  )       // amount allocated to file system, including descriptor blocks
                                          // note that 1 block of file data will be reserved for the file system
#define FIRST_ADDR (FLASH_SIZE - FS_SIZE) // first file system address to use in the flash
#define BLOCKSTART 2                      // first block where file system data starts
                                          // (first 2 blocks are DESCRIPTORS)


/*
 * Descriptor Blocks:
 * These blocks contain critical information about the file system, block allocation,
 * wear information and file/directory information. At least two descriptor blocks
 * must be included in the system, which can be erased independently. An optional
 * descriptor write cache may be configured which improves the performance of the
 * file system. Please refer to the EFFS-STD implementation guide for additional
 * information.
 */
//#define DESCSIZE ( 128*1024 )      // size of one descriptor
#define DESCSIZE ( BLOCKSIZE )     // size of one descriptor
#define DESCBLOCKSTART 0           // position of first descriptor
#define DESCBLOCKEND 1             // position of last descriptor
#define DESCCACHE 2048

[TomNB]

I can't be certain, I have not seen the fs size defined that way. What values did the fsmem utility tell you to use? This is something you should probably open a support ticket for, so they can go through the numbers and test an example for you. Wouldn't the 1MB as specified in the example be enough?

#define FLASH_SIZE ( 32*1024*1024 ) // size of total flash in the system, 32MB
#define FS_SIZE ( 1280*1024 ) // amount allocated to file system: 2 Desc. plus 1MB for data (8 x 128k)

If not, support can modify the parameters for the space you need

[SeeCwriter]

fsmem is very confusing. I'm not even sure what it's supposed to be calculating.

The value of FS_SIZE in the example I used (from v2.8.3) was 25*1024*1024 which, according to my calculator, is 26.2Mbytes. Not sure how that turns into a 1Mbyte file system.

The example from v2.9.4 of FS_SIZE = 1280*1024 calculates to 1.3Mbytes which would be fine. But that doesn't explain why my define of FS_SIZE to 4*128*1024 does not result in a file system size of 512k.

Regardless, if I revert back to the original #define in v2.9.4 for a 1.3MB file system, what does that do to the files that are already there in fielded units? Do they get corrupted?

[TomNB]

Hello,

I'm not sure what example you used, but I just checked the 2.8.3 archive, and the effs-std example has the following definitions for a 1.3MB file system:

#define BLOCKSIZE ( 128*1024 ) // flash physical "sector" size
#define SECTORSIZE ( 1*1024 ) // file system sectors per BLOCK
#define SECTORPERBLOCK (BLOCKSIZE/SECTORSIZE)

/*
* Specify the total amount of flash memory in the system, and the amount
* allocated to be used by the file system (the rest is used by the
* application.
*/
#define FLASH_SIZE ( 32*1024*1024 ) // size of total flash in the system, 32MB
#define FS_SIZE ( 1280*1024 ) // amount allocated to file system: 2 Desc. plus 1MB for data (8 x 128k)


Now lets look at your settings:
FS_SIZE is 4 * 128 * 1024 for a total file system size of 512K bytes.

The two file descriptors, which hold the directory information:
#define DESCSIZE ( BLOCKSIZE ) // size of one descriptor

And there are 2 of them, 0 and 1, so BLOCKSIZE = 128k time 2 = 256k. You always need 2 physical flash sectors for an embedded flash file system so it can be power fail safe and erase one while maintaining the other. For a 32MB flash chip, 128k per physical sector is normal.

This leaves 512k - 256k = 256k (2 128k physical sectors) for the file system data. One flash block in the file system data area is required to be free, again for power fail safe purposes. So out of the 4 sectors allocated for the total file system usage, 2 are descriptors, 1 free for file manipulation, leaving only 1 128k block for file storage, which is what the free space function is reporting.

For the 1MB file system in the example that I can see, the same overhead of 3 128k blocks is plenty of room. So that would be
10 total blocks (physical sectors)
2 descriptors
1 free for file manipulation
7 left for file storage: 7 * 128k = 917,504 bytes (896k bytes)

You can even make the file system much larger without adding additional descriptors, although I would use fsmem to verify the sectorsize within a block (in these examples it is 1k).

If you change any of these parameters, the file system will need to be reformatted.

[TomNB]

There is a much more detailed description of all these things in \nburn\docs\effs\EFFS-STD-R1p91.pdf

[TomNB]

I do have one thought on how you may be able to do field updates, but it would definitely have to be tested to see if it would work. There is a 128k flash sector set aside for bulk storage (no file system). It might be possible to write an app with your 128k file system that copied information to the User Param flash area, then run a second app with a bigger file system and copy the data from User Params to your files. You would need to run some tests to see if it is feasible for you.