OM13066-Reprogram LPC11U24 via USB

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

OM13066-Reprogram LPC11U24 via USB

Jump to solution
1,785 Views
coolxiangm
Contributor I

Hi,

I order OM13066 board, which is LPC11U24 evaluation board. I want to program LPC11U24 through USB interface, so I isolate this board target side, and provide the independent power for LPC11U24. I also follow UM10462 and reference one post in this community. 

"Content originally posted in LPCWare by DiligentMinds.com on Thu Aug 30 10:32:12 MST 2012
Just for you-- I just tested it.  I am using the 48-pin (Rev-B) version of your device, but otherwise they are the same.  Yes-- USB_CONNECT (P0.6) goes low if you enable the ISP by holding (P0.1) low during a reset.  Note that, to enter the USB ISP, "VBUS" must also be connected to P0.3, and it must be high when reset happens (and P0.1 is low).

On my device, if I leave the batteries out, it is powered by the USB host when I plug it in (through a 3V3 regulator of course).  In this case, when I hold P0.1 low, and plug in the USB cable, it DOES NOT enter the ISP (as I would expect)-- I have to further cause a reset-- and THEN it goes into the USB ISP.  I'm guessing that this is because the power is not ready (or something) when the (internal) reset goes high...  Another deviation from the ap-note is that I put a 10K resistor in series with VBUS to P0.3-- I know the data-sheet says that this pin is "5V tolerant", but I wanted to limit the current into the pin anyway, just to be safe...

I used the same circuit for the 1.5K pull-up through a P-channel FET as was given in the ap-notes, and it appears to work fine.  (P0.6 goes low, driving the drain of the PFET high, which pulls up the 1.5K resistor on the D+ line of the USB cable).

This is used by the ISP, and if you are programming a USB device, it allows your software to do a "soft connect"-- ie., it's like unplugging the USB cable from the host, and then re-plugging it back in to re-enumerate the USB device.  This might be done if you (for some reason) have re-configured your USB device, and you want the host to treat it in a different way.

So, you probably do need this pull-up PFET (or PNP) arrangement if you are going to use the USB port for either USB ISP or for a USB device.

I hope this helps!

--Ken Peek

I can see "CRP DISABLED" drive displayed on my PC, and I also see one bin file which is "firmware.bin" , and its date is 2/6/2009. I delete this file and drag my own bin file. After reset the board by shorting PIO0_0 to ground, unplug PIO0_1 from ground and unplug PIO)_3 from 3.3V, the board is still not working. When I re-check the "CRP DISABLE" drive, the file I loaded in is disappeared, and old file "firmware.bin" is back, so I'm wondering which step is wrong. By the way, I also padded my own file to 32kB, because document an11305 indicates

"Using a padded (128 kB or flash size) programming file also provides a means for
the programming tool to error-check that the correct LPC part is connected (by
comparing file sizes of the new firmware and the firmware.bin on the device) without
additional configuration information"

the padded files is still not working. Is there any NXP technical engineer I can call in to talk?

Thanks,

 

Frank

0 Kudos
1 Solution
1,649 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Hi

Most likely it goes wrong in the first step, generation of the bin file.
The bootcode of the LPC checks whether a valid flash signature is found at a specific location, probably this signature is missing in the .bin file.
This process is explained in the User Manual ( https://www.nxp.com/webapp/Download?colCode=UM10462&location=null  ), chapter '20.7 Criterion for Valid User Code'

You can also refer this article to add checksum.

https://community.nxp.com/t5/LPC-Microcontrollers-Knowledge/LPC8N04-LPC-Boot-ROM-checksum/ta-p/11261...

 

Have a nice day

Jun Zhang

 

View solution in original post

0 Kudos
9 Replies
1,749 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Hi

The application must be renamed to firmware.bin, and the rename cannot be performed in the CRP DISABLD disk.

Please do the following to update firmware:

-Remove the original firmware.bin in the CRP DISABLD disk.

-Rename the application ( .bin file) to firmware.bin.

-Copy the application firmware.bin to the CRP DISABLD disk.

-Reset the MCU, if the LED is observed blinking, it proves that the application has been successfully upgraded.

Please test again.

Have a nice day,

Jun Zhang

0 Kudos
1,732 Views
coolxiangm
Contributor I

Hi Jun,

I follow the procedure you list, but it still does not work. I want to ask some additional question?

1. For my new "firmware.bin" file, do I have to pad file to 32KB?

2. What tool are you use to pad the file, and what values are being padded with?

Currently, I'm using OM13066-LPC11U24 Evaluation board. I can successfully to load file through JTAG by using lpcxpresso. The file type is .axf. This is what I got so far.

 

Thanks,

 

Frank

0 Kudos
1,725 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

HI 

afx file can not be accepted. firmware can only accept bin file.

To generate bin file,  refer below screenshot

ZhangJennie_0-1655875373283.png

 

make sure rename it as "firmware.bin", lower case

Best Regards,

Jun Zhang

0 Kudos
1,715 Views
coolxiangm
Contributor I

Hi Jun,
This is what I did to get the original binary file, but this file is not padded to 32KB, so
1. do we need to pad file to 32KB? 
2. Is there any other hardware setup trick?
When I supply independent power to LPC11U24
I have PIO0_1 connects to GND, and PIO0_3 connects to 3.3V (all the time). If I leave PIO0_3 floated, the "CRP DISABLED" drive display and disappear, so PIO0_3 should connects 3.3V. I also screenshot my hardware setup. Please take a look. If I setup anything wrong, please tell me. 

coolxiangm_0-1655918380580.png

 

0 Kudos
1,687 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Yes, please pad it.

if your firmware.bin can't work after programming, test if your code can work in standalone mode:

- download your application with debugger.

- disconnect the PC. 

- provide external power to the board. let it run in standalone mode. 

can you see the blinky code working?

0 Kudos
1,680 Views
coolxiangm
Contributor I

Hi, 

"download application with debugger"- if you mean left side of the board, I successfully load file through left side, but the file type is .axf, and then I applied standalone at right size, the right part of circuitry is work. I can see LED is blinking. But it is still not able to reprogram from right side.

coolxiangm_1-1656097538784.png

Frank

0 Kudos
1,650 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Hi

Most likely it goes wrong in the first step, generation of the bin file.
The bootcode of the LPC checks whether a valid flash signature is found at a specific location, probably this signature is missing in the .bin file.
This process is explained in the User Manual ( https://www.nxp.com/webapp/Download?colCode=UM10462&location=null  ), chapter '20.7 Criterion for Valid User Code'

You can also refer this article to add checksum.

https://community.nxp.com/t5/LPC-Microcontrollers-Knowledge/LPC8N04-LPC-Boot-ROM-checksum/ta-p/11261...

 

Have a nice day

Jun Zhang

 

0 Kudos
1,645 Views
coolxiangm
Contributor I

I think this reply is the right direction. I will try to correct checksum, I will get back to you soon.

Frank

0 Kudos
1,041 Views
FLS
Contributor I

How did you go on this...

I now have the same problem on my own circuit board...

Did you find a way to pad the file?

Cheers

0 Kudos