NXP USB bootloader Linux vs Windows quirk

[MattHollands]

My latest project uses an NXP LPC11U24 chip which is an ARM Cortex-m0. One of the neat features is that you can boot it into a preloaded usb bootloader than enumerates as a 32kb mass storage device, and then you can copy your bin file onto it - effectively programming it.

However on my Linux Debian PC, the program does not run when I reset the chip - the LEDs just glow slightly which is the same as it does when it's in the bootloader. But it does work on a Windows 10 (even a Windows 10 virtual machine running on my Linux machine).

I assumed that the flash memory must be changing in some way so I took MD5SUMs of the bin file at different stages and here is what happened:

1. MD5 of the bin file on my laptop harddrive - 4911e46463102b3bd8bbf69e75c2e407
2. Using my Windows 10 VM, attach chip via usb bootloader, delete current firmware, replace with bin file. MD5 the bin file on the chip - 4911e46463102b3bd8bbf69e75c2e407 (the same)
3. Exit bootloader, program begins to run, flashing LED etc. Reconnect chip via usb bootloader, MD5 the bin file on the chip - bec2c37631b20f3bf4723f11f9674010 (different - but program still runs)
4. Using my Linux Debian machine, attach chip via usb bootloader, delete current firmware, replace with bin file. MD5 the bin file on the chip - 4911e46463102b3bd8bbf69e75c2e407 (the same as what I got with the Windows machine)
5. Exit bootloader, program does not run, LEDs glow dimly. Reconnect chip via usb bootloader, MD5 the bin file on the chip - 664f5274738df16546427baea6c8066f (different to anything before)
This is 100% repeatable.

So from what I can see, the chip's flash changes in some way when the bootloader is disconnected, but on Linux it changes differently to how it changes on Windows such that it doesn't run at all. Slightly at a loss to what this could be. I was hoping that maybe someone else had used the bootloader on Linux or had any idea what the difference could be.

p.s. Unless there is some unsolvable problem I REALLY don't want to use Windows.

[BradC]

Are you syncing after copying the bin across? USB Storage on Linux has a fair amount of caching and you must sync before disconnect.

[ataradov]

That neat USB MSD "trick" is a horrible idea and relies on OS specific behavior.  At some point NXP documents had a note that it only works on Windows. I'm not sure if that has changed.

But, yes, sync on a drive is a good idea.

EDIT: I guess the note was removed and all OSes are supposed to be supported now:

20121119 Modifications:
• Removed remark “USB ISP commands are supported for the Windows operating system only.”. USP ISP commands are supported in Windows, Linux, and Mac OS.

[MattHollands]

running sync before umount does not seem to help

[ataradov]

Here is a workaround that worked on old bootloaders (before the fix) http://dangerousprototypes.com/docs/LPC_ARM_quick_start#Bootloaders

But I would assume that by now all devices should have a fixed version of the bootloaders.

[andersm]

running sync before umount does not seem to help

If you do a proper unmount, you don't need to ecplicitly sync.

[MattHollands]

Here is a workaround that worked on old bootloaders (before the fix) http://dangerousprototypes.com/docs/LPC_ARM_quick_start#Bootloaders

But I would assume that by now all devices should have a fixed version of the bootloaders.

Works! Thank you!

[mubes]

Assuming you've got to the point where the LPC 'drive' is appearing then the problem is that the file-write stuff expects that the file is written to the chip in linear order, which it is on doze. Linux/OSX, not so much.  All you need to do is explicitly write the file directly to the device, something like;

Code: [Select]

dd conv=nocreat,notrunc if=newfile.bin of=/media/CRP\ DISABLD/firmware.bin
sync

Regards

DAVE

[ataradov]

Works! Thank you!

So 5 years later, parts are still shipped broken. Nice.

[MattHollands]

Works! Thank you!

So 5 years later, parts are still shipped broken. Nice.

Looking at the date code, it looks like this was manufactured in the 45th week of 2015. Seeing as they removed that comment in 2012, you would think that this would be correct...

[dgtl]

I've messed with the same issue on LPC1343 ages ago. It was broken already then.
Most of such bootloaders do not have proper fat filesystem implementation. They have researched that windows overwrites a file in place; they pre-create a fat with one file and assume that you overwrite that file so that the block mapping does not change, they just redirect these corresponding blocks of mass-storage media to flash blocks. But the OS might use blocks on the FAT filesystem in whatever order and the devide gets to know what it was only after the FAT table itself was written after the data on unmount of the FS. As there is usually not so much RAM as flash, you can't store the fw in ram for writing later; you have to write down what the computer said and un-shuffle the filesystem when OS finished and you know what the order is. But waiting for the OS to unmount the fs and after that un-shuffling the blocks is not done and the blocks of the code can remain shuffled (a lot of users would not unmount/eject the drive properly anyway).
In linux the dd workaround helps as this will open the file and write bytes to the same file without letting the fs to map blocks. Copying with overwrite files depends somewhat on file manager behavior; deleting and copying new file depends on kernel fs implementation and these seem to be not windows-compatible.
I wonder, why they won't do MTP instead of mass-storage. As mass-storage just provides raw flash block access (SCSI), it can not be accessed by multiple owners at the same time. Protocols like MTP give the pc fs-independent file-level access and this would be much more suitable.
Or we could use DFU if Microsoft would provide a generic driver or another simple way to access the device (libusb/winusb still need signed inf etc). At least they added generic usb-serial support in win10, maybe we'll get dfu in win15?

[amyk]

I have written FAT filesystem drivers before, one with full functionality is not hard and doesn't take all that much space either. That's just broken.

[ataradov]

I have written FAT filesystem drivers before, one with full functionality is not hard and doesn't take all that much space either. That's just broken.

But that's the trick. This bootloader does not have an actual file system, it has no place to store it. It simulates in run-time, but expects blocks  to come in in the right order, since there is no place to store ordering information. And USB MSC has no idea of the file system, it transfers sectors.