How does one "run" or "reset" from withi

Development Boards MicroMod
1

How does one “run” an openocd target from within gdb ?

For example, this session…

$arm-elf-gdb -x gdb_init-manual

GNU gdb 6.5.0.20060626-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-linux-gnu --target=arm-elf”.

Breakpoint 1 at 0x240: file main.c, line 68.

0x00002238 in uart0Getch () at uart.c:121

121 if (U0LSR & ULSR_RDR) // check if character is available

Current language: auto; currently c++

force hardware breakpoints enabled

(gdb) run

The program being debugged has been started already.

Start it from the beginning? (y or n) y

Starting program: …/main.elf

Don’t know how to run. Try “help target”.

Does “monitor run” do the same thing ?

How does one reset the target ?

2

Hi,

without knowing what’s inside gdb_init-manual it’s hard to tell what is going on in your case.

The GDB remote protocol can’t ‘run’ a program, as running basically means create a new process and let that run. With the GDB remote protocol, you attach to the target (target remote localhost:3333), then ‘continue’ execution.

Resetting is a bit difficult, as the GDB remote protocol doesn’t have a reset packet (there is one, but it’s obsoleted and for a different purpose), but you can use the ‘monitor’ facility to send the reset command to the OpenOCD. Because GDB expects the target to be halted while you’re working on the GDB command line, you must not use “reset run”, only “reset halt”, “reset init”, “reset run_and_halt” or “reset run_and_init”. The versions without “run_and” only work with targets that can be debugged out of reset, i.e. not with the LPC2000 or the STR7x (among others).

Regards,

Dominic

3

Hi Dominic. Thanks in advance for your help.

“without knowing what’s inside gdb_init-manual it’s hard to tell what is going on in your case.”

OK. Lets forget about the example above. Lets look at my Eclipse Setup.

Here is my openocd config file for debugging.

OPENOCD Debug

for Philips LPC2138/2148 ARM7TDMI-S

Adapted by Martin Thomas (www.siwawi.arubi.uni-kl.de/avr_projects)

Based on information from Dominic Rath - Thank you!

#daemon configuration

telnet_port 4444

gdb_port 3333

#interface

interface ft2232

ft2232_device_desc “Olimex OpenOCD JTAG A”

ft2232_layout olimex-jtag

ft2232_vid_pid 0x15BA 0x0003

jtag_speed 2

srst_push_pull

reset_config trst_and_srst trst_pulls_srst

#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 attach

daemon_startup reset

#target

#target arm7tdmi little reset_run 0 lpc2000

target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4

run_and_halt_time 0 30

working_area 0 0x40000000 0x4000 nobackup

mthomas: LPC2138 @ 12MHz 0x7D000 from 500*1024 (not 512!)

loses 12K due to remapping of registers

flash bank lpc2000 0x0 0x7D000 0 0 lpc2000_v2 0 12000 calc_checksum

I am running the Zylin debugger plugin in Eclipse.

My "initialize’ commands are below. I am not running any ‘run’ commands.

target remote localhost:3333

monitor arm7_9 force_hw_bkpts enable

monitor soft_reset_halt

info reg pc

info breakpoints

Here is what I get in the Eclipse console for the arm-elf-gdb process:

target remote localhost:3333

uart0Getch () at uart.c:121

121 if (U0LSR & ULSR_RDR) // check if character is available

Current language: auto; currently c++

monitor arm7_9 force_hw_bkpts enable

monitor soft_reset_halt

info reg pc

pc 0x2224 8740

info breakpoints

No breakpoints or watchpoints.

The problem with this setup is that pc doesn’t get reset between runs, unless I restart openocd each time. And even then, the target runs before the debug process starts and pc doesn’t start at 0x0 in the debug process.

Am I doing something wrong ?

“The GDB remote protocol can’t ‘run’ a program, as running basically means create a new process and let that run. With the GDB remote protocol, you attach to the target (target remote localhost:3333), then ‘continue’ execution.”

OK, I changed the config file from daemon_startup reset

to daemon_startup attach

I then tested a number of command combinations and none seem to reset the pc. I want to debug some initialization routines, so I need the processor under control immediately. If I put continue into the command, the debug process locks up.

So… how do I get the processor to reset so I can debug init routines ? The only thing I have found to remotely work is soft_reset_halt, but it doesn’t always reset pc.

target remote localhost:3333

uart0Getch () at uart.c:124

124 return -1;

Current language: auto; currently c++

monitor arm7_9 force_hw_bkpts enable

monitor soft_reset_halt

info reg pc

pc 0x2260 8800

So how does one start the debugging process with the PC at the proper place ?

“Resetting is a bit difficult, as the GDB remote protocol doesn’t have a reset packet (there is one, but it’s obsoleted and for a different purpose), but you can use the ‘monitor’ facility to send the reset command to the OpenOCD.”

On my setup, that crashes the debugging session. I get a “broken pipe” error like this:

Execution is suspended because of error.

putpkt: write failed: Broken pipe.

Don’t know how to run. Try “help target”.

That was using the following command sequence:

target remote localhost:3333

__pabt () at crt0.S:69

69 __pabt: b . // program abort

