Can't debug in RAM openOCD+Eclipse+Olimex ARM-USB-OCD

Hi friends of the AT91SAM
Im new in ARM and in your group. I get the following errors after
erase all the flash with SAM-Prog and try to debug the example
'demo_at91sam7_p64_blink_ram'. I have done only little chances in the
board.h to support my AT91SAM7S128 chip.

Info: openocd.c:84 main(): Open On-Chip Debugger (2006-01-26 13:30 CET)
Warning: arm7_9_common.c:683 arm7_9_assert_reset(): srst resets test
logic, too
Warning: arm7_9_common.c:842 arm7_9_halt(): target was already halted
Info: server.c:67 add_connection(): accepted 'gdb' connection from 0
Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused
data abort (address: 0x8f78501d, size: 0x1, count: 0x8)
Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused
data abort (address: 0x8f78501d, size: 0x1, count: 0x1)
Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused
data abort (address: 0x8f78501d, size: 0x1, count: 0x1)
Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused
data abort (address: 0x364f5d7e, size: 0x1, count: 0x4)
Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused
data abort (address: 0x364f5d7e, size: 0x1, count: 0x4)
Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused
data abort (address: 0x364f5d7e, size: 0x1, count: 0x4)
Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused
data abort (address: 0x364f5d9e, size: 0x1, count: 0x4)
Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused
data abort (address: 0x364f5d9e, size: 0x1, count: 0x4)
Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused
data abort (address: 0x364f5d9e, size: 0x1, count: 0x4)
Hardware:

AT91SAM7S128
JTAG Olimex ARM-USB-OCD

Software:
WindowsXP
openocd-2007re128
Yagarto (yagarto-bu-2.17_gcc-4.1.1-c-c++_nl-1.14.0_gi-6.5.5.exe)
Yargarto IDE eclipse 3.2 (yagarto-ide-20061002)

Installation after this great tutorial: Using Open Source Tools for
AT91SAM7S Cross Development revision 2.pdf

Flash example works fine but with ram example i get the errors above.
What can be the problem? I suppose, I can't get write access for some
registers, but I do not know why.
Can somebody explane me this? What can I do?
Thanks a lot and cheers

John Start a New Thread

Hi John.

The AT91SAM7S128 has 128K of FLASH and 32K of RAM.

Forgive me if I'm suggesting the obvious, but with 32K RAM you have to
make sure that:

top-of-stack is: _stack_end = 0x7FFC; (in the linker .cmd file)

are you good to go on that?

Cheers,
Jim Lynch Start a New Thread

Thanks Jim for answering so quickly and don't be afraid to ask me this
things. You are right, at the beginning everyone can make a lot of
mistakes with ARM.

The stack and the memory I had chanced before. But there was a lot of
more mistakes. First I erased flash again (with SAMBA 1.7), maybe the
first one was not correct.

Than I chanced the debugconfiguration to (if I ask over telnet
commandwindow the openOCD server, what is the core_state, it always
shows thumb, that's why I insert the second line)

target remote localhost:3333
monitor armv4_5 core_state arm
monitor soft_reset_halt
monitor mww 0xFFFFFF00 0x01
monitor reg pc 0x00000000
monitor arm7_9 sw_bkpts enable
break main
load
continue

And also I had forgotten to un-checked the "Stop on startup at:" check
box .

Than it works sometimes. After I commented out the
enableIRQ();
enableFIQ();
in main.c, it works more stable.

But I have a lot of questions. I would be really glad if you could
answer me.
1) There are some little problems around debugging.
First, if I step into a function or into main, it don't stop at the
following line. It jump over some lines. Why? And also it is usual
that eclips hang up sometimes?
2) Where are the interruptvectors if I load the program into RAM?
Where can I see the memory map and the place of the interrupt vectors?
How can I imaging, that the program is in RAM? Can you explane this
with a addressdecoder or something else around hardware? And if I turn
off the power and turn on the power, the program is still in the
memory. I always thought, that after turn power of, the RAM is erased?
3) I played with the gnu-tool "size" in the makefile. I get this
output during compiling:

