Reprogramming LPC3154 at LPCxpresso

Question

I wonder, if that's possible to load lpc3154 at LPCExpresso board with custom firmware?

I see that chip supports secure boot, so if AES key was programmed, it is impossible without knowing the key? Or are there any options to boot lpc3154 without knowing the key? (SD, flash, USB, JTAG... Anything?)

Does anyone know if key was indeed loaded?

Just buying new lpc3154 is not an option - they are not in stock here anywhere, and wait times are 4 weeks+ (and a price tag > than a price of this board)...

There is no such LPCXpresso board! The only processors are LPC1114, LPC1343 and LPC1769. — Leon Heller, Mar 10 '11 at 16:00
Well, LPC3154 is on each of these, on the host part. :-) That's what I want to reprogram. I have 2 LPCxpresso boards, and It would be so nice to reuse such a juicy 192kb SRAM chip... — BarsMonster, Mar 10 '11 at 16:17
I will, but officials would not be happy about that question - price of 3154 is comparable to price of this devboard :-) — BarsMonster, Mar 10 '11 at 16:55
Not yet, the only reply I've got on official forum was 'That would be cool' :-) — BarsMonster, Mar 17 '11 at 13:10
[Was about to add a small bounty](http://chat.stackexchange.com/transcript/message/697459#697459) as I think this is a great question, but you have no shortage of rep yourself ;) ... maybe offer a bit for an answer? — tyblu, Mar 19 '11 at 16:05

score 4 · Accepted Answer · answered Mar 23 '11 at 15:10

From what i gather the AES key is loaded into the chip. And also there may be a CR232 check on the firmware as well or OTP fuses set

source

Supports un-secure boot from UART and USB (DFU class) interfaces during development. Once the AES key is programmed in the OTP, only secure boot is allowed through UART and USB.

This doesn't mean it cant be hacked, if you put the time into it. I would check to see if the JTAG pins have been disabled and start from there.

some interesting statements from the user guide

7.1 Production line use case At the NXP production line the OTP will be tested and programmed using JTAG. In test mode, the fuse block itself will be accessed directly. During programming the VPP will need a higher voltage than in the application use case. Written data is checked afterwards by reading out the fuses (using a low voltage on VPP) The customer will also program the OTP only at the production line, here DFU programming will be used. An image for programming customer-selected bits can be loaded into the device via USB.

7.2 Application use case nitially it is important to make sure that the data_15 register is updated early during the initialization (by boot-code) this will set the security level. Four levels of security are implemented in the design:

• Level 0: nothing is protected.

• Level 1: password protected. In this level, JTAG can be enabled by software after password sequence (depends on customer application) by setting the sticky bit 'JTAG_EN' in OTP_con register.

• Level 2: In this level, JTAG access can be enabled using special test equipment. Used by NXP for Returned Material Analysis only.

• Level 3: JTAG is completely disabled and hence the chip is virtually locked.

The customer can program the security level of the chip. For level 1, fuse-bit 509 should be set. For level 2, fuse-bits 509 and 510 are set. For level 3, fuse-bits 509, 510 and 511 are programmed. A special case will be for the customer to disable writing to the fuses, but since in application a low voltage (for reading) will be connected to the VPP, writing will not be possible anyway. During normal application, the fuses will already have been programmed on the production line. So three options remain: copying the fuse data into the data registers, reading this data, and setting the read protection. The boot code will copy the fuse data into the data registers because this is needed for security and DRM. After this, the data can be read from the data registers via the APB0 bus (according to the read protection settings).

Edit: If the key is truly loaded, you will only be able to load custom firmware if you have the key.

The existence of Level 2 is frightening. I wonder if 'special test equipment' overrides the password requirement for level 1? — Kevin Vermeer, Mar 23 '11 at 15:24
@reemrevnivek, for as many people that are scared by that there are probably a large number of failed chips they could not debug without it. If you set level 2 you know what you are doing, really, in a final product you would probably set level 3. Still, great research! — Kortuk, Mar 25 '11 at 11:28
I couldn't find any direct reference, stating that the key was loaded but my guess is still yes, just because of the closed nature of the board. — jsolarski, Mar 26 '11 at 19:46

score 2 · Answer 2 · edited Mar 19 '11 at 21:56

2

The question was answered here on the LPCXpresso forum. The device can only load DFU software from Code Red.

From NXP_USA:

The LPC-LINK boards distributed embedded in LPCXpresso, can only load DFU firmware from our LPCXpresso IDE partner Code Red. However, the LPCXpresso schematics are posted here: http://www.embeddedartists.com/products/lpcxpresso/lpc1343_xpr.php?tab=res. They are a useful reference for a more flexible LPC3154 design that could accept arbitrary firmware via DFU.

The LPC3154 is available from Digi-Key and Mouser.

edited Mar 19 '11 at 21:56

Kevin Vermeer

19,989
8
57
102

answered Mar 19 '11 at 17:29

Leon Heller

38,774
2
60
96

This does not explain one we cannot load 3rd party firmware. – BarsMonster Mar 19 '11 at 18:27
That post links to another thread, which has, at the bottom, an authoritative post from NXP. I'm going to give you a hand, and drop the links in for ya... – Kevin Vermeer Mar 19 '11 at 21:53

score 1 · Answer 3 · answered Aug 31 '11 at 20:43

I have been experimenting with the LPCXpresso LPC1114 board. It appears the programming interface (LPC3154) is USB High-Speed (480 MHz) and it seems extremely particular about the USB cable you use. If the cable (or the host port) isn't top notch, it may be very unstable, crash a lot, and even lock up other USB devices on the same root port. From having written a number of USB stacks, my guess is this particular USB stack is not very robust in terms of error and exception handling.

The fact they used such a high-end ARM for a simple JTAG/SWD interface is laughable, that MCU was over $13 (at Digikey) last time I looked.

I would recommend using a different SWD interface and disconnecting the one on the board if you have any difficulty. This should also permit the use other (non Code Red) IDEs with these boards.

(If you encounter USB problems with any device (even Full-Speed 12 MHz) and you are using the USB host connectors in the front of a PC system unit, try using the rear connectors on the MB itself. I have seen well-known brands of PCs with non-compliant (and very flaky) cabling to the front of the system unit.)

Izzy Weird

Reprogramming LPC3154 at LPCxpresso

3 Answers3