USB DFU Firmware Upload for LPC1850 LPC4350 LPC1800 LPC4300 LPC18xx LPC43xx

[lpcware]

Content originally posted in LPCWare by lpc18_43 on Sun Mar 25 20:00:22 MST 2012
How do I use USB DFU mode to upload firmware onto a LPC18xx/LPC43xx device?

The device starts up into DFU mode correctly and shows up using lsusb and dfu-util under Linux as well as under Windows.  It fails on the first download command.

Are there any documents available describing NXP's version of the DFU protocol?  Is custom software needed?

$ sudo lsusb -d 1fc9:000c -vv

Bus 001 Device 003: ID 1fc9:000c  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1fc9 
  idProduct          0x000c 
  bcdDevice            1.00
  iManufacturer           1 NXP
  iProduct                2 LPC
  iSerial                 3 ABCD
...

$ sudo dfu-util -l
dfu-util 0.5

(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY

dfu-util does currently only support DFU version 1.0

Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="DFU"

Under both Linux and Windows dfu-util fails when the download begins.

$ sudo dfu-util -R -D FIRMWARE.bin
dfu-util 0.5

(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY

dfu-util does currently only support DFU version 1.0

Opening DFU USB device... ID 1fc9:000c
Run-time device DFU version 0100
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="DFU"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0100
Device returned transfer size 2048
No valid DFU suffix signature
Warning: File has no DFU suffix
bytes_per_hash=481
Copying data from PC to DFU device
Starting download: [dfu_download: libusb_control_transfer returned -4
Error during download
can't detach
Resetting USB to switch back to runtime mode

My IC is a '-' revision part.  I am trying to use a binary file created by LPCXpresso (so it includes the checksum) which works correctly when uploaded using a LPC-Link through LPCXpresso.  I have also tried a version processed by lpc313xImgCreator.exe under Windows and unsimgcr under Linux.

[thiagosiqueira]

Hi,

I have the same problem. I have used the dfu-util and lpc-dfu but I can't upload the binary file to board.

To create the dfu file, I am using the following command:

$ dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -a _tmp.dfu

$ python2 -c "import os.path; import struct; print('0000000: da ff ' + ' '.join(map(lambda s: '%02x' % ord(s), struct.pack('<H', os.path.getsize('$<') / 512 + 16))) + 'ff ff ff ff ff ff ff ff ff ff ff ff')" | xxd -g1 -r > _header.bin

$ cat _header.bin _tmp.dfu >main.dfu

To program the board, I am using this way:

# dfu-util --device 1fc9:000c --alt 0 --download main.dfu

When I list my DFU devices:

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [1fc9:000c] ver=0100, devnum=31, cfg=1, intf=0, path="1-8", alt=0, name="DFU", serial="ABCD"

My board is found so when I program it:

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: DFU suffix CRC does not match
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1fc9:000c
Run-time device DFU version 0100
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0100
Device returned transfer size 2048
Copying data from PC to DFU device
Download [=========================] 100% 2768 bytes
Download done.
dfu-util: unable to read DFU status after completion

But the device doesn't run. Nothing happens.

I don't know why.

Thanks,

  Thiago

[lpcware]

Content originally posted in LPCWare by fred033 on Mon Oct 06 06:49:11 MST 2014
Hello,

I have the same problem, when flashing my LPC4337 using DFU utils, download seems to be done correctly but the code doesn't run.
I have tried the lpc-dfu util given by lancos_com but I'have following errors :

But after downloading the header file I have the following error :

C:\MinGW\msys\1.0\home\OV\lpc_dfu-1.02>dfuprog.bat C:\Users\OV\Documents\_FRED\d
fu_test_axf_bin\dfu_test.bin
Downloading algo...
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1fc9:000c
Run-time device DFU version 0001
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0001
Copying data from PC to DFU device
Download        [=========================] 100%        18320 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Programming C:\Users\OV\Documents\_FRED\dfu_test_axf_bin\dfu_test.bin
PREPARE
[color=#f00]Upload Op State, invalid response[/color]

I have attached the log file too.

I don't understand what is the problem and I hope someone can help me.

Thank You.

[lpcware]

Content originally posted in LPCWare by lancos_com on Tue Nov 19 01:31:26 MST 2013

---

Quote: coco
If that's the case, do you think do a 2 stage dfu-util code download will work?
* dfu-util -D bootloader_second_stage.bin.hdr  (with header)
* dfu-util -R -D firmware.bin  ( no header)

bootloader_second_stage.bin is compiled from the second stage dfu drivers. Thanks.

---

Hi,
I implemented the second stage, if you are interested you can download the file here http://www.lancos.com/lpc_dfu-1.02.tar.gz
Claudio

[lpcware]

Content originally posted in LPCWare by coco on Tue Aug 27 18:49:08 MST 2013
If that's the case, do you think do a 2 stage dfu-util code download will work?
* dfu-util -D bootloader_second_stage.bin.hdr  (with header)
* dfu-util -R -D firmware.bin  ( no header)

bootloader_second_stage.bin is compiled from the second stage dfu drivers. Thanks.

[lpcware]

Content originally posted in LPCWare by drs on Mon Aug 12 11:16:07 MST 2013
When the LPC18xx and LPC43xx family of parts boot up over USB they sends a DFU descriptor up to the host but they do not support the full set of DFU functions. They can only download an image into RAM and jump to it. That's it.

To implement a DFU driver you will need to create an image that contains this driver and download and run it as a second stage.

This has all been done here: http://lpcware.com/content/project/dfu-download-programming-utility-and-security-lpcdfusec-tool

The utility that downloads the image when the parts are booting up over USB is a C# application that sits on top of WinUSB. Source code to this application can be obtained with an NDA. Contact your FAE to do this.

Source code to the second stage DFU driver that works with dfu-util can be found in the applications\lpc18xx_43xx\examples\dfuutil folder of the latest LPCOpen Platform release for this part which can be found here: http://lpcware.com/content/project/lpcopen-platform-nxp-lpc-microcontrollers

[lpcware]

Content originally posted in LPCWare by coco on Sun Aug 11 23:00:31 MST 2013
Hi, I'm using LPC1857 (Keil MCB1800 Board) and encountered the same issue. The code download using dfu-util from linux is successful, but the code doesn't seem to run. I tried to download the same binary with the LPC-Link and it runs successfully, so most likely the problem is with the download. Just wondering whether you manage to find the solution. Thanks.

[lpcware]

Content originally posted in LPCWare by trioflex on Fri Apr 13 09:29:01 MST 2012
we have DFU loading ok nice on LPC4350, I assumed it MUST also work on LPC1830, but now getting really scared..

on LPC1830 we see:

Opening USB Device 0x0000:0x0000...
Setting Configuration 1...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1fc9:0x000c] devnum=2, cfg=0, intf=0, alt=0, name="DFU"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0800
bytes_per_hash=102
Starting download: [##################################################] finished!

now, the BLINKY does not seem to start...

another observation, READING back from LPC,
on LPC4350 we get 128K of 0's
on LPC1830 we get 96K of ARM code!

so I think it seems like the DFU is trying to load to ROM section??

Antti

PS, DOWNLOAD works, for some reason I can not control GPIO pins... but all DFU stuff is OK!

[lpcware]

Content originally posted in LPCWare by NXP_USA on Tue Apr 03 12:53:40 MST 2012
Downloading a new image via DFU requires an image with a special header. You can attached this header to your image using our image creator tool which you can find here: http://lpcware.com/content/nxpfile/lpc18xx-43xx-image-manager

The Rev '-' does hold a bootloader and does support DFU. This is the older revision of the part. The current part is Rev A and we encourage anyone interested in using this part in the future to use this current rev as it contains many important bug fixes. BTW, the register map is slightly different between these two revisions.

[lpcware]

Content originally posted in LPCWare by lpc18_43 on Mon Apr 02 06:31:24 MST 2012
As mentioned, DFU partially works for me.  Upload (retrieve firmware from device) works and the bottom line on my IC is [B]ESD1120-Y[/B].  Is there more than one '-' revision?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri Mar 30 07:35:03 MST 2012
IIRC, the Rev '-' silicon contained no boot rom. That is, there is no DFU or any other sort of external boot possible with that revision of the chip (i.e. it will only boot from Flash)

We will ask somebody from NXP to confirm and post to the forum.

As has been commented in this thread, you should not rely on anything in pre-production chips.

[lpcware]

Content originally posted in LPCWare by lpc18_43 on Fri Mar 30 06:45:42 MST 2012
Thanks for the response Rob65.  I will contact NXP.  It is likely a bug specific to the LPC1850 since other NXP devices work fine with dfu-util.

However, the problem doesn't seem to have anything to do with security since I can retrieve firmware correctly from a working device.  In other words, I can easily clone other's firmware.

It may be that someone confused the direction of Upload and Download and secured Download (load firmware onto device) but left Upload (retrieve firmware from device) unsecured.  It should be the other way around.

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Mar 29 09:16:46 MST 2012
Just reading the top two threads ...

---

Quote: TheFallGuy
dfu is dfu is dfu...

I wouldn't think that NXP would claim a device can be dfu booted, if it can't.

---

Just like CDC is CDC is ....
and MSC is MSC is ...
and HID is HID is ...
and RS232 (not a USB protocol) is RS232 is ...

Well, in fact - these are all 'just' protocols that are using the USB base protocol. A programmer can specify which endpoints to use and how these endpoints are ordered and there are even variations possible with a number of those protocols.

HID is a good example: the USB device driver knows all about HID and there is even support for it in user libraries - but the application needs to know how to control the HID device.

DFU is similar: DFU can be protected (e.g. to allow programming only with specific software from the company making the device) and it is even possible to add per device encryption, using a device's serial number to allow only certain firmware to be downloaded into certain devices.
I'm not stating that NXP uses this in the LPC1xxx controllers but I know some chips that use specific settings to prevent users from using anything like a generic DFU util to program a device.
It has been a few years ago when I worked on parts of the DFU code for some chips and I do remember that we had a lot of questions with different engineers interpreting the specifications in a different way (even the USB organisation is 'just a bunch of engineers' and even they can make mistakes).

So I think it is a bit of a blunt statement to blame NXP for selecting something that works in a specific way.
In fact, as a programmer and a device creator I welcome the use of features that allow me to protect my 'investment' in the creation of a product. I would not like it if anyone could just clone my hardware and use my software or download other software: rendering the device unusable and then blaming me ...

I did not read through the whole thread so it may be that there is a real bug - in that case, contact your NXP representative and explain this to him. They will then provide you with a solution, provide you with new (no Rev-) chips or make sure that this gets to NXP via the proper channels.
It is too much to ask for NXP to constantly search this forum for possible bugs and research every question that is being asked.

Regards,
[INDENT]Rob
[/INDENT]P.s: if you feel like it, go and study the USB3 spec and try to determine what the highest effective transfer rate is on a 5 GB/s USB3 connection :eek:

[lpcware]

Content originally posted in LPCWare by lpc18_43 on Thu Mar 29 05:56:34 MST 2012
Thanks TheFallGuy.  DFU is such a basic feature NXP should have caught this earlier and added it to the errata.  No mention in the 2012-02-02 version.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Wed Mar 28 21:49:25 MST 2012
dfu is dfu is dfu...

I wouldn't think that NXP would claim a device can be dfu booted, if it can't. The have dfu in a large number of their devices, and in my experience they all seem to work OK with dfu-util, so I don't see why LPC18/43 would be any different.

However, I haven't tried this on LPC18/43.

[lpcware]

Content originally posted in LPCWare by lpc18_43 on Wed Mar 28 21:31:17 MST 2012
Thanks for the post TheFallGuy.  I realise Rev. '-' is early silicon and unsupported but I just want to know if I should even bother.  I can't afford to prototype another board right now so I need to make the most of what I have.  I can use JTAG for firmware upload and debugging but DFU is a requirement and I was hoping to test system functionality.

Do you know if DFU Boot and loading with dfu-util works on  Rev. 'A' silicon?  With a custom dfu utility?

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Wed Mar 28 20:58:46 MST 2012
AFAIK, Rev '-' was very early pre-production silicon (and therefore boot rom). I know that NXP do not support that version of the silicon. I'd suggest getting hold of a production chip (rev 'AY' IIRC). This is supported and so if there are any problems with it, NXP are probably going to help you.

[lpcware]

Content originally posted in LPCWare by lpc18_43 on Wed Mar 28 20:24:59 MST 2012
[SIZE=4]I still cannot Download (load firmware onto device) using LPC1850 USB DFU Boot and dfu-util.  The LPC1850 still fails on the DFU_GETSTATUS command.

In a strange twist, DFU Upload (get firmware from device) works perfectly.  After a cold boot into DFU mode I can retrieve 96kb of data which is mostly random and changes after each cold boot.  If I load firmware using a JTAG dongle and reset the LPC1850, I can then retrieve the firmware correctly using dfu-util.

The LPC1850 responds incorrectly to dfu-util's Download process at the first [/SIZE][SIZE=4]DFU_GETSTATUS request.

Do the [/SIZE][SIZE=4]LPC18xx/[/SIZE][SIZE=4]LPC43xx have a customised DFU procedure?

Has anyone been able to load firmware onto a [/SIZE][SIZE=4]LPC18xx/[/SIZE][SIZE=4]LPC43xx (Revision '-') using USB DFU Boot?  I just want to know if it is possible.[/SIZE]
[SIZE=4]
[/SIZE]

[SIZE=3]
A:B:$  sudo dfu-util -U firm.bin

dfu-util 0.5

(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY

dfu-util does currently only support DFU version 1.0

Opening DFU USB device... ID 1fc9:000c
Run-time device DFU version 0100
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="DFU"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0100
Device returned transfer size 2048
bytes_per_hash=2048
Copying data from DFU device to PC
Starting upload: [################################################] finished!
[/SIZE]

[SIZE=4]

[SIZE=3]The retrieved firmware decompiles correctly:[/SIZE]

[/SIZE]

[SIZE=3]A:B:$  [/SIZE]arm-none-eabi-objdump -m arm -Mforce-thumb -b binary -D firm.bin | head -40

firm.bin:     file format binary

Disassembly of section .data:

00000000 <.data>:
       0:    8000          strh    r0, [r0, #0]
       2:    1001          asrs    r1, r0, #32
       4:    3401          adds    r4, #1
       6:    1000          asrs    r0, r0, #32
       8:    01b5          lsls    r5, r6, #6
       a:    1000          asrs    r0, r0, #32
       c:    01bd          lsls    r5, r7, #6
       e:    1000          asrs    r0, r0, #32
      10:    01c5          lsls    r5, r0, #7
      12:    1000          asrs    r0, r0, #32
      14:    01cd          lsls    r5, r1, #7
      16:    1000          asrs    r0, r0, #32
      18:    01d5          lsls    r5, r2, #7
      1a:    1000          asrs    r0, r0, #32
    ...
      2c:    01dd          lsls    r5, r3, #7
      2e:    1000          asrs    r0, r0, #32
      30:    01e5          lsls    r5, r4, #7
      32:    1000          asrs    r0, r0, #32
      34:    0000          movs    r0, r0
      36:    0000          movs    r0, r0
      38:    01ed          lsls    r5, r5, #7
      3a:    1000          asrs    r0, r0, #32
      3c:    01f5          lsls    r5, r6, #7
      3e:    1000          asrs    r0, r0, #32
      40:    01fd          lsls    r5, r7, #7
      42:    1000          asrs    r0, r0, #32
      44:    01fd          lsls    r5, r7, #7
      46:    1000          asrs    r0, r0, #32
      48:    01fd          lsls    r5, r7, #7
      4a:    1000          asrs    r0, r0, #32
      4c:    01fd          lsls    r5, r7, #7
      4e:    1000          asrs    r0, r0, #32
...

[SIZE=4]

[/SIZE]

[lpcware]

Content originally posted in LPCWare by lpc18_43 on Mon Mar 26 05:48:16 MST 2012
[SIZE=4]I separately logged the USB communication of dfu-util upload for both LPC-Link (LPC3154) and my LPC1850 board.[/SIZE]

$lsusb
  Bus 001 Device 007: ID 1fc9:000c  
  Bus 001 Device 006: ID 0471:df55 Philips (or NXP) LPCXpresso LPC-Link
  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$sudo cat /sys/kernel/debug/usb/usbmon/1u >~/Desktop/USBcaptureLOG.mon

$./vusb-analyzer ~/Desktop/USBcaptureLOG.mon

Defines from the USB DFU Specification (Pg.9):

0x21 0x00 = DFU_DETACH
0x21 0x01 = DFU_DNLOAD
0xA1 0x03 = DFU_GETSTATUS
Error code 108 = ESHUTDOWN = Cannot send after transport endpoint shutdown

[SIZE=4]

The following compares dfu-util communication with LPC-Link and with the LPC1850.  The LPC3154 responds properly to a DFU_GETSTATUS request and continues with DFU download.  The LPC1850 responds to DFU_GETSTATUS by dropping off the USB hub (1001).  This behavior is consistent across multiple sessions.[/SIZE]

[SIZE=3][B]DFU-Util to LPC-Link:[/B][/SIZE]

[SIZE=2][I]Direct: http://knowledgebase.nxp.com/attachment.php?attachmentid=717&stc=1&d=1332992780[/I][/SIZE]

[IMG]http://knowledgebase.nxp.com/attachment.php?attachmentid=717&stc=1&d=1332992780[/IMG]

[B][SIZE=3]DFU-Util to LPC1850:[/SIZE]

[/B][I][SIZE=2]Direct: http://knowledgebase.nxp.com/attachment.php?attachmentid=718&stc=1&d=1332992790[/SIZE]

[/I][IMG]http://knowledgebase.nxp.com/attachment.php?attachmentid=718&stc=1&d=1332992790[/IMG]


[SIZE=4]The following is the output from the LPC-Link (LPC3154) dfu-util session.[/SIZE]

$sudo dfu-util -R -D firm.bin 
[sudo] password for dev: 
dfu-util 0.5

(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY

dfu-util does currently only support DFU version 1.0

Opening DFU USB device... ID 0471:df55
Deducing device DFU version from functional descriptor length
Run-time device DFU version 0100
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
Found Runtime: [0471:df55] devnum=0, cfg=1, intf=0, alt=0, name="UNDEFINED"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Deducing device DFU version from functional descriptor length
DFU mode device DFU version 0100
Device returned transfer size 2048
No valid DFU suffix signature
Warning: File has no DFU suffix
bytes_per_hash=436
Copying data from PC to DFU device
Starting download: [##################################################dfu_download: libusb_control_transfer returned -9
Error sending completion packet
can't detach
Resetting USB to switch back to runtime mode

[SIZE=4]Useful links:[/SIZE]

http://vusb-analyzer.sourceforge.net/
http://www.usb.org/developers/devclass_docs/usbdfu10.pdf