OpenOCD: single stepping fails

[meixner]

Hello all!

I have managed to install openocd version 0.4.0 along gdb version 6.8 and already managed to set a single break point. But then I get stuck: When my program stops at the breakpoint I can not single step through the application. This is the gdb session:

$ /c/arm-gcc/bin/arm-eabi-gdb.exe hello.elf

GNU gdb 6.8

Copyright (C) 2008 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type “show copying”

and “show warranty” for details.

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

(gdb) target remote |openocd --pipe

Remote debugging using |openocd --pipe

Open On-Chip Debugger 0.4.0 (2010-06-29-13:14)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.berlios.de/doc/doxygen/bugs.html

0x00000000 in ?? ()

(gdb) mon halt

target state: halted

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

cpsr: 0x80000033 pc: 0x00c508b0

MMU: enabled, D-Cache: enabled, I-Cache: enabled

(gdb) b vMain

Breakpoint 1 at 0xbd74d2: file src/hello.cpp, line 45.

(gdb) cont

Continuing.

Breakpoint 1, vMain () at src/hello.cpp:45

45 B b;

Current language: auto; currently c++

(gdb) n

Breakpoint 1, vMain () at src/hello.cpp:45

45 B b;

(gdb) n

Breakpoint 1, vMain () at src/hello.cpp:45

45 B b;

(gdb) n

Breakpoint 1, vMain () at src/hello.cpp:45

45 B b;

(gdb) n

Breakpoint 1, vMain () at src/hello.cpp:45

45 B b;

(gdb) delete 1

(gdb) n

As you can see the PC is just not increased when trying to step. When I delete the breakpoint “n” just does not return.

The code lives in flash, i.e. I have to use hardware breakpoints. I use the following configuration:

source [find interface/olimex-jtag-tiny.cfg]

source [find target/at91rm9200.cfg]

flash bank xip cfi 0x400000 0xC00000 2 2 $_TARGETNAME

telnet_port 4444

gdb_port 3333

arm7_9 fast_memory_access enable

Although I use “flash bank” gdb does not seem to detect the flash and “info mem” does list it. I also played around with “gdb_breakpoint_override hard” which also did not help.

So what is missing that I can single step through the application?

[ntfreak]

Hi,

Does single stepping work using the telnet interface?

Enabling the debug log in openocd will give you more info, eg. openocd -d 3 -l openocd.log

Are you sure your gdb is xml enabled?

Cheers

Spen

[meixner]

Hello Spen,

single stepping using the telnet interface seems to work when the CPU has been halted using the “halt” command. It does not work when the program is in the breakpoint that has been set by gdb.

I have recompiled gdb with xml support. However, this did not improve things. “info mem” still reports “There are no memory regions defined” and I have to enforce using hardware breakpoints manually.

I have attached the log generated by openocd -d 3

Any ideas?

• Matthias Meixner

[meixner]

Hello!

I did some additional testing and it seems that even using telnet single stepping does not allways work.

When in thumb mode I was not able to single step once a breakpoint was hit.

I have attached the openocd log.

• Matthias Meixner

[ntfreak]

Both these logs fail because the target is not halted, how are you executing openocd?

At minimal it should be something like this:

debug_level 3
log_output openocd.log

adapter_khz 500
reset_config trst_and_srst

source [find interface/olimex-jtag-tiny.cfg]
source [find target/at91rm9200.cfg]

init
reset init

May be also worth looking at the at91rm9200-dk.cfg config, as the jtag clock may need tweaking to suit your hardware.

Cheers

Spen

[meixner]

Hello!

I start the target and hold it in something like a loop. Then I attach to JTAG using openocd. Next I use “halt” to stop the processor followed by setting a breakpoint. Then after “resume” I toggle a switch which makes the program leave the loop. After that it hits the breakpoint. It is in thumb mode by then. Stepping does not work. Setting arm_mode to arm reenables stepping, however since there is no thumb code this is quite useless.

Adding your configuration options to openocd.cfg did not help. In fact when setting adapter_khz it did not attach any more.

• Matthias Meixner

[ntfreak]

adapter_khz is probably newer cmd, cannot remember if it was in v0.4.

The old cmd was jtag_khz, start of with a slow clock until simple operation work.

Seems a bit of a strange way to debug a target, need to go back to basics.

Cheers

Spen

[meixner]

This is an embedded device that has already tons of other software on it and this is more or less the only way that I can make the target run my own code.

I don’t think that this is a JTAG issue: I can connect to the target, I can single step in arm mode. I can set hardware breakpoints. I can use “reset”, “halt” and “resume”. And I can disassemble the arm code and it looks perfect. Now the things that do not work:

- Single stepping in thumb mode.

- Making gdb automatically use hard- or soft-breakpoints depending on the address

