Kinetis K64F - USB FLASH Drive using Internal FLASH and USB MSD device class

[#1]

Hello,

I've created a application of USB FLASH Drive acessing the 1MB internal FLASH of K64 using the Freescale's bareboard USB Stack 5.0 software + FRDM-K64F to be used by anyone as reference.

It seems to be stable, I already wrote some files on that and checked the integrity of the volume.

It can be very useful for datalogger application where the equipment can store data on the MCU FLASH using a internal filesystem, and read it through PC as it was a regular USB stick. It also very much cheaper than using a external SD Card, as it only needs the MCU + a external crystal and a USB connector.The only limitation so far is that it cannot exceed the number of the erase/write cycles of the device (of course!).

Please see the file attached with the USB Stack and the example on the folder "{Installation Path}\Freescale_BM_USB_Stack_v5.0\Src\example\device\msd\bm\iar\dev_msd_disk_frdmk64f". The project was wrote using IAR.

Also I have attached the srec file if you don't want to build the project by yourself.

Any issues, doubts or suggestions, please let me know.

Denis

[mjbcswitzerland]

Hi Denis

Please see the following: µTasker Kinetis FRDM-K64F support

This allows the same but the internal application can already access the card. In addition, the SD card can be used in parallel, plus an optional external SPI Flash - meaning that the USB host sees 3 hard drives when the FRDM-K64F is attached.

There are downloads there for comparison if of interest. The project is available as CW, KDS, IAR, Keil, Crossworks, Atollic, CooCox, GCC standalone and Green Hills setups, plus can be simulated in real-time using VisualStudio. It also works on any K, KL or KE device with enough internal memory to be of use.

Out of interest I checked the project that you posted and have the following remarks:

- Usually FAT in internal Flash uses a block management layer with wear-leveling. - this makes Flash operations faster because you don't need to erase a complete Flash sector each time you write data to a FAT sector

- The wear-leveling also ensures that the Flash sectors that are being erased/written most are not going to fail first (spreads the wear) - although this is of course only an issue when a very large amount of writes are performed

- When you erase a 4k Flash sector it would be better to use a define for this size otherwise the code is not correctly portable for processor with different Flash sector sizes

- The technique of erasing a Flash sector on each FAT sector write is a risk for systems requiring high reliability due to the fact that if there is a reset/power down during the process (which takes about 15ms each time) it is possible to lose important data that can result in corrupted files or a corrupted file system. Block management is therefore important in such systems since its operation automatically allows failure at any time without risk of corrupting the file system itself or data that has already been saved.

The project in the link has a define SIMPLE_FLASH which also allows exactly the same method. Without this define it switches in a block management layer (although I have to admit that there is a little extra work required to perform background mode house-keeping that is still being worked on).

Regards

Mark

Kinetis: µTasker Kinetis support

K64F: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[dshimizu]

Hi Mark!

Thank you very much for your feedback! I will surely check the examples of uTasker!

Yes, you are right. There is no wear-leveling scheme on this version of the project. The idea here was to make something easy to understand and baremetal (no OS) for further use. I will work on this implementation for the future releases.

Thank you again!

Regards,

Denis

[neilporven]

Hi Denis,

I tried using the project, but every time I disconnect the board from the PC and re-connected it, it keeps trying to do a 

FORMAT.  If I format it and place a small file, I can never see it, because it asks for formatting.

Any idea on this?

Thanks,

Neil

[myke_predko]

Hey dshimizu‌,

Interesting project.  I've looked at doing an application like this repeatedly over the years but wasn't sure how as I would also have a USB CDC device running in parallel (and never had enough time to do the research).  There are a few examples providing USB MSD but none that I've tried actually work as I would expect; when you plug in the Freedom board with the example projects (ie dev_composite_cdc_msc_bm/freertos) you just end up with an error message.  

I should point out that the SDK MSD examples (seem to have the same issue as what neilporven‌ is reporting; when you plug the Kinetis into a PC you will be told that the drive needs to be formatted before you can copy in any files.  The data is lost when you plug in again (and have to format).  

Just a few comments back to mjbcswitzerland‌, a few years ago, I took the basic FatFS code and ported it to the K20DN512 (under MQX) and got it running quite nicely with a lot of work.  It's fairly easy to implement "as is" but to get it working practically in a Kinetis (and the internal Flash of any MCU) you're going to have to:

• Consider whether or not this approach is right for your application.  If you're going to be writing multiple, relatively large files continuously, then it probably isn't the best approach for the reasons outlined below
  • If you are writing files fairly infrequently but reading them constantly, then using Flash for a file system works really well
• Think about wear-leveling (as you noted).  The FS should really have a pseudo-random sector allocation algorithm
  • I added in a 16 bit CDC to the header so that I could detect data corruption but it has yet to catch any issues (with a number of systems that have run for years with one to five file writes every day) without any kind of randomizing algorithm - of course, YMMV
• Figure out how to manage sectors.  FAT uses a 512 byte sector and Kinetis (and probably most other MCUs) do not
  • If you're going to have small files, you're going to have to figure out how to manage this without using up all the Flash with only a small percentage of actual saved data in the Flash
  • You will also have to figure out whether or not to implement garbage collection rather than let the files become jumbled throughout Flash over time
    • I suggest that you do implement garbage collection along with only implementing contiguous files as noted in the next point
• Accept that read efficiency is going to be terrible in an MCU as you have to count on the files being non-contiguous with the "as is" implementation.  If you're looking at reading a file, you have to ensure you have an SRAM block large enough to store the entire file
  • OR you can do what I did and only allow contiguous files, that way to read, you point to the start of the data and read from there as if it were a single byte array
• Figure out what you're going to do in terms of reentrency
  • Life is too short to worry about this in an MCU: I suggest that you only allow accesses to the file system through a semaphore and don't try to create code that will allow multiple tasks (ISRs, Callbacks, etc.) accessing the file system at the same time

• In the Kinetis, you have to make sure you don't write to the last sectors in each block of Flash (to allow firmware swapping).  Not a big deal, but something to think about for the people here

I'd love to see this project move forwards (and understand the issues) because it would eliminate the need for the custom software I use for accessing the file system contents through a CDC device with custom software.  Bonus, as I said, would be able to communicate with the Kinetis concurrently using a CDC device.  

myke