memory read caused data abort

Hi,

I try to debug a C code but I always run into a pitfall. Please somebody help me! Here

are the details:

My target is a remote target, the AT91SAM7S256 microcontoller. It has ARM7TDMI core. The

architecture of it is armv4t.

I use the openOCD created by Dominic Rath. Thank you Dominic! :slight_smile:

I didnt try this on Linux only on window$ yet. I can use the yagarto (native) or the

sourcery g++ toolchain (native, but it can use the cygwin as well)…the problem is the

same in either case.

The code which I like to debug is this:

/test.c/

main () { /This is just a test code, meaningless./

int a;

int b;

while (1) {

a=2;

b=3;

a+=b;

}

}

COMPILE

==========

I compile with these parameters:

CC -march=armv4t -mcpu=arm7tdmi -LE -g -gdwarf-2 -o test.elf test.c

where CC is arm-none-eabi-gcc (sourcery g++) or arm-elf-gcc (yagarto).

After that I create a .bin file.

OB -O binary test.elf test.bin

Where OB is arm-none-eabi-objcopy (sourcery g++) or arm-elf-objcopy (yagarto)

I can compile without any error or warning message.

I load the test.bin in the flash using JTAG wiggler interface and the

openOCD.

OPENOCD

==========

My openOCD config file contain these lines:

#Deamon configuration

gdb_port 3333

telnet_port 4444

deamon_startup attach

#JTAG interface configuration

interface parport

jtag_speed 0

reset_config srst_only

jtag_device 4 0x1 0xf 0xe

#jtag_nsrst_delay

#jtag_ntrst_delay

#Parport options

parport_port 0x378

parport_cable wiggler

#target configuration

target arm7tdmi little reset_halt 0 arm7tdmi

#run_and_halt_time

#working_area

#Flash configuration

flash bank at91sam7 0 0 0 0 0

After the start I have got 2 info:

info: openocd.c:82 main(): Open On-Chip Debbuger (2006-09-28 20:00 CEST)

info: configuration.c:50 configuration_output_handler(): Command

deamon_startup not found

I dont know what is mean the second one, but there is no problem in during

the flash write. I load the test.bin in the flash using telnet.

LOAD the test.bin

===================

Start the telnet:

telnet localhost 4444

I get a prompt like this:

Open On-Chip Debugger

The sequence is:

soft reset

flash erase 0 0 15

flash write 0 test.bin 0

soft reset

arm7_9 sw_bkpts enable

This works well.

Debug

=====================

I use the arm-elf or the arm-none-eabi gdb…I will sign this just gdb.

start:

gdb test.elf

then it write some line information about himself. I think maybe this would be

important:

This GDB was configured as “–host=i686-pc-mingw32 --target=arm-elf” …

(yagarto)

–target=arm-none-eabi"

…(sourcery g++)

I have a celeron 800MHz.

Then I connect to the remote target (the prompt is (gdb) now )

(gdb)target remote localhost:3333

Remote debugging using localhost:3333

0x000048a0 in ?? ()

(gdb)

Now if I try to execute a “step” or “next” I see:

(gdb)next

Cannot find bounds of current function

(gdb)step

Cannot find bounds of current function

Daniel Jacobowitz wrote me I am not in the main().I have to make a

breakpoint at the entry of the main and execute the continue

command. Thank You Daniel! If I do this then:

(gdb)break main

Breakpoint 1 at 0x821c: file test.c, line 6.

(gdb)continue

Continuing.

Thats all…I dont get back the (gdb) prompt…:frowning:

openOCD deamon write an error message:

error: arm7_9_common.c:1771 arm7_9_read_memory():memory read caused data abort

What is this? :slight_smile: I dont understand. Please!

Where is the mistake? What I can do? Please somebody help me!

The list command is alright and I can debug assembly code without

any trouble.

Thank You!

David

Hello DÃ vid,

info: configuration.c:50 configuration_output_handler(): Command

deamon_startup not found

