LPC MicrocontrollersのトピックRe: LPC11U2x winth non-Windows OS

LPC11U2x winth non-Windows OS

lpcware — Wed, 15 Jun 2016 19:28:33 GMT

Content originally posted in LPCWare by Zoltan on Sun Jun 17 04:24:17 MST 2012
The datasheet says that the LPC11U2x ISP presents itself as an USB mass storage device.
Then it warns the reader several times that it works with Windows only.

As far as I know the USB mass storage device class is pretty much standard and everybody supports it.
Including OS-X, Linux, BSD and about a zillion embedded devices.

So, does anyone know what how NXP managed to turn a platform agnostic, standardised device profile to a
Windows-only, undocumented, proprietary protocol?

Thanks,

Re: LPC11U2x winth non-Windows OS

lpcware — Wed, 15 Jun 2016 19:28:34 GMT

Content originally posted in LPCWare by drs on Wed Jun 20 10:30:24 MST 2012
It should work with other operating systems. Have you seen otherwise?

Re: LPC11U2x winth non-Windows OS

lpcware — Wed, 15 Jun 2016 19:28:35 GMT

Content originally posted in LPCWare by Zoltan on Wed Jun 20 15:01:05 MST 2012
I have not tried it, considering that the data sheet repeatedly emphasises that it works only work with Windows.
However, I found an entry on mbed, http://mbed.org/forum/mbed/topic/3573/ in which a poster says that he tried
it with OS-X and it does not work while with Windows it does. He didn't try Linux. The post is only a week old.

My sentiment was like yours, if it's a mass storage profile, it should work with any OS, because the profile
specification is OS agnostic. Apparently NXP managed to make it Windows specific.

Re: LPC11U2x winth non-Windows OS

lpcware — Wed, 15 Jun 2016 19:28:36 GMT

Content originally posted in LPCWare by Martin on Sun Aug 19 18:52:07 MST 2012
I can confirm that it works correctly in OS Linux. I have tried it on PC with Ubuntu and Fedora distributions.

Re: LPC11U2x winth non-Windows OS

lpcware — Wed, 15 Jun 2016 19:28:36 GMT

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!