Using OpenOCD/GDB with AT91SAM7S / AT91SAM7X & wiggler?

Development Boards MicroMod
1

I am a bit confused with the basic setup/commands to use OpenOCD/GDB for debugging the AT91SAM7 series with an Olimex “wiggler”. It is working strangely from what I am used to. (I’ve had a little experience setting up j-link/jlinkgdbserver and GDB, but gave up because there is little support for jlinkGDBserver.)

I’d like to be able to

  1. Halt code running from flash

  2. “Completely” reset processor

  3. Run code from 0x0

First thing: When I connect to OpenOCD with GDB (target remote localhost:3333), my target halts execution immediately. Why? When I was using the Jlink, I would have to specifically issue a “monitor reset” command. This isn’t serious, it’s just peculiar.

Second: On my SAM7X board, OpenOCD apparently can not do a full hardware reset. I see this because after execution halts, and I issue a “monitor reset halt” command, some of the LEDS on the PIO lines may still be lit up. Also, “monitor reset halt” does not set pc to zero. Shouldn’t it?

  • Joe

Here is the config file I am using:

# openocd cfg file for AT91SAM7S/X

# For more information about the configuration files, take a look at:
# http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+Debugger


#daemon configuration
telnet_port 4444
gdb_port 3333

# When daemon starts, you can "reset" target or simply "attach"
daemon_startup attach


#interface setup for wiggler
interface parport
parport_port 0x378
parport_cable wiggler
jtag_speed 0


#On AT91SAM7S64-EK ans AT91SAM7X256-EK, TRST is always pulled up.
reset_config srst_only

# Wait after reset in ms
# I just picked an arbitrary value to see if it makes any difference
# (it can't hurt, can it?)
jtag_nsrst_delay 100 


#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe


# The target is halted after gdb connection.  Why?
# I am assuming this startup mode is what defines what happens 

#target <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>

#This works on SAM7S:
#target arm7tdmi little run_and_halt 0 arm7tdmi_r4
#run_and_halt_time 0 30

#Try this:
target arm7tdmi little reset_halt 0 arm7tdmi_r4

###### Flash stuff untested #######
# For AT91SAM7, flash config values are looked up after reading the chip-id and type
flash bank at91sam7 0 0 0 0 0
2

Hi,

1.: That’s what GDB expects - when it attaches to a target, you get a GDB prompt, and GDB believes the target is halted.

2.: I just tried with a SAM7-H64 board from Olimex, and I could halt out of reset with no problems. I should have access to a SAM7X based system in the next few days, but I’m fairly confident that there’s no difference in that rgard.

You have to be careful when using some of the monitor commands. The GDB doesn’t get informed about what happened after the ‘monitor’ command, i.e. it doesn’t know the target state changed. You’ll have to set the PC manually to 0x0, using “set $pc = 0x0” after issuing the reset command.

If you’re still having problems, send the complete debugging output (run with “-d -l ”) to Dominic.Rath gmx.de

Regards,

Dominic