You have a typo in your config file, the syntax is “daemon_startup” (the command allows you to specify whether the target should be reset when you launch the OpenOCD.

arm7_9 sw_bkpts enable

You can’t use software breakpoints in flash. To debug code running in flash, you have to use one of the two hardware breakpoints. GDB normally requests software breakpoints, so you have to use

“arm7_9 force_hw_bkpts enable” to make the OpenOCD use a HW breakpoint for every requested bp.

You didn’t break in main() because the OpenOCD tried writing the trap for a sw breakpoint at the location in flash, which of course failed, but didn’t produce an immediate error.

Best regards,

Dominic

Hi Dominic!

Thank You! :slight_smile: I emend the text in the config file. The openOCD can find the deamon_startup now :slight_smile: , but I am in the same trouble :frowning:

I tell to the gdb “set debug remote 1”. You can see more information abut the trouble:

C:\Documents and Settings_DAV_\Asztal>arm-elf-gdb test.elf

GNU gdb 6.5.50.20060612-cvs

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type “show copying” to see the conditions.

There is absolutely no warranty for GDB. Type “show warranty” for details.

This GDB was configured as “–host=i686-pc-mingw32 --target=arm-elf”…

(gdb) target remote localhost:3333

Remote debugging using localhost:3333

0x00000000 in ?? ()

(gdb) monitor poll

target state: halted

target halted in ARM state due to debug request, current mode: Supervisor

cpsr: 0x600000d3 pc: 0x00000000

(gdb) monitor arm7_9 force_hw_bkpts enable

force hardware breakpoints enabled

(gdb) set debug remote 1

(gdb) break main

Breakpoint 1 at 0x821c: file test.c, line 6.

(gdb) continue

Continuing.

Sending packet: $Z0,821c,4#14…Ack

Packet received: OK

Packet Z0 (software-breakpoint) is supported

Sending packet: $vCont?#49…Ack

Packet received:

Packet vCont (verbose-resume) is NOT supported

Sending packet: $Hc0#db…Ack

Packet received:

Sending packet: $c#63…Ack

_

This is the end…I dont get back the prompt…Please help me!

Is this maybe because a hardware settings? I have to set the PA0 PA1 PA2 and TST pins or it has no effect now? Thank You!

How do you know my name is DÃ¥vid instead of David? :slight_smile:

DÃ¥vid

Hello David

Are you sure you have valid startup code linked in, otherwise you will never reach main.

Do youn have a linker map where you can check if the first halt point 0x000048a0

is witinh your code?

Regards,

Magnus

Hi,

Thank You!

I think we reach the critical part of this problem, because I suppose only what is that map file. :slight_smile: Sorry…Do You mean if I have no startup code so there is no vector table in the address 0x0 then the reset handler wont start and at the end of the reset rouotin wont jump to the main? So if I have no startup file then there is no guarantee for the main will be at the address 0x0. Therefore there is a lot instruction between the address 0x0 and the main and when I tell a “continue” to the GDB then it try to execute all of them and never reach the main. For example there is an instruction before main which enable the interrupts and I got one and because there is no real vector table it will jump somewhere and the system will be chaotic…Do I understand it well?

I have a startup code, but I have to amend something on that. I will try to link that. Can somebody tell me what is the map file exactly? Do I have to tell “-Map FILE” to the ld to create map file too? Does it tell me what the linker did? I like the assembly, but I like to know how can I write startup code in C? How can I make a vector table? I mean If I write the code in C, how can I reach that will be at address 0x0?

Sorry because I am an idiot! Thank You!

DÃ¥vid

Hi

The map file list all symbols, variable and function names, and their placement in memory, RAM and FLASH.

The lowlevel startup code and vector table definition is written in assembler and is usally called someting like crt.s, init.s, CStartup.S or vector.s

This contains the irq table, defult interrupt handlers, some lowlevel stack and variable initialisation code and a jump to main. Then C starts.

If this is missing or corrupted then the processor, that always starts at the reset vector 0x0, finds invalid instructions and or data references and end up in abort mode.

This happens even if the abort vector is corrupted, only the abort handler consists of random ramblings i code space, never to return.

Read the Eclipse tutorial by J Lynch, se neighboor thread. Look at startup code and makefiles in example projects.

Greetings,

Magnus

Hi

This tutorial looks awesome! Very good! Thanks a lot! Can You recommend me other good books or tutorial like this? Thank You!

regards

DÃ¥vid