Current language: auto; currently asm

monitor arm7_9 force_hw_bkpts enable

monitor reset halt

info reg pc

pc 0x40 64

Remote communication error: Connection reset by peer.

putpkt: write failed: Broken pipe.

Don’t know how to run. Try “help target”.

Or I get this:

target remote localhost:3333

0x00002240 in uart0Getch () at uart.c:121

121 if (U0LSR & ULSR_RDR) // check if character is available

Current language: auto; currently c++

monitor arm7_9 force_hw_bkpts enable

monitor reset halt

info reg pc

pc 0x2240 8768

Remote communication error: Connection reset by peer.

continue

putpkt: write failed: Broken pipe.

“Because GDB expects the target to be halted while you’re working on the GDB command line, you must not use “reset run”, only “reset halt”, “reset init”, “reset run_and_halt” or “reset run_and_init”. The versions without “run_and” only work with targets that can be debugged out of reset, i.e. not with the LPC2000 or the STR7x (among others).”

That is great to know.

So how do I start my debugging session with pc at the start of the code ?

Thanks

4

armdeveloper:
So how do I start my debugging session with pc at the start of the code ?

Thanks

Your OpenOCD config file indicates that you are running a setup for a "# for Philips LPC2138/2148 ARM7TDMI-S "

Since it is not possible to debug an LPC part out of reset, you need to load the PC with 0x00000000 after the debugger has gained control. The command “soft_reset_halt” should do that for you, if the Phillips bootloader has completed it’s execution. The LPC parts are specifically designed to prevent a debugger gaining control as the chip comes out of reset as part of their code read protection mechanism. The mechanism that Phillips uses to accomplish the defeat of debugging out of reset is to internally tie the SYSTEM RESET signal and the TAP CONTROLLER RESET signals together. So, when the system is reset the TAP controller is also reset, causing ANY debugger to loose it’s JTAG connection to ARM. The Phillips bootloader immediately disables the JTAG port as it starts up, and does not re-enable it until after it has determined that CRP is not active. The end result of all this is that the ARM has run many hundreds of clocks by the time that any debugger has access to it after reset. On an ARM processor with separately controlled resets, it IS possible to start debugging immediately after reset as long as nTRST is not asserted during nSRST. ARM Application Note 31 explains all of this in much more detail.

– Dave

5

Thanks for the explanation ! I’ve been fighting with this for a day and a half !

“Since it is not possible to debug an LPC part out of reset, you need to load the PC with 0x00000000 after the debugger has gained control. The command “soft_reset_halt” should do that for you, if the Phillips bootloader has completed it’s execution.”

OK, that makes sense. So how does one make sure that the bootloader has completed its execution so that the soft_reset_halt will work ?

I am NOT restarting openocd each time I debug. I’ve been leaving it run. So when I start a new debug process, the processor should be well out of reset, right ? Thus soft_reset_halt should do its thing every time, but it doesn’t appear to be. Can I just set pc to 0x00000000 or do I need to set/clear other things as well ?

What part does the “run_and_halt_time” parameter play in this ? If one sets that too low does the processor not get done the bootloader routine and then would that mess up the soft_reset_halt ?

Could someone share how they set up their config and scripts for Eclipse ?

Thanks

6

More questions.

Should the openocd debug process startup and attach or startup and reset ? If we want the controller to get through the bootload, we need it to reset and run, right ?

Then, do we want it to run_and_init or run_and_halt ?

I see the openocd command set has wait_halt ! So I did this, but soft_reset_halt is NOT resetting PC:

target remote localhost:3333

uart0Getch () at uart.c:121

121 if (U0LSR & ULSR_RDR) // check if character is available

Current language: auto; currently c++

monitor arm7_9 force_hw_bkpts enable

monitor soft_reset_halt

monitor wait_halt

info reg pc

pc 0x2224 8740

So do I explicitly set pc to 0x00000000 ?

7

I got it to work reliably !

I start openocd with attach and run_and_halt.

Then I start my debug process using the following “initialization” commands.

target remote localhost:3333

monitor arm7_9 force_hw_bkpts enable

monitor soft_reset_halt

monitor wait_halt

info reg pc

The first time I run the debug process, it gives me this:

target remote localhost:3333

uart0Getch () at uart.c:124

124 return -1;

Current language: auto; currently c++

monitor arm7_9 force_hw_bkpts enable

monitor soft_reset_halt

monitor wait_halt

info reg pc

pc 0x2260 8800

Cannot access memory at address 0xfffffffb

This is not what I want. I don’t understand why it doesn’t work, but it doesn’t.

However, the second time I run it, without restarting openocd, I get this:

target remote localhost:3333

_boot () at crt0.S:40

40 b _start // reset - _start

Current language: auto; currently asm

monitor arm7_9 force_hw_bkpts enable

monitor soft_reset_halt

monitor wait_halt

info reg pc

pc 0x0 0

At that point the processor is halt and the pc is sitting at the very first line of executable code and I can step through everything. That is exactly what I want ! And I didn’t even have to use a breakpoint to do it.

The only downside to this is that I have to start the debugger twice every time.

So why isn’t it working the first time ?