Problems with Olimex LPC-2106 (random crashing)

Hello all. :-) I''m new to the ARM world, but after much struggling, I''ve managed to figure out how to compile and load code into RAM using an openocd JTAG programmer from Olimex. Using Eclipse or Insight as the debugger makes no difference in the behavior.

The problem is that I seem to be getting random crashes when running the code (simple LED blinker with for/next delay loops). Sometimes the code will run for minutes before going off to never-never land, other times it will crash right away. A \"crash\" always leads to the same thing, the CPU seems to have jumped from RAM to the flash area and will almost always be stuck at

0x00000688 (sometimes 0x00000684).

The assembly code for the while(1) loops looks just like it should, there is no possible way for the code to get out of that loop, yet it does. :roll: And it always ends up stuck at the same area. I''ve tried different crt.S startup code and linker scripts, but the end result is always the same. I just don''t get it, could it be a spurious interrupt?

I''ve tried different power supply modules in case it was that, no difference. Since I only have one board to test with, I can''t be sure of much of anything. Since it always ends up at the same location, I really suspect the JTAG. Single stepping works, it''s just when you hit the \"Continue\" button, the program crashes after a few seconds or maybe two minutes. Anyone got a really good crt.S, linker script for GCC?

Thanks for reading.

Reply to
Anthony Fremont
Loading thread data ...

I would like to have some clarifications here w.r.t random crashes. It is crashing at the same location but at different instant of time. Or Is it crashing at different locations of your code ? (Less probability . :( )

Ok. It is crashing at the same location but at different instant of time . What does the stack pointer point to at the time of the crash in your code ? Are you able to get some info w.r.t Program Counter ?

Can you show the snapshot of this ?

Try to trace the flow as below, if you are not feeling comfortable in stepping in through the code :

1) Try to put while(1) after few set of actions/instructions. If you wish you can put after every defined instruction also. 2) Try to put some prints after every instruction

Are you not able to single step for even a single instruction ? Did you load your application at the correct place in the Memory ? Are you directing the bootloader/main application correctly to load your application from that correct location ?

Are you able to get pass through the entry point ? Did your LED blink atleast once or were you able to step into those LED related routines ? Is there any abnormal declaration or defintion ?

Karthik Balaguru

Reply to

