at91sam7-linux so far..

Development Boards MicroMod
1

Hello folks,

I’ve done my time waiting for the mythical P019 and decided to move on up…

Thanks to Jim’s excellent tutorial I have Eclipse-Arm running, I made the

changes needed in Fedora 4 to use Sun’s Java and Eclipse 3.2 . Here’s a

site I found helpful for adapting makefiles to Eclipse:

http://www-128.ibm.com/developerworks/e … index.html

Thanks, Jack !

Insight ( arm-elf-insight) runs fine as an external tool from Eclipse; I found

I had to point directly at the program rather than to its symbolic link

in /usr/local/bin; I also needed to add environment variables for

ITCL_LIBRARY and ITK_LIBRARY for my particulaar setup

I ordered the at91sam7 board and the ‘ollie-gler’ , was pleasantly surprised when the package arrived promptly … thanks Sparkfun & Olimex !

Pleasure turned to delight when OpenOCD connected to Eclipse-Insight

without a hitch … Thanks Dominic !

Of couse, I have questions …

First, I’m not getting a lot of sense from my debug session. I can’t seem

to get sensible single stepping from reset. I’ve tried different code and I’m

concentrating on Martin Thomas’ at91sam7-gpio compiled with arm-elf-gcc.

Should I be compiling for RAM ?

Should I be able to step from PC=0x0000 through the entire startup

using the ollie-gler JTAG interface ?

What daemon / target reset options are correct for the ollie-gler ?

target reset_halt with trst seems to prevent ocd from connecting

run_and_halt works with with trst but the PC end up … anywhere

The config script in the openOcd package looks different from the one

(in German) for at91sam7 on the openOcd wiki … what is correct ?

I tried the sam7utils but /.configure fails on my setups, there seems to

be a problem with the libreadline check. From what I can tell, in Core 4, some

of the readline functions are moved to ncurses library. Although I have

both libs ( and -devel’s ) properly installed, the configure test still fails:

configure:3504: gcc -o conftest -g -O2 conftest.c -lreadline >&5

/usr/lib/gcc/i386-redhat-linux/4.0.2/…/…/…/libreadline.so: undefined reference to `tgetnum’

/usr/lib/gcc/i386-redhat-linux/4.0.2/…/…/…/libreadline.so: undefined reference to `tgoto’

/usr/lib/gcc/i386-redhat-linux/4.0.2/…/…/…/libreadline.so: undefined reference to `tgetflag’

/usr/lib/gcc/i386-redhat-linux/4.0.2/…/…/…/libreadline.so: undefined reference to `BC’

/usr/lib/gcc/i386-redhat-linux/4.0.2/…/…/…/libreadline.so: undefined reference to `tputs’

/usr/lib/gcc/i386-redhat-linux/4.0.2/…/…/…/libreadline.so: undefined reference to `PC’

/usr/lib/gcc/i386-redhat-linux/4.0.2/…/…/…/libreadline.so: undefined reference to `tgetent’

/usr/lib/gcc/i386-redhat-linux/4.0.2/…/…/…/libreadline.so: undefined reference to `UP’

/usr/lib/gcc/i386-redhat-linux/4.0.2/…/…/…/libreadline.so: undefined reference to `tgetstr’

collect2: ld returned 1 exit status

configure:3510: $? = 1

configure: failed program was:

| /* confdefs.h. */

Hope This Helps, If anyone can offer clues, TIA !

regards polly

2

I’ll try to answer your questions regarding the OpenOCD:

I have to admit that I’m not sure whether the SAM7s support debug out of reset - there’s a tradeoff between flash content protection (intellectual property) and debugability. Philips (LPC2000) chose to prevent debugging out of reset, and I just got a SAM7 to test with today, so it’ll take a bit until I can answer this for sure.

The setting for daemon_startup is mostly a matter of taste. If you want OpenOCD to reset your target when you start the daemon, choose “reset”, otherwise use “attach”. If the SAM7 has similar restrictions like the LPC, you have to use “reset_run”, “run_and_halt” or “run_and_init” in the target line.

What should work is “run_and_halt” together with a “soft_reset_halt”. “run_and_halt” lets the target run for a while (allowing an on-chip bootloader to enable JTAG) and then stops it. “soft_reset_halt” simulates a reset by cleaning the registers and setting the PC to 0x0 - if any peripherals (especially PLL and memory controllers) have already been set up, they wont be reset.

If you’re in doubt if OpenOCD is working correctly, try the telnet interface first. Also, make sure that you’re using a current version of OpenOCD - the latest SVN version usually works best. There are no real problems that I currently know of - everytime something doesn’t work, it turned out to be a configuration problem - though I have to admit that might be due to the documentation (http://openfacts.berlios.de/index-en.ph … le=OpenOCD, which isn’t easy to find, and probably not easy enough to understand (and certainly not complete). If you have a problem, use the openocd forums (http://developer.berlios.de/forum/?group_id=4148), or contact me by email.

Best regards,

Dominic

3

Dominic, Thanks for your very helpful reply. Those are issues I had not

considered, I was expecting to do a ‘RAM’ build, download via JTAG

and step thru the startup code.

I will try the soft_reset approach and will post to openOCD forum if

I see any problems. Tks again for a useful utility, best regards

Polly

4

Even if you don’t use the flash, the LPC for example prevents debugging out of reset. If a debugger had a chance to gain control from the very first instruction executed, it might compromise system security. I’ll post here once I had more time to play with the SAM7.

Regards,

Dominic