USB Flash FatFs

lpcware · ‎06-15-2016

Content originally posted in LPCWare by renan on Mon Jun 21 06:48:28 MST 2010
Is it possible to display/erase/write the internal flash (lpc1768) contents using a file system like FatFs?

Renan

lpcware · ‎06-15-2016

Content originally posted in LPCWare by renan on Thu Jun 24 04:25:41 MST 2010

Quote: CodeRedSupport
It is simply transient and has to be recreated each time you power the board up.

That's why I sad 'fake', but it was a bad choice of word. Transient is a better choice.

Quote:

But in fact it is quite possible to create multiple files and directories there. It is just if you do, then the bootloader may well not boot the image you want it to - as it assumes that the boot image is located at the start of the user flash (at 64KB).

Assuming that the boot image is located [B]always[/B] at the start at the user flash, why it might not boot the image I want?
The only difference is that the boot image size I'm trying to create is diferent, in other words, the boot image starts at the same location, but it ends in another.

Renan

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Thu Jun 24 00:42:00 MST 2010
There is nothing fake about the FAT that the bootloader provides - it is simply transient and has to be recreated each time you power the board up. And as the bootloader doesn't know what you had previously written into flash, it sets the FAT up to represent a single file - [FONT=Courier New][SIZE=2]firmware.bin[/SIZE][/FONT] - occupying the whole of the user flash area. It is then necessary to delete this single file before you can write any new files to the bootloader's flash drive. This deletion is treated as a special case by the check for [I]user_flash_erased[/I]. Once you delete firmware.bin, deleting any other files you write to the flash will NOT erase the flash - unless you yourself modify the code to do so. It will simply mark them as erased in the FAT (using the code 0xe5).

To use the bootloader as a bootloader, it is recommended to only write a single file to the flash drive. But in fact it is quite possible to create multiple files and directories there. It is just if you do, then the bootloader may well not boot the image you want it to - as it assumes that the boot image is located at the start of the user flash (at 64KB).

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by renan on Wed Jun 23 10:24:53 MST 2010
Just adding aditional information:

When BlockDevWrite() routine is called, it tests 'user_flash_erased' variable, like this:

if(user_flash_erased == FALSE)
{
    erase_user_flash();
    user_flash_erased = TRUE;
}

it calls erase_user_flash():

prepare_sector(USER_START_SECTOR, MAX_USER_SECTOR, SystemCoreClock/1000);
erase_sector(USER_START_SECTOR, MAX_USER_SECTOR, SystemCoreClock/1000);
if(result_table[0] != CMD_SUCCESS)
{
     while(1); /* No way to recover. Just let Windows report a write failure */
}

prepare_sector and erase_sector erases the flash using IAP.

I'm using the example published in may/2010.

As far as I understood in this example, there is not a 'real' FAT file system in the flash, but it looks like because this is what the bootloader does with Windows (I mean, the bootloader tricks Windows to make it think that this device has a real file system).
If this assumption is right, I can make Windows believe that this device has more than 1 file, and when I delete it just part of the flash is going to be deleted.
Is this idea right (if I were clear enough)?

Renan

lpcware · ‎06-15-2016

Content originally posted in LPCWare by renan on Wed Jun 23 07:38:49 MST 2010

Quote: CodeRedSupport
In the RDB1768 bootloader example, the flash only gets erased when the "fake" [FONT=Courier New][SIZE=2]firmware.bin[/SIZE][/FONT] file that is created at reset is deleted. When you delete this from Windows, [FONT=Courier New][SIZE=2]BlockDevWrite()[/SIZE][/FONT] uses the check for '[FONT=Courier New][SIZE=2]user_flash_erased[/SIZE][/FONT]' to carry this out as a special case.

When I delete the 'fake' file [FONT=Courier New][SIZE=2]firmware.bin [/SIZE][/FONT]the routine [FONT=Courier New][SIZE=2]BlockDevWrite() [/SIZE][/FONT]is called, and actually erases the flash from USER_START_SECTOR 16 until MAX_USER_SECTOR 29 (I checked the memory monitor, before and after deleting the file). This means that SCSI write 10 gets called. This is where I'm trying to understand how it works, reading the SCSI Block Commands 3 (rev 12).

From what I've read so far, I know that the LBA (http://en.wikipedia.org/wiki/SCSI_Write_Commands) is going to tell me what part of the flash should be erased, based on RootDirEntry (diskimage.c), but I have to translate it first.

Renan

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed Jun 23 05:53:58 MST 2010

Quote: renan
Then I was thinking:
When I delete one file, how the bootloader will know what part of the flash to erase?

