LPC11U24 ISP via USB

[lpcware]

Content originally posted in LPCWare by hens on Tue Apr 02 11:34:55 MST 2013
I have code which works correctly when .axf file is loaded via SWD.  I want to program the flash via USB and have followed the steps in
   http://support.code-red-tech.com/CodeRedWiki/OutputFormats

My Post-processing steps are:
  arm-none-eabi-size "${BuildArtifactFileName}";
  arm-none-eabi-objcopy -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin";
  checksum -p ${TargetChip} -v -d "${BuildArtifactFileBaseName}.bin";
(I added th -v option to checksum and log shows "Validation checksum = 0x0")

When I reset the target in ISP mode, the folder pops up with "firmware.bin", I delete it, and copy my new .bin to that folder, then reset.  Everything seems to have worked fine but the target is no longer working.

How do I debug this?

[lpcware]

Content originally posted in LPCWare by hens on Thu Apr 04 13:19:52 MST 2013
Thanks!  Got it working with that app-note.  Bummer that it didn't show up in any of the web searches that I did over the last 3 days :-(
Moving forward again now.  Thanks again.

[lpcware]

Content originally posted in LPCWare by Tsuneo on Wed Apr 03 19:35:03 MST 2013

---

Quote:
Host is X86_64 running Fedora 14.

---

Ah, on Linux.
Then, this NXP appnote helps you.

AN11305: USB In-System Programming with the LPC11U3X/LPC11U2X
http://www.lpcware.com/content/nxpfile/an11305-usb-system-programming-lpc11u3xlpc11u2x

AN11305v.1.pdf in the zip tells you the reason of your trouble, and its workaround.

3. USB ISP details (p5)
The data written to the filesystem is organized in flash by disk block order, with the beginning of flash starting at block 4. If firmware.bin is deleted, PCs running windows will allocate any new file starting at block 4 and using increasing block numbers as more data is written. This means that in Windows, any standard program or tool can be used to write new firmware to the LPC11U37. In a Windows Explorer window, a user can delete firmware.bin and drag over a new file to program the flash.

Unfortunately, FAT filesystems on Mac and Linux machines tend to allocate blocks to files in a different order which results in data being written onto the ISP disk, and consequently firmware being written to flash, being reordered. This will cause the firmware update to be unsuccessful.

There are two workarounds for this. The most general workaround is to overwrite the firmware.bin file in place. A more “brute-force” option that requires administrative privileges to do direct disk device writes to /dev.

Tsuneo

[lpcware]

Content originally posted in LPCWare by hens on Wed Apr 03 17:08:29 MST 2013
If I load via SWD, reset into ISP mode, then copy the firmware.bin from the "CRP DISABLD" folder, the file matches the .bin generated by LPCXpresso.  At least for the first 7K, which is the size of my code.

In contrast, if I load via USB, reset, then read firmware.bin, I see massive mismatches starting at 1KB boundary (0x400).

I am getting some mods done to clean up possible signalling problems in D+/D- path as I type, but this data corruption looks more like a buffer overflow.

Any chance there is a flow control bug in the USB ISP mechanism?
Host is X86_64 running Fedora 14.

[lpcware]

Content originally posted in LPCWare by hens on Tue Apr 02 16:26:40 MST 2013
When I said "no longer working", I meant it doesn't even show up on the USB bus after reset.  I am able to see the "CRP DISABLD" folder again if I reset into ISP mode.

I have managed to get my code working in the USB_DEVICE_ROM_DRIVER mode (saves about 8KB of flash), hoping that might help but ....

Please, does anyone have any suggestions?

PS. Drivers needed modification to get rom-mode working, as detailed in-
http://jenswilly.dk/2012/10/nxpusblib-on-lpc1347/