arm-elf-size -A main.o
main.o :
section size addr
.text 572 0
.data 60 0
.bss 16 0
.debug_abbrev 278 0
.debug_info 2528 0
.debug_line 112 0
.rodata 40 0
.debug_frame 48 0
.debug_loc 42 0
.debug_pubnames 88 0
.debug_aranges 32 0
.debug_str 68 0
.comment 18 0
Total 3902

Can you explane me, what all this mean? Now I ask me, how large is the
file, that really will downloaded into the RAM? I looked the
properties of the main.out file, the size is 48862 bytes and this I
don't understand, because that's more than my RAM size is, so normally
it can't work? That's why I ask, what and how many I really download?
It can't be the hole main.out

4) If I want to delete some lockbits? How do I see, if something is
locked? If I try the OpenOCD and do a connection with the
commandwindow (with localhost 4444 and so on) the instruction flash
erase does not exists. I always get the error messages:

Open On-Chip Debugger
> help flash
flash no help available
> flash erase 0 0 7
Command erase not found
> flash info 0
Command info not found
> flash erase 0 0 15
Command erase not found
>

5) At least for today I want to explain for myself, how OpenOCD and
JTAG of the C and eclipse work together, but I don't know really, if
I'm right. OpenOCD works as a SERVER, it has a open port number 4444.
eclipse or the commandwindow works as a CLIENT, the portnumber of the
client is 4444 to. If the client is connected to the server, he can
send some instructions. The server understand this and convert this
into JTAG-Instructions and send this through a USB (with the
USB-driver) to the ARM-USB-OCD. Into the ARM-USB-OCD there is a FT2322
chip, and it can convert the USB-packets into the JTAG-instructions
for the C ARM. The ARM itself cannt send any instruction, it can only
answer to the instructions from the Server. Is all this ok, or are
there some mistakes in my thinking. And whats about the
arm-elf-gdb.exe? Is this a server too?

Please accept my apologies for all this questions.I'm really glad
about this forum and the knowledge of all of you. Around me there is
nobody how knowing much about the ARM. Thanks a lot.

Cheers
John

--- In A..., "lynchzilla" wrote:
>
> Hi John.
>
> The AT91SAM7S128 has 128K of FLASH and 32K of RAM.
>
> Forgive me if I'm suggesting the obvious, but with 32K RAM you have to
> make sure that:
>
> top-of-stack is: _stack_end = 0x7FFC; (in the linker .cmd file)
>
> are you good to go on that?
>
> Cheers,
> Jim Lynch
> Start a New Thread

Hi John.

Sorry for being late with a responce, but my high-speed internet
connection went out this week and I had to deal with the local cable
supplier to get it repaired.

1. Why doesn't it really stop at main() ?

You would expect the starting cursor to be right at the main() line,
but it never does that. It stops at the first executable statement
and that typically is a variable initialization right under main().
For example, if you define int icount = 5; at the top of your main
module, that act of initializing the value of icount to five is an
executable statement and the debugger will stop there. Relax, it
drives me crazy also!
2. Where are the vectors if you load the application into RAM?

There's a typographical error in my Revision C tutorial, I had
intended that you define the RAM as starting at address 0x00000000 in
the linker script and thus load everything (.text, .data, .bss,) into
RAM at address 0x00000000. Doing it this way makes more sense. When
you start the debugger and toggle that MC Remap Control register,
this overlays the RAM at address 0x200000 to address 0x000000. Now
the vectors are at address 0 as they are supposed to be and all is
well. It's just as if the Flash had become read/write.

My latest tutorial says to load everything into RAM at 0x200000 and
then toggle the MC Remap register. This also works perfectly well.
The vectors are at 0x200000 but are mapped also to address
0x00000000. Therefore, any read/write to address 0x200000 also
read/writes to address 0x00000000. The hardware activates the vector
at address 0x00000000 and while your vectors are defined at 0x200000 -
they both occupy the same space so your vector is triggered at
0x200000 also.