In normal circumstances, when Windows requests a file to be deleted, it is simply marked as deleted in the FAT tables. It won't actually get physically erased at that point.

In the RDB1768 bootloader example, the flash only gets erased when the "fake" [FONT=Courier New][SIZE=2]firmware.bin[/SIZE][/FONT] file that is created at reset is deleted. When you delete this from Windows, [FONT=Courier New][SIZE=2]BlockDevWrite()[/SIZE][/FONT] uses the check for '[FONT=Courier New][SIZE=2]user_flash_erased[/SIZE][/FONT]' to carry this out as a special case. (The 0xe5 in this same code block is the byte value to mark a file as erased - see http://en.wikipedia.org/wiki/File_Allocation_Table or other sources for information on FAT)

Quote:

And If I copy a file, with the exact name of one of the 2 that I'm showing in Windows Explorer, it will be overwriten, but in part of the flash?

To be honest, I can't remember what it will do in this circumstance. It is quite possible that it will simply write the new file elsewhere in flash, then mark the original file as deleted.

I would suggest that you add some statements to dump status information out to the UART so that you can see details as to the messages that are being received over the USB, what updates are being done to the FAT, etc.

Anyway I'm afraid there is little more advice I can give you here without actually going and implementing a similar system to the one you seem to be trying to create - and I'm not going to be able to put the time into doing that at the moment. Sorry :(

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by renan on Tue Jun 22 06:08:59 MST 2010

Quote: CodeRedSupport

I would suggest that in addition to looking at the RDB1768 bootloader example,

This is were I started.
I have changed this example to show 2 files:

diskimage.c

RootDirEntry[DIR_ENTRY]

and then changed the main_bootloader.c to correct the file size of both files:

Fat_RootDir[FAT_SIZE + 60 until 63]  and Fat_RootDir[FAT_SIZE + 92 until 95]

Then I was thinking:
When I delete one file, how the bootloader will know what part of the flash to erase?
And If I copy a file, with the exact name of one of the 2 that I'm showing in Windows Explorer, it will be overwriten, but in part of the flash?

I have defined areas in the flash for this 2 files, but I don't know exactly how to link them with what the user is going to do in the windows explorer.

Renan

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Jun 22 05:36:16 MST 2010

Quote: renan
There will be no more then 3 or 4 files.
Now I'm stuck with the low level drivers to fill the file system. "Reading" the flash to fill the file system is what I don't know how to do it now. Do you have any recomendation on how to do it?

I haven't really done anything exactly like this using FATfs or EFSL previously, but I did at one point have a look at how I might modify the RDB1768 bootloader example to provide a filing system that remained intact between power-ons.

The way I was looking at this, I would provide a "formating utility" which would be run first to create the filing system in the 1st sector of the flash. This basically consisted of writing the filing system arrays the bootloader uses out to flash.

Then my real program would start off by reading the stored filing system out of memory. Then the write sector code called from the usb mass storage level would set a flag every time the filing system arrays were updated. I then had a timer interrupt going off, and every 1 second or so my code would check the update flag and if it detected the arrays had been updated it would write the new version out to the 1st sector.

Unfortunately this experiment didn't really progress very far, so I can't really provide much more than the basic theory above on this.

I would suggest that in addition to looking at the RDB1768 bootloader example, it would be useful to look at the RDB1768 EFSL example as well:

http://support.code-red-tech.com/CodeRedWiki/RDB1768cmsisExampleProjects

And there are ports of both EFSL and FATfs to the LPC17 available from NXP which you might want to look at too:

http://ics.nxp.com/support/documents/microcontrollers/?search=LPC17&type=appnote

You might also want to think about wear levelling if you are writing files out to flash a lot. When you use an SD card or similar, this of course will be handled automatically for you. But using the LPC17's flash, you will potentially have to handle this yourself.

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by renan on Mon Jun 21 10:24:08 MST 2010

Quote: CodeRedSupport
Well assuming that you reserve the sectors in the flash, and then write the appropriate low level drivers for the filing system, I can't see any reasons why this shouldn't be possible. You'll probably need to watch things like the sector sizes restricting the number of files you can write though.

There will be no more then 3 or 4 files.
Now I'm stuck with the low level drivers to fill the file system. "Reading" the flash to fill the file system is what I don't know how to do it now. Do you have any recomendation on how to do it?

To write/erase, IAP should do the job the same way it is done in the bootloader example.

Renan

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Jun 21 10:00:09 MST 2010
Well assuming that you reserve the sectors in the flash, and then write the appropriate low level drivers for the filing system, I can't see any reasons why this shouldn't be possible. You'll probably need to watch things like the sector sizes restricting the number of files you can write though.

Regards,
CodeRedSupport