It "ends up" sitting at address 0x00000688 when I do a break. The IP is pointing into the flash area, not at some address in the RAM (such as

0x40000xxx. The code will run fine for random amounts of time then the LED comes on permanantly, followed by the distinct sound of the relay (on the dev board) clicking. Always the same symptom when it "crashes". This could be due to the demo code that was stored in the flash by olimex. I have not reprogrammed the flash area at all. The question is, "how does a tight loop executing in RAM end up executing some code out of the flash area?"

The IP is the only thing that is consistantly pointing at 0x00000688.

Here is the whole loop: while (1) { { IOCLR = 0x00001000; for (j = 0; j < 500000; j++ ); // wait 500 msec IOSET = 0x00001000; for (j = 0; j < 2000000; j++ ); } }

The code will single step just fine, but if I tell it to just run, it crashes after some seemingly random amount of time. One interesting thing is that I don't believe it has crashed when the PLL is not enabled.

It single steps just fine.

As far as I can tell, yes. I am concerned about the area of ram that the internal boot loader uses, but I haven't found any linker scripts that go out of their way to not use those areas. I'm thinking that if during the course of the JTAG happenings, if the CPU gets reset and possibly attempts to execute the phillips boot loader after my program has been loaded into RAM, resulting in some of my code getting smashed. I'm still pretty incompetent when it comes to using these tools and knowing the "gory" details of what's going on in the hardware.

I'm not using any boot loader, just JTAG to plunk the code into RAM and run it.

The code usually starts up just fine, but sometimes the debugger will indicate the IP is already pointing into the flash area before executing even the first instruction.

Yes, it will blink for a random number of times before the program ends up crashing. I don't know much about JTAG, but the little LED is really blinking like mad when my program is in the RUN state. I don't really understand why, but I don't know the details of how this stuff all works yet.

Here are the commands I pass to Insight:

******************************* target remote localhost:3333 monitor reset monitor sleep 500 monitor poll monitor soft_reset_halt monitor arm7_9 sw_bkpts enable monitor mww 0xE01FC040 0x0002 monitor mdw 0xE01FC040 break main load continue *******************************

This is what I use for OpenOCD:

************************ telnet_port 4444 gdb_port 3333

#interface interface ft2232 ft2232_device_desc "Olimex OpenOCD JTAG TINY A" ft2232_layout "olimex-jtag" ft2232_vid_pid 0x15BA 0x0004 jtag_speed 3

#use combined on interfaces or targets that can't set TRST/SRST separately #reset_config trst_and_srst srst_pulls_trst reset_config trst_and_srst separate

#jtag scan chain #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE) jtag_device 4 0x1 0xf 0xe

#target configuration daemon_startup reset

#target #target arm7tdmi target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4 run_and_halt_time 0 30

working_area 0 0x40000000 0x10000 nobackup

#flash configuration #flash bank lpc2000 0 0 flash bank lpc2000 0x0 0x20000 0 0 0 lpc2000_v1 14765 calc_checksum


After some more tinkering, I'm finding that the PLL sometimes becomes disabled while I'm debugging. If I disable setting up the PLL in my code, it seems to work "better" (read this as it runs for a longer time before crashing). When it crashes, the stack gets filled (but not so far as to smash over the code in RAM) with some ping-pong type entries (like two functions are calling each other recursively). This all culminates in the processor being stuck between 0x00000684 and 0x00000688. The code in RAM remains intact as far as I can tell.

Reply to
Anthony Fremont

If you don't get a response from this group, it may pay to drop your message on the Olimex support group at:

formatting link


Don McKenzie

Affiliate Program:	
 Click to see the full signature
Reply to
Don McKenzie

Have you tried a program load to flash using the Philips/NXP serial bootloader? Are you 100% sure that the pins that must be pulled-up on reset, are? What do the power rails look like? Are interrupts enabled and have you taken care to trap the known spurious interrupts that family is vulnerable to? (See NXP appnote AN10414.)

Reply to
Rich Webb

Thanks Don. I posted basically the same thing over there first, but I got this: Usage of forbidden word We're very sorry, but your post is hold for moderation. A site administrator will be notified and will approve your post.

That was this morning, and my post still hasn't appeared on the forum. :-( Oh well, I'll repost if it doesn't show by morning.

I can duplicate the behavior by pressing the reset button on the dev board. It ends up in exactly the same behavior pattern.

Reply to
Anthony Fremont

I haven't gotten to that point just yet, I was thinking that running from RAM would be easier at first.

I'm using an Olimex dev board, and the schematic looks ok.

After a bunch more tinkering, I'm thinking this is precisely where the issue lies. After subbing in still more AC adapters, I think I'm on the path to success. The specs only call for 6VA or 9VDC input, but it looks like I really need to hit it with at least 12VDC to be sure that it will power on ok. I had a 9VDC 600mA adapter that would partly work, but the 12V 200mA that I'm using now seems to be able to do the job. Strange IMO.....

Thanks for the pointer on that. :-) I'm not using either of the two circumstances described, but I put a default spurious interrupt trap in my code. That's when I determined that some type of hard reset seems to be occuring at random times, because the vector I load gets wiped out after a "crash".

I was able to run the LED blink program all last night without failure with the PLL disabled (running at about 15MHz). Now I'm using the 12V adapter, it's running with the PLL enabled and seems to be working so far (about 30 minutes).

Of course I didn't do any of the things I probably should have before running for help, like checking the current draw or scoping the power rails. I was trying to be lazy and just be a software only guy right now. I guess I'll have to drag my stuff back upstairs to the laboratory til I can trust it. ;-)

Thanks again everyone. :-)

Reply to
Anthony Fremont

I've managed to get LPCs so confused that the serial bootloader was the only (or at least the easiest) way to recover. It actually works pretty well.

Reply to
Rich Webb

It has been running the blink program for 4 hours now with the PLL cranked up. For some reason Olimex doesn't seem to publish a spec stating the minimum current required to power the board. Since the supplier listed a

6VDC 200mA adapter as an "accessory", I assumed that I wouldn't need very much. Now to see if I can get some interrupts working. :-)
Reply to
Anthony Fremont

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.