Reply by Anthony Fremont●October 13, 20072007-10-13
Rich Webb wrote:
> On Sat, 13 Oct 2007 10:01:43 -0500, "Anthony Fremont"
> <nobody@noplace.net> wrote:
>
>> Rich Webb wrote:
>>> On Fri, 12 Oct 2007 08:56:00 -0500, "Anthony Fremont"
>>> <nobody@noplace.net> wrote:
>>>
>>>> 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.
>>>
>>> Have you tried a program load to flash using the Philips/NXP serial
>>> bootloader?
>>
>> I haven't gotten to that point just yet, I was thinking that running
>> from RAM would be easier at first.
>
> 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.
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 by Rich Webb●October 13, 20072007-10-13
On Sat, 13 Oct 2007 10:01:43 -0500, "Anthony Fremont"
<nobody@noplace.net> wrote:
>Rich Webb wrote:
>> On Fri, 12 Oct 2007 08:56:00 -0500, "Anthony Fremont"
>> <nobody@noplace.net> wrote:
>>
>>> 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.
>>
>> Have you tried a program load to flash using the Philips/NXP serial
>> bootloader?
>
>I haven't gotten to that point just yet, I was thinking that running from
>RAM would be easier at first.
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 by Anthony Fremont●October 13, 20072007-10-13
Rich Webb wrote:
> On Fri, 12 Oct 2007 08:56:00 -0500, "Anthony Fremont"
> <nobody@noplace.net> wrote:
>
>> 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.
>
> Have you tried a program load to flash using the Philips/NXP serial
> bootloader?
I haven't gotten to that point just yet, I was thinking that running from
RAM would be easier at first.
> Are you 100% sure that the pins that must be pulled-up on
> reset, are?
I'm using an Olimex dev board, and the schematic looks ok.
> What do the power rails look like?
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.....
> Are interrupts enabled, and have you taken care to trap the known spurious
> interrupts that
> family is vulnerable to? (See NXP appnote AN10414.)
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 by Anthony Fremont●October 12, 20072007-10-12
Don McKenzie wrote:
> If you don't get a response from this group, it may pay to drop your
> message on the Olimex support group at:
> http://forum.sparkfun.com/index.php
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 by Rich Webb●October 12, 20072007-10-12
On Fri, 12 Oct 2007 08:56:00 -0500, "Anthony Fremont"
<nobody@noplace.net> wrote:
>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.
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 by Don McKenzie●October 12, 20072007-10-12
Anthony Fremont wrote:
> 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 by Anthony Fremont●October 12, 20072007-10-12
karthikbalaguru wrote:
> On Oct 12, 6:56 pm, "Anthony Fremont" <nob...@noplace.net> wrote:
>> 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).
>
> 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 . :( )
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?"
>> 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).
>
> 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 ?
The IP is the only thing that is consistantly pointing at 0x00000688.
>> 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:
>
> Can you show the snapshot of this ?
>
>> 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?
>
> 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
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.
>> 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.
>
> Are you not able to single step for even a single instruction ?
It single steps just fine.
> Did you load your application at the correct place in the Memory ?
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.
> Are you directing the bootloader/main application correctly to load
> your application from that correct location ?
I'm not using any boot loader, just JTAG to plunk the code into RAM and run
it.
> Are you able to get pass through the entry point ?
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.
> Did your LED blink atleast once or were you able to step into those
> LED related routines ?
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 <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
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 <base> <size> 0 0 <target#> <variant>
flash bank lpc2000 0x0 0x20000 0 0 0 lpc2000_v1 14765 calc_checksum
*********************
> Is there any abnormal declaration or defintion ?
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 by karthikbalaguru●October 12, 20072007-10-12
On Oct 12, 6:56 pm, "Anthony Fremont" <nob...@noplace.net> wrote:
> 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).
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 . :( )
> 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).
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 ?
>
> 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:
Can you show the snapshot of this ?
> 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?
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
>
> 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.
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 by Anthony Fremont●October 12, 20072007-10-12
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.