[solved] openocd regression or configuration issue?

Development Boards MicroMod
1

I have an Atmel AT91SAM7S256, and I use OpenOCD and a parallel port wiggler to program the flash. I’m reusing the OOCD configs/scripts that my coworkers have been using for at least a year. I tried to go the easy route and install the OOCD from Ubuntu 7.10 (rev 188), but it didn’t work. So I installed 128, which is what my coworkers use, and it worked. I did a binary search to find out which rev the regression happened in, and 141 is the first one that doesn’t work. I saw that there was a bunch of work done on the arm7 code in that rev, but I’m pretty unfamiliar with the details so I can’t see what’s wrong.

openocd_at91sam7s_flash.script

# The following command wills be executed on
# reset (because of run_and_init in the config-file)
# - halt target
# - init ecr
# - flash content of file main.bin into target-memory
# - shutdown openocd
#
# created by Martin Thomas 
# http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects
# based on information from Dominic Rath 
#

halt
sleep 50
wait_halt

# Init - taken form the script openocd_at91sam7_ecr.script 
mww 0xfffffd44 0x00008000	# disable watchdog
mww 0xfffffd08 0xa5000001	# enable user reset
mww 0xfffffc20 0x00000601	# CKGR_MOR : enable the main oscillator
sleep 50
mww 0xfffffc2c 0x00481c0e 	# CKGR_PLLR: 96.1097 MHz
sleep 50
mww 0xfffffc30 0x00000007	# PMC_MCKR : MCK = PLL / 2 ~= 48 MHz
sleep 50
mww 0xffffff60 0x003c0100	# MC_FMR: flash mode (FWS=1,FMCN=60)
# arm7_9 force_hw_bkpts enable	# program resides in flash

# AT91SAM7 flash command-"batch"
arm7_9 dcc_downloads enable
flash probe 0
flash write 0 main.bin 0x0
sleep 50
reset run
sleep 50
shutdown

openocd_at91sam7s_flash_wiggler.cfg

#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface parport
#parport_port 0x378
parport_port /dev/parport0
parport_cable wiggler
jtag_speed 0

#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config srst_only srst_pulls_trst

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

#target <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
target arm7tdmi little run_and_init 0 arm7tdmi
run_and_halt_time 0 30

# flash-options AT91
target_script 0 reset openocd_at91sam7s_flash.script
working_area 0 0x00200000 0x4000 nobackup
flash bank at91sam7 0 0 0 0 0

Here is the output of openocd: http://pastebin.com/mf14eb61

2

Hi

It is a bit hard to see the differences since one version (rev 140) is logged with default debug level and the other (rev 141) is logged with debug level 3 (-d 3).

The best would be to run both revisions with the same debug levels.

Can you describe what is not working, how does this show ?

Error messages or non working targets ?

Regards

Magnus

3

The output of the broken version with default debug level is the same as what I posted without the “Debug:” lines.

Info:    openocd.c:86 main(): Open On-Chip Debugger (2007-04-11 16:20 CEST)
Warning: arm7_9_common.c:685 arm7_9_assert_reset(): srst resets test logic, too

Here is a pastebin of the verbose output: http://pastebin.com/m77120041

It just gets stuck there, I have to CTRL-C to kill it. It doesn’t stop the target, because I have a program on there to blink an LED and it never stops.

4

Strange,

I have compiled a r141 version and tested your config and script on a Olimex AT91SAM7S64 board and it works without problems.

There are some small differences, I am using a FTDI USB jtag adapter, and I do not do the actual flash writing. But I get past the initialisation, into the script and nothing hangs.

What board are you using ?

The things I can see that might make a difference are:

  • run_and_halt_time 0 30 - default is 1000

  • run_and_init as reset behaviour, try reset_halt or run_and_halt

  • or try the latest revision

Regards

Magnus

5

I think the run_and_halt time is the problem. When I set it to 1000, it works. Same with latest rev (231). So it was a configuration issue. Thanks for the help.

BTW, I was using an Atmel AT91SAM7S-EK and an Atmel AT91SAM7SE-EK.