"The directory name is invalid" on the NXP LPC19459 in USB mode

Note - If you've arrived at this page because you're trying to get data off an SD card or USB drive that gives the "The directory name is invalid" error, I suggest trying to access the file via a Linux virtual machine.

Nearly every device you buy now seems to have an ARM core processor in it somewhere.  They're affordable, powerful, and when surrounded by peripherals they make some pretty impressive microcontrollers.  Traditionally I've always been an AVR and PIC person, and they still have their place, but I'd be stupid to ignore such a massive section of the market.  For those reasons I thought it was time to start learning about ARM processors.  

For various reasons I decided to start with the OM13056 evaluation board from NXP that contains an LPC1549 ARM cortex-M3 micro.  I chose this particular device because it has an onboard CAN bus controller and flexible methods for updating the firmware.

ISP Modes

Depending on the state of the the ISP_0 and ISP_1 pins at boot time, the device can be programmed via the CAN controller, USART, or USB.  The USB mode is the one that interests me the most.  By booting into USB mode the device presents itself as a mass storage device to the computer that when mounted contains a file named firmware.bin that contains the firmware.  You can read this file or drag and drop a new file to the drive to overwrite it to load new firmware.  It's fairly common now, but this was new to me.  In the past I've built PIC and AVR programmers by hand to get my code onto a device and I hated it.  It always got in the way of the task I was actually trying to perform. So this was brilliant.  It would also allow me to make a device that a user could update without extra hardware.

Then reality set in.  I plugged it into my Windows 10 computer, rebooted it in USB mode and was faced with an error message stating that "The directory name is invalid".  I tried everything I could find online to try and fix it but got nowhere.  I didn't know if it was the device or my computer causing the problem, so I tried it in my old laptop.  This time it worked.  So the most you could say at this point is that there's something about the way the device presents itself as a USB drive that allows one computer to read it and not the other.  My desktop was a fresh install of windows 10 64-bit while my laptop is an 32-bit upgrade to windows 10 from windows 7, so maybe there's a driver issue.  Who knows?

Error Message

I still didn't know if my desktop had a driver or hardware issue so I opened the drive in raw mode with a program called HxD.  It hasn't been upgraded in ages, but it's awesome.  Straight away you can see from a cursory glance that the first sector kind of looks what you'd expect the master boot record of a FAT file system to look like.  This tells me that the hardware is at least working to this level.  You could sit there and decode it by hand, but there are better ways to attack this.  "TO LINUX!!!" **Puts on cape and slides down pole into a secret cavern**

Accessing the raw data on the USB with HxD

I installed a quick Ubuntu VM in virtual box and passed the "NXP LPC1XXX IFLASH" USB device to it.  This is just here in case anyone doesn't know how to do that.

Pass the USB to the Virtual Machine

Success.  The drive mounts and I can access the file.  From this I surmised that the problem is probably a combination of things.  In some way, the MBR of the flash drive doesn't conform with the FAT standard 100% and the fresh install of Windows 10 is enforcing that rigorously, while the other systems are able to deal with what ever is wrong with it.

USB drive mounts in the virtual machine

What else can we find out about the drive?  It's FAT-12 and the size of 264,192 bytes is as expected.  It may seem wrong as the LPC1549 has 256 kiB of memory and this is 258 kiB, but you need to realise that the first 2 kiB of the device is dynamically generated when the computer accesses it.  It's the MBR and FAT and doesn't really exist.  The on board USB boot loader wraps the flash memory up as a file named firmware.bin and presents it to the computer.

Disk tool show that the dev board shows up as a FAT-12 partition

We can find out more info by imaging the drive with the dd command and running the file command on the image.  Warning! dd can do bad things, be careful when you use it.

dd if=/dev/sdb bs=512 count=1 of=mbr_usb.bin
file mbr_usb.bin

.

Inspecting the master boot record

The next step was to run the testdisk utility over the drive.  I'm not able to say for certain that this is the problem, but it did show a couple of things as unusual.  Maybe one of these issues is causing my Windows problems.

Inspecting the drive with testdisk

Unless this is just a random edge case I don't feel comfortable letting an end user use this method of firmware updating.  I'd much rather try my luck with the USART.