FatFs Example Project for USB Flash Drive

[Markus Gritsch]

I was trying to achieve accessing an USB flash memory stick from my CUI32.  So I tried the "USB Host - Mass Storage - Simple Demo" from the "Microchip Solutions" folder, only to find out, that Microchips MDD library explicitely lacks LFN (long file name) support. (The working code is in the repository [1].)

After some searching I found ChaN's excellent FatFs library [2].  Googling for Microchip and FatFs first only turned up this [3] application note from Microchip, which just has the MMC low level driver implemented.  After quite some more Googling, I fould some (non-compiling) example code in the Microchip forum [4], which had a low level driver for the Microchip USB stack, which I made working and did some cleanup. I think others could benefit from this example project, so here is the link to the code [5].

Have fun,
Markus

[1] http://code.google.com/p/cui32/source/browse/#svn/trunk/firmware/US...
[2] http://elm-chan.org/fsw/ff/00index_e.html
[3] http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&...
[4] http://www.microchip.com/forums/fb.ashx?m=501402
[5] http://code.google.com/p/cui32/source/browse/#svn/trunk/firmware/Fa...

[Rich Testardi]

Hi Markus,

If you get stuck there, I also have a low level usb driver, a block cache on top of it, and FAT16/32 filesystem on top of that. Most of it is in the skeleton project (http://www.cpustick.com/downloads.htm), but the rest is attached (I didn't write the filesystem, though I fixed a couple of bugs in it and use it in StickOS -- you can just "print" results to a USB flash drive for data logging on the PIC32 and MCF5225x).

-- Rich

[Markus Gritsch]

Thank you Rich,

I also had a look at the DOSFS website [1] before finding FatFs. The latest version of DOSFS is from 2006 and the site says version 1.03 contains bugs that will be fixed in 1.04, and this version never got released... Further the readme says it does not support long filenames, which was the reason I was not satisfied with Microchips MDD library in the first place. So I went on to FatFs.

However, your USB stack might be interesting. I suppose it already supports the mass storage and CDC class devices. Ian Lesnet from Dangerous Prototypes [2] is also looking for open source libraries to replace the ones provided by Microchip, which does not allow modifiying and redistributing them. Here [3] he is looking for an open source TCP/IP stack, USB stack, and FAT library. Maybe I can understand your USB code -- I will take a look.

Markus

[1] http://www.larwe.com/zws/products/dosfs/index.html
[2] http://dangerousprototypes.com/
[3] http://dangerousprototypes.com/docs/Compiling_PIC_projects#Non-dist...

[Markus Gritsch]

Rich, I downloaded the skeleton project and compiled it for my self-made CUI32 using the PIC32MX795F512H. I made it pass the check in line 86 of basic0.c, but after programming, the device does not enumerate as a COM port, although the STATUS led is flashing. Any hints on how to proceed? (It works fine if I compile the skeleton for my other CUI32 from SparkFun using the PIC32MX440F512H.)

[Rich Testardi]

Hi Markus,

There are three things you have to be careful of on the compile, and unfortunately, I left the skeleton project in an indeterminate state for v1.72c (I'll fix that at v1.72d).

1. you have to do Configure -> Select Device, obviously
2. if you want to use the HID bootloader, you have to "cp procdefs.ld.ubw32 procdefs.ld" *and* you have to define HIDBL in config.h
3. if you don't want to use the HID bootloader, you have to "rm procdefs.ld" and comment out HIDBL in config.h

Unfortunately, by default, the skeleton project has HIDBL defined and procdefs.ld not existing, which is an invalid configuration.

Does that help?

-- Rich

[Markus Gritsch]

I already saw this and commented the HIDBL define. Guess what, the problem was that I had left the HOST/DECIVE switch on my selfmade CUI32 in the HOST position x-) After switching it to DEVICE, enumeration was flawless and communication worked fine :)

One thing though: The PIC32MX795F512H has TX3 and RX3 on its RF5 and RF4 pins respectively. The PIC32MX440F512H has TX2 and RX2 on those pins. So I guess I have to make some fix to get the UART working on this CPU.

[Rich Testardi]

Hi Markus,

Welcome to uart pin soup on the PIC32. :-(

Basically, the relationship between uarts and ports is completely random between MCUs. Up to the MX5+, at least UART2 was consistent... Now even that one is not.

So you'll have to change SERIAL_UART to be 2 (the uarts are named starting at "1", "2", "3", ...) and then you'll have to implement all the higher level uarts in sources/pin.c. Don't forget to extend the uart_names[] array.

Unfortunately, you won't be able to use the uarts from BASIC (though you should be able to for the serial console) because MAX_UARTS is a #define rather than a variable, so even if you change it, the StickOS library won't be affected (I'll change that on the next skeleton drop).

I will probably have to order a MX7 or something as well so I can start testing with... Do you know is there one chip that is a superset of all of the new MX's that would be best for me to order?

-- Rich

[Rich Testardi]

Or you could just connect your serial console to whatever pins are used for TX2 and RX2 on the MX7, of course.

[Markus Gritsch]

Rich Testardi said:

I will probably have to order a MX7 or something as well so I can start testing with... Do you know is there one chip that is a superset of all of the new MX's that would be best for me to order?

I choose the PIC32MX795F512H because currently it is the top-of-the-line PIC32 (of the small package ones). It seems to have all the peripherals the lesser devices have, but have a look yourself at the parametic table: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&...

I got mine for free as a sample, so it might be worth asking Microchip :)

Markus