However, without single stepping OpenOCD is quite useless for me.

Would it help to switch to another version of openocd? I guess that I am not the first who tried to use single stepping in thumb mode with an at91rm92000.

• Matthias Meixner

[meixner]

Hello!

I did some additional testing with version 0.3.1 and 0.2.0 of openocd. All show the same behaviour: Everything works with the exception of single stepping in thumb mode.

What else could I test? Any ideas? Has anyone used OpenOCD sucessfully for single stepping in thumb mode?

• Matthias Meixner

[ntfreak]

last time i tried it working fine for me with str7 and str9 targets.

If i find time i will dig out some hardware to test.

We have had no other reports of single stepping issues.

Can you send a openocd log with a reset init then a step?

Cheers

Spen

[meixner]

Here is the log.

And here is the input/output from the telnet console:

Open On-Chip Debugger
> halt
target state: halted
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x60000033 pc: 0x00bd764c
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> reset init
JTAG tap: at91rm9200.cpu tap/device found: 0x05b0203f (mfg: 0x01f, part: 0x5b02, ver: 0x0)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000013 pc: 0x0000010c
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> bp 0xbd72c8 2 hw
breakpoint set at 0x00bd72c8
> resume
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> resume
target state: halted
target halted in Thumb state due to breakpoint, current mode: Supervisor
cpsr: 0x00000033 pc: 0x00bd72c8
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> step
target state: halted
target halted in Thumb state due to single-step, current mode: Supervisor
cpsr: 0x00000033 pc: 0x00bd72c8
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> step
target state: halted
target halted in Thumb state due to single-step, current mode: Supervisor
cpsr: 0x00000033 pc: 0x00bd72c8
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> rbp 0xbd72c8
> step
target state: halted
target halted in Thumb state due to single-step, current mode: Supervisor
cpsr: 0x00000033 pc: 0x00bd72c8
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> step
target state: halted
target halted in Thumb state due to single-step, current mode: Supervisor
cpsr: 0x00000033 pc: 0x00bd72c8
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> resume
> exit

It would be great if there was a solution to this problem.

• Matthias Meixner

[ntfreak]

Very strange indeed - just done a quick test with a str7 target and all is working as expected.

I am using latest git version, so my only suggestion is to get the latest and greatest from the git repo.

Cheers

Spen

[meixner]

Hello!

Now I compiled the latest source from the GIT repository (from July 9). The behaviour is excactly the same. Stepping does not work.

Just in case someone else is trying to compile it using Mingw: I had to run bootstrap twice with libtoolize in between

since it complained about ltmain.sh missing:

./bootstrap

libtoolize --automate --copy

./bootstrap

Then I had to add option --disable-werror to configure since it warned about a variable shadowin a parameter (which looks like a bug in mingw/gcc)

• Matthias Meixner

[a.sorio]

Hi

I have the same problem with arm-none-eabi-gdb and ddd interface.

Andrea

[meixner]

Great to hear that I am not the only one and that someone else can confirm the problem.

[a.sorio]

HI

I found this workaround:

for example, set a break point to “main”

start the program after a monitor soft_reset_halt command

the debugger stop on “main” break point.

now, disable the “main” break point.

now the ‘s’ (step) and ‘n’ (next) commands from gdb works.

Andrea

[meixner]

Hello,

this workaround does not work for me. Even when disabling all break points stepping does not work.

• Matthias

[meixner]

Hello,

it looks that I have found a solution that works for me. Disabling the use of hardware single-stepping seems to help:

--- openocd-0.4.0/src/target/arm9tdmi.c	Sun Feb 21 12:17:08 2010
+++ openocd-0.4.0a/src/target/arm9tdmi.c	Fri Aug 06 09:46:35 2010
@@ -721,7 +721,7 @@
 {
 	struct arm7_9_common *arm7_9 = target_to_arm7_9(target);
 
-	if (arm7_9->has_single_step)
+	if (0 && arm7_9->has_single_step)
 	{
 		buf_set_u32(arm7_9->eice_cache->reg_list[EICE_DBG_CTRL].value, 3, 1, 1);
 		embeddedice_store_reg(&arm7_9->eice_cache->reg_list[EICE_DBG_CTRL]);
@@ -736,7 +736,7 @@
 {
 	struct arm7_9_common *arm7_9 = target_to_arm7_9(target);
 
-	if (arm7_9->has_single_step)
+	if (0 && arm7_9->has_single_step)
 	{
 		buf_set_u32(arm7_9->eice_cache->reg_list[EICE_DBG_CTRL].value, 3, 1, 0);
 		embeddedice_store_reg(&arm7_9->eice_cache->reg_list[EICE_DBG_CTRL]);

With this patch I was able to do some single stepping.

• Matthias Meixner