LPC Microcontrollers中的主题 Re: LPC4370 jump to internal DFU

LPC4370 jump to internal DFU

mflipphi — Tue, 06 Dec 2016 08:56:50 GMT

We would like to jump to the internal DFU of the LPC4370 from within our application.
Is there any example code available?

Re: LPC4370 jump to internal DFU

jeremyzhou — Wed, 07 Dec 2016 01:34:02 GMT

Hi Mark,

Thank you for your interest in NXP Semiconductor products and the opportunity to serve you.

I was a little confused with your question, do you want to use the USB DFU API routine in the application code?

If yes, you can refer to the LPCOpen library which includes the USB DFU demo.

LPCOpen Software for LPC43XX|NXP
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: LPC4370 jump to internal DFU

mflipphi — Wed, 07 Dec 2016 13:02:31 GMT

Hi Ping,

Thanks for the quick response and the DFU demo location.

The demo should do what we need, except we are getting some problems.

The initialization of the DFU is working, and we manage to upload a firmware file.
A led blinky (in ram) is working, but loading the LPCscrypt (http://www.nxp.com/products/software-and-tools/software-development-tools/software-tools/lpc-microcontroller-utilities/lpcscrypt-v1.8.0:LPCSCRYPT#features) is resulting in a hard fault after the following function :

/* Execute the new image. */

static void start_image(uint32_t *image_ptr)

{

/* disconnect and load the new image */

USBD_API->hw->Connect(g_dfu.hUsb, 0);

/* disable all IRQs enabled in this example */

NVIC_DisableIRQ(LPC_USB_IRQ);

SysTick->CTRL &= ~SysTick_CTRL_ENABLE_Msk;

/* get and set the stack pointer of the new image */

__set_MSP(*image_ptr++);

/* jump to new image's execution area */

((void (*)(void)) * image_ptr)();

}

We upload the PLCscrypt firmware with the following command line :

dfu-util.exe -d 088d:4323 -c 0 -i 0 -t 2048 -R -D LPCScrypt_140.bin.hdr

For the blinky, we found that interrupts are not remapped, but for the LPCscrypt it looks there are some more problems.

Please advise how to continue

Kind regards, Mark

Re: LPC4370 jump to internal DFU

jeremyzhou — Thu, 08 Dec 2016 07:44:41 GMT

Hi Mark,

In the dfu_composite demo, the USB standard device descriptor is illustrated below, and you can find the idVendor and idProduct is 0x1FC9 and 0x0089 respectively.

So you can use the command instead of the previous one.

dfu-util.exe -d 1FC9:89 -c 0 -i 0 -t 2048 -R -D LPCScrypt_140.bin.hdr

/**
 * USB Standard Device Descriptor. In this example we will overwrite
 * this descriptor in DFU_AppDetach state so this array has to be in
 * RW area hence no const keyword.
 */
ALIGNED(4) uint8_t USB_DeviceDescriptor[] = {
     USB_DEVICE_DESC_SIZE,                    /* bLength */
     USB_DEVICE_DESCRIPTOR_TYPE,               /* bDescriptorType */
     WBVAL(0x0200),                              /* bcdUSB: 2.00 */
     0x00,                                        /* bDeviceClass */
     0x00,                                        /* bDeviceSubClass */
     0x00,                                        /* bDeviceProtocol */
     USB_MAX_PACKET0,                         /* bMaxPacketSize0 */
     WBVAL(0x1FC9),                              /* idVendor */
     WBVAL(0x0089),                              /* idProduct */
     WBVAL(0x0100),                              /* bcdDevice: 1.00 */
     0x01,                                        /* iManufacturer */
     0x02,                                        /* iProduct */
     0x03,                                        /* iSerialNumber */
     0x01                                        /* bNumConfigurations */
};‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Have a great day,
Ping

Re: LPC4370 jump to internal DFU

mflipphi — Thu, 08 Dec 2016 18:45:31 GMT

Hi Ping,

The USB descriptor is not the problem.

We used our own, because it's already running in our own firmware.

We have the composite device, have the dfu device and our own device. Uploading using the command also finishes, only the the problem starts.

After the image is uploaded, the function "start_image" is called to start running the code just oploaded to the ram memory.

When leaving this function we get an hardfault, and the firmware hangs in the while(1)

So the LPCScrypt firmware causes problems.

It's like there are unhandled interrupts, jumps to faulty memory location, wrong clock settings...

We did not find sources of the LPCScrypt which makes debugging hard.

We tried a small blinky application that runs in ram. Uploaded the image and this is working. We had to add re-routing of the interrupts and we had to disable the header for the upload.

Kind regards, Mark

Re: LPC4370 jump to internal DFU

mflipphi — Fri, 09 Dec 2016 06:30:12 GMT

Tried the DFU example (without any modifications) from the file lpcopen_2_20_lpcxpresso_nxp_lpclink2_4370.zip.

We uploaded the DFU example to the flash of the LPC-LINK 2. Then reconnected the USB cable and device shows up the USB composite device as shown below

Now we run the command

dfu-util.exe -d 1FC9:89 -c 0 -i 0 -t 2048 -R -D LPCScrypt_140.bin.hdr

dfu-util 0.7

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

Filter on vendor = 0x1fc9 product = 0x0089
Opening DFU capable USB device... ID 1fc9:0089
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 DFU USB Device...
Found Runtime: [1fc9:0089] devnum=0, cfg=1, intf=0, alt=0, name="UNDEFINED"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: error get_status

Next the device switches the DFU mode, goes to an alternate configuration of the USB and shows up as

Again we run the command

dfu-util.exe -d 1FC9:89 -c 0 -i 0 -t 2048 -R -D LPCScrypt_140.bin.hdr

dfu-util 0.7

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

Filter on vendor = 0x1fc9 product = 0x0089
Opening DFU capable USB device... ID 1fc9:0089
Run-time device DFU version 0100
Found DFU: [1fc9:0089] 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
bytes_per_hash=563
Copying data from PC to DFU device
Starting download: [##################################################] finished!
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
No valid DFU suffix signature
Warning: File has no DFU suffix
can't detach

And after this, the USB connection is gone, and the device is not responding anymore.

Re: LPC4370 jump to internal DFU

jeremyzhou — Fri, 09 Dec 2016 09:01:38 GMT

Hi Mark Flipphi，

Let me illustrate the steps of my work.

1. Click the Boot LPCScrypt, then program the ufu-composite demo image to SPIFI.

2. Configure MCU boot from the SPIFI when JP1 closed.

But I encountered a weird issue, the PC can't recognize the USB device, and in the readme.text, it states "When connected to Windows host use the .inf included in the project", however I didn't find the inf file.

So I was wondering if you can share your procedure, then I can replicate your issue on my site.
Have a great day,
Ping

Re: LPC4370 jump to internal DFU

mflipphi — Fri, 09 Dec 2016 09:32:49 GMT

Hi Ping,

The inf file for this example is included in the LPCScrypt installer, that can be found here

http://www.nxp.com/products/software-and-tools/software-development-tools/software-tools/lpc-microcontroller-utilities/lpcscrypt-v1.8.0:LPCSCRYPT?&tab=Design_Tools_Tab

We have included a zip file containing the inf from this installer.

This should work!

Mark

Re: LPC4370 jump to internal DFU

jeremyzhou — Mon, 12 Dec 2016 06:14:47 GMT

Hi Mark Flipphi，

Thanks for your reply.

I've done the following steps to replicate your issue.

When enter the DFU, type these command again : dfu-util.exe -d 1FC9:89 -c 0 -i 0 -t 2048 -R -D LPCScrypt_140.bin.hdr, then receive the messages as the Fig 1 illustrates.

Fig 1

Did you ever try to type the command: lpcscrypt queryspifi or lpcscrypt queryflash ?

Have a great day,
Ping

Re: LPC4370 jump to internal DFU

mflipphi — Mon, 12 Dec 2016 06:31:07 GMT

Hi Ping,

For us the commands LPCScrypt queryspifi or queryflash makes no sense, lpcscrypt isn't running on the device so why try calling these commands? (Just to make sure, we tried it and got errors just like we would expect)

After uploading LPCScrypt, the USB devicelist enumerates and no LPCScrypt device is available at this time.

Mark

Re: LPC4370 jump to internal DFU

jeremyzhou — Mon, 12 Dec 2016 08:33:11 GMT

Hi Mark,

Thanks for your reply.

I'm also struggling to fix the dfu driver issue, as the dfu enumeration process is very unreliable.

Sometime goes well, sometime not.Whatever I'm still working on it.
Have a great day,

Ping

Re: LPC4370 jump to internal DFU

philipouellette — Thu, 09 Mar 2017 19:07:44 GMT

One thing to consider. Windows makes registry entries for each USB device and once created it gets made if you change things. First time I ever tried to implement DFU (on an 8051 class processor), I didn't understand this and when I started with an HID class device which worked fine. When I added DFU class support (as a composite device), Windows refused to enumerate the device until I cleared out the registry entries for that device. This happened a long time ago, but perhaps something like this might be behind your problems? The simplest check is to change the Device ID or Serial number (triggering the creation of new registry entries) and then see if the USB connection works correctly now.