Author Topic: USBricked my LPC1547  (Read 3470 times)

0 Members and 1 Guest are viewing this topic.

Offline kmmTopic starter

  • Contributor
  • Posts: 32
  • Country: us
USBricked my LPC1547
« on: March 05, 2015, 10:51:17 pm »
Howdy EEVbuddies, long time lurker here.

I've been working on a device based around an LPC1547; got some parts last week, assembled a prototype (everything worked first power on, much to my surprise), cobbled together a skeletal blinky project and associated toolchain/linker crap, and built a (very questionable) blinky.bin.

So cool, I've got at least somewhat working prototype hardware, and an at least somewhat working build kit, time to use that slick USB firmware upload feature to flash this thing.

Plug the USB into my board's USB hole, power it up - Windows sees it as a mass storage device just like the datasheet says. Awesome.
Copy the existing image over to check it for anything interesting (there wasn't), delete it, and copy over my 4 kilobytes of pleasure. Appears to be successful.

Power cycle it - no blinky but that's pretty much what I expected first try.
Notice a possible error in my C, fix it, recompile, plug in the USB...and nothin.

Device no longer gets detected as a mass storage class, and as far as I can tell appears completely inert to the host PC.

Figure maybe I killed USB with some config or power bit I didn't set, so I pulled the boot pins appropriately, hooked up a serial dongle and poked it with lpc21isp....nothin.

When I checked it with the scope, I found that with ISP_1 pulled high (boot to USB ISP loader) the 12MHz osc starts up, as it does when both ISP_0 and ISP_1 are pulled high (boot to flash program), but not when both are pulled low (boot to UART ISP loader). This strikes me as a bit odd.

The manual certainly makes it sound like the bootloader is in its own ROM, but it kinda seems like my dodgy firmware either wacked something important or enabled all the protection bits.

I suppose it's possible I just coincidentally zapped the chip with static or a USB transient or something around the same time I programmed it, but I've only got the one prototype on hand so I can't reproduce the whole process at the moment.

Anyone out there encountered anything like this?

 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4078
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: USBricked my LPC1547
« Reply #1 on: March 07, 2015, 02:07:04 pm »
Is your binary checksummed? And can you use swd/jtag to erase/write the flash?

The external oscillator is only required for USB operations. So is't not that odd when it's not used in UART mode.

It is higly unlinkely you programmed the magic key accidentally. But verify anyway: 0x000002FC should not contain any of the following values:  0x4E697370,  0x12345678, 0x87654321 or 0x43218765.

Did you include USB ESD protection diodes?
« Last Edit: March 07, 2015, 02:09:56 pm by Jeroen3 »
 

Offline kmmTopic starter

  • Contributor
  • Posts: 32
  • Country: us
Re: USBricked my LPC1547
« Reply #2 on: March 08, 2015, 11:42:38 am »
Quote
Is your binary checksummed?

Hm, doesn't seem like it. I see a lot of references to generating this with a program called checksum.exe on NXP's site, do you happen to know if it can be built on if or an equivalent of it exists for linux? My build environment is vanilla gcc-arm-none-eabi and makefiles on ubuntu (in a VM on windows, but I'm trying to keep the build process unixy and minimalist). I can take the image to windows for checksum stamping but it'd be nicer to just add it to my makefile in linux. Not turning up much on NXP's site regarding alternatives.

Quote
And can you use swd/jtag to erase/write the flash?

I'm not sure. I have a dusty (cheap chinese knockoff, natch) ULink2 dongle, and it would appear that I can use Keil's MDK to drive it against the 1547.

That'll be something to mess with.

Quote
The external oscillator is only required for USB operations. So is't not that odd when it's not used in UART mode.

Makes sense.

Quote
It is higly unlinkely you programmed the magic key accidentally. But verify anyway: 0x000002FC should not contain any of the following values:  0x4E697370,  0x12345678, 0x87654321 or 0x43218765.

Looks good.

Quote
Did you include USB ESD protection diodes?

Nope, which is why I can't at all rule out physical damage, however oddly coincidental. Next rev will have proper USB protection.

Thanks, I think trying to swd/jtag probe it is the next logical step until I get another prototype built.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4078
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: USBricked my LPC1547
« Reply #3 on: March 08, 2015, 12:48:16 pm »
Within Keil you have elfdwt.exe and fromelf.exe to checksum the file and make a binary.

If you're looking for a linux solution you should search/ask here: http://www.lpcware.com/
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6190
  • Country: us
Re: USBricked my LPC1547
« Reply #4 on: March 08, 2015, 03:09:58 pm »
When I run the project make file setup by lpcxpresso it has this line

//Performing post-build steps
arm-none-eabi-size "hello_world.axf" ; arm-none-eabi-objcopy -v -O binary "hello_world.axf" "hello_world.bin" ; checksum -p LPC11U35_501 -d "hello_world.bin"

And then

$ which checksum
/Applications/lpcxpresso_7.3.0_186/lpcxpresso/bin/checksum

All my binaries came from the single package install of lpcxpresso. I am using Mac OSX but Linux and Windows should be the same.
 

Offline kmmTopic starter

  • Contributor
  • Posts: 32
  • Country: us
Re: USBricked my LPC1547
« Reply #5 on: March 08, 2015, 10:08:05 pm »
Found the linux lpcxpresso installer, good to go on the checksumming front now; one less thing to beat my head against in the future.  |O

For any other blind squrrels reading, the nut is here: http://www.lpcware.com/lpcxpresso/downloads/linux
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf