EmbDev.net

Forum: ARM programming with GCC/GNU tools Did I brick my LPC1768?


von KennyB (Guest)


Rate this post
useful
not useful
I'm using Yagarto/Eclipse/Flash Magic.

I have a LPC1768 Blueboard. When I first got it, it had some kind of 
code on there that flashed the LED. I loaded my own code to do the same, 
and it now doesn't seem to be able to vector off and run.

I talk to it through Flash Magic. I can talk to it through a serial 
terminal and issue the Synchronized and crystal commands, however I'm 
not seeing anything on the scope at the crystal, and the LED doesn't 
blink. In fact both LEDs seem to go to an intermediate state and I'm 
reading 1.7V.

I haven't hooked anything up to the board that I would consider to have 
caused this. I tapped into the USB power (That is how I'm powering it, 
through USB) to get ~5V over to my level converter.

I've uploaded another hex file I found on the web and it does the same 
thing.

Is it how I'm using Flash Magic maybe? Is there another program I should 
try? It has worked for me in the past with the LPC2138. My experience 
with that chip was that when I fryed it, it was truly fryed and I 
couldn't load code or anything else.

I'm getting a fresh board delivered today, but I don't want a repeat.

von Martin T. (mthomas) (Moderator)


Rate this post
useful
not useful
Since you can "talk" to the controller with FlashMagic I don't think you 
"bricked" the device. At least the UART and the internal 
clock-generation still work. Did your compare/verify after flashing? 
FlashMagic offers an option for this. If this works too I expect the 
problem is in the application code.

I have not done much with LPC17xx and can not point you to a simple 
example. Did you ask the board-manufacturer or seller if they can send 
you just the hex-file of the preinstalled application for tests?

Maybe the code gets linked for addresses in RAM. Double check the 
linker-script, startup-code and maybe the disassmebly (objdump). At 
least a minimal vector-table should be located at address 0. The first 
DWORD value in the table should be a valid RAM address since it's use as 
initial stack-pointer. The second value should be the address of the 
reset-handler. If you are using the CM3 systick, check if the 16th(IRC) 
value in the table is the address of the systick-ISR.

You may also try with my SD-Card example, it's made for LPC1766 and 
includes a lot of code which is not needed for a simple test but at 
least a LED-blink is also included. You may have to change the 
LED-connection (Port, Bit) in the defines to reflect your board's 
hardware. I have tested with the GNU toolchain as in Codesourcery G++ 
lite for ARM-EABI but if you use the latest Yagarto-release (ARM-EABI 
target) there should be no changes needed to build the project with 
Yagarto too.
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#chanfat_lpc_cm3

von KennyB (Guest)


Rate this post
useful
not useful
I'm getting the same results with you example. The only thing I changed 
were:

1) Call make instead of cs-make in Eclipse.
2) Change location of hex file in the flash magic settings along with 
the device type.

I have not talked to the manufacturer, but I do have a fresh board here. 
I tried pulling the hex off that, but my test editor messed up the 
formatting I believe, and I couldn't get it on to the broken board.

What I did notice, however, is that the board must stuck in reset. I say 
this because it behaves just as the new board does when I reset with BSL 
pulled low.

I just have to figure out why I can't get it to vector off and do 
anything.

von KennyB (Guest)


Rate this post
useful
not useful
I also tried changing over the *.ld and *.cfg files that project to 
those created for the LPC1768. That just made a big mess. I have more 
learning to do.

von KennyB (Guest)


Rate this post
useful
not useful
I'm really perplexed by what's happening between the code and the hex 
file. I can compile your example above for the LPC1766, but that hex 
file does not get the chip out of ISP. I'm using the latest of : 
CodeSourcery/Eclipse/FlashMagic.

I found another example project for the LPC1766 on the net, and that hex 
file works fine. On the other hand, I can't get that one to build.

What could be causing this thing to get stuck?

von Martin T. (mthomas) (Moderator)


Rate this post
useful
not useful
KennyB wrote:
> I'm really perplexed by what's happening between the code and the hex
> file. I can compile your example above for the LPC1766, but that hex
> file does not get the chip out of ISP.

- Do you have something connected to the BSL pin (P2.10 IRC)?
- IRC Flash magic has a checkbox to insert the correct checksum during 
the transfer. Is this option activated? It should be enabled by default. 
Application-code will not start if the checksum in the vector-table is 
not correct.

von KennyB (Guest)


Rate this post
useful
not useful
Hmmm, the checksum block is grayed out for me. A quick look at the 
manual doesn't make it obvious why that is the case.

Anyways I finally got it working today. It seems like there are a lot of 
examples floating around out there that may indeed need that box to be 
checked. Thanks for your help.

von KennyB (Guest)


Rate this post
useful
not useful
You're program works great. I did not change the LED to values to match 
my board, and the LED was stuck in a half way state. This makes it 
appear as though the board is in ISP (same behavior, visually)

I was able to start my own project based on your work, thank you.

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.