Content originally posted in LPCWare by DiligentMinds.com on Fri Aug 24 15:51:08 MST 2012
Hi Zoltan,
Unlike Windows (which writes file data in sequential sector order), Linux and all of the *BSD's (including Apple OS/X, which is based on OpenBSD) write files in random sector order on MS-DOS formatted file systems. I forgot why this is, but it may have something to do with security or performance (or ???).
So, if you are trying to write to an LPC that has a built-in USB ISP driver, and you are using a non-Windows system, it will probably work if you *DO NOT* first delete the file-- (ie.-- just drag-n-drop the file on top of "firmware.bin"-- to write directly on-top of "firmware.bin" without first erasing it). This way, your non-Windows system will simply use the block numbers already present in the (simulated) FAT on the device-- in the sequential order in which they appear.
If you make the mistake of first ERASING the file, and then try to write the firmware.bin file back with a non-Windows system, then your flash code is going to be scrambled on the chip, because the non-Windows system *WILL* write the (simulated) "sectors" in random order on the device. You *CAN* recover from such a situation by re-writing the file from a Windows system, or (if your repository has it) you can install "mtools"-- and write the file using that (which writes the sectors in sequential order just like Windows does).
I use Ubuntu Linux on my workstation, and I use mtools for this-- but I also run Windows-XP in VMware Player, so I can also program the device using that also.
So, to summarize, if you have a non-Windows system, NEVER DELETE the "firmware.bin" file on the (simulated) LPC drive-- just write on-top of it-- (ie.-- open it for writing, and copy the new file sector-for-sector over the top of the old one, thus "modifying" the original file)-- Alternatively, you can use mtools, which will allow you to erase the file and write a new one (without even "mounting" the drive, because mtools works directly with the device-- not with a mounted file system).
In YOUR case, it probably worked, because you didn't first erase the file (like the NXP ap-notes recommend). If you ever did erase the file, then you would either have to install and use mtools, or find a Windows system to recover.
If you dig deep enough, I'm betting NXP (or someone else) has an ap-note about this on the Internet.
I hope that helps!
