Under WinXP Sp3 with release 16457 on the mbed device, I believe the disk size reported is 2mb with 512bytes used on the initial powerup of the device. (No errors noted during USB driver installation.) Since the 1768 only supports 512Kb, where is it reporting the additional memory from? I was able to pull a copy of the MBED.HTM file to the laptop without any problem, so it doesn't appear to be corrupt. (Used XP properties sheet to examine free space available.)

Have you looked on the underside of the Mbed? There's a chip marked "Mbed Interface" which is a microcontroller in it's own right and an AT45DB161 16Mbit flash device. It's the "backend" of the Mbed system you are seeing, not the target LPC1768 device on the top side of the Mbed.

Thanks for the info, it didn't appear obvious to me and I don't recall seeing the identification of the device by number in the handbook.

Now that you point it out, I do see the chips on the schematic and this makes more sense now.

I suppose the rest of that memory(16mb - 2mb) is used by this other interface microprocessor for the USB filesystem support and control no? Is the LPC1768 writing the file into the USB directly from the localfilesystem API, or is this Interface Microprocessor providing that functionality?

My thought process on this is to use the mbed platform to log external events to a USB flash I was considering something much larger in the 128mb - 2gb range but this will be ok for the proof of concept.

Also noted when connected to the device:

A Command box chksdk reported that there was a nonvalid long folder filename in \.. .

The disk tools check disk did not report any such error.

Is there a section of the handbook or this sitr which explains the operation of the entire mbed platform as a block diagram?

Hi Edward,

16 megabits is 2 megabytes of storage, so we get to use pretty much all of it for program or data storage. I think the localfilesystem writes through the interface chip to the flash. If you need more storage, there has been a good amount of success using SD cards. They communicate using SPI and I believe there is a library already available. Have a look here.

Hope that helps!

Thanks again for the input. SD card sounds like the way to go.

You're probably right. I'm currently working with SD cards and working my way through what others (notably Simon Ford et al) have done to date. Welcome to your next world of pain ;)  (It's not the code that's the pain, it's finding cards that appear to function to the V2 version of the spec that's going to have you hair pulling :)