You should also consider what happens to the FLASH after the MC
Remap? It now resides at address 0x100000 and stays there. Under
normal operating conditions, it remaps after boot from the region at
0x100000 to address 0x00000000 but this doesn't happen if you toggle
the MC Remap register. It stays in it's official location 0x100000.

3. The size of the main.out file seems huge?

You are forgetting that the main.out file contains not only the
executable code, but all the symbol information as well. You program
the flash with the main.bin file and you can see how much was loaded
by inspecting the map file or the main.dmp file. In my example, the
actual amount downloaded into RAM (.text, .data, .bss) is about 5000
bytes.

4. Please explain the lock bits?

The Atmel AT91SAM7S256 has 256k of FLASH memory organized as 1024
pages of 256 bytes/page. The AT91SAM7S256 memory is further
subdivided into "LOCK regions". There are 16 LOCK regions and each
comprises 64 pages (16384 bytes per lock region). You cannot erase or
program any of the words or pages in a locked region.

The LOCK bits can be set or cleared using the MC Flash Command
Register (MC_FCR) at address 0xFFFFFF60. The MC Flash command
register has 3 fields that you must specify.

FCMD = 0100 = 0x04 Clear Lock Bit Command

PAGEN = any page number within the region you want to lock If you
typically choose the first page in the lock region, we would have the
following encoding:

Lock Region Page Number
0 0x000
1 0x040
2 0x080
3 0x0C0
:
:
63 0x3C0

KEY = 0x5A (fixed constant)

Example: to lock the first five LOCK bits (regions), enter the
following bit patterns into the MC Flash Command Register

0xFFFFFF60 = 0x5A000004 # lock region 0 (Lock Bit 0)
0xFFFFFF60 = 0x5A004004 # lock region 1 (Lock Bit 1)
0xFFFFFF60 = 0x5A008004 # lock region 2 (Lock Bit 2)
0xFFFFFF60 = 0x5A00C004 # lock region 3 (Lock Bit 3)
0xFFFFFF60 = 0x5A010004 # lock region 4 (Lock Bit 4)

These are the commands you need to insert into the OpenOCD programing
script as mentioned in my tutorial (there's a typo error in the
tutorial concerning the second lock bit).

5. Please describe the client-server relationship between OpenOCD and
Eclipse?

This subject is covered in my latest revision of the Atmel
tutorial "Using Open Source Tools for AT91SAM7 Cross Development",
pages 4 - 11.

Don't lose heart about these ARM chips, everything you need to know
will be revealed by a thorough reading of the Atmel documentation.
Unfortunately, that is a daunting task!

Cheers,
Jim Lynch Start a New Thread

--- In A..., "johnsign_jonny"
wrote:

> 1) There are some little problems around debugging.
> First, if I step into a function or into main, it don't stop at the
> following line. It jump over some lines. Why? And also it is usual
> that eclips hang up sometimes?

John,

Although Jim answered a lot of your questions, I'd follow up with 2:

1. If you are compiling using anything other than -O0 (disable
optimization) the order of execution in assembler may be very
different than the order you programmed in 'C'. You may see the
executon hop around between lines of 'C' code, and even go back
several times to the same line (it does what you asked in little pieces).

2. I have had Eclipse hang a bunch of times, particularly failing to
respond to a "pause". (still very new with the AT91SAM family, and
eclipse too). Sometimes you can get it to come back by doing the
following:
Pull up a terminal emulator, and connect to OpenOCD (assuming you're
using openocd! 127.0.0.1, port 4444). If you get back an OpenOCD
prompt, you can then do a manual "halt", and often, eclipse will come
back. If not, at least you can step a few and figure out what mode
the processor is in, and what the PC is.

Hope this helps! Start a New Thread