Wed Sep 15 14:47:30 CEST 2010

OpenOCD on Olimex ARM-USB-OCD

# Starting with "apt-get install openocd" I get openocd which seems to
# support the FT2232 (see openocd -c interface_list).

# Scripts are relative to /usr/share/openocd/ in my install.

# This also seems to have config support for an the Olimex SAM7-EX256
# board[3].  scripts/board/olimex_sam7_ex256.cfg

# The script only sources this script:

# I have the SAM7-H256 board[2] connected, so it should just work.

# For the programmer Olimex ARM-USB-OCD it seems these scripts are used:

# To use these scripts (had to use sudo -> need to fix perms).

$ cd /usr/share/openocd/scripts
$ openocd --file interface/arm-usb-ocd.cfg  --file target/sam7x256.cfg 
Open On-Chip Debugger 0.4.0 (2010-02-23-16:59)
Licensed under GNU GPL v2
For bug reports, read
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
Info : clock speed 6000 kHz
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Info : Embedded ICE version 1
Info : sam7x256.cpu: hardware has 2 breakpoint/watchpoint units

# The default port is 3333.

$ arm-eabi-gdb
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0x00000000 in ?? ()

# Now the `monitor' command can be used.
(gdb) monitor help
# for output see [4]

# Trying to upload the code gives this:

(gdb) load
Loading section .text, size 0x14595 lma 0x1000000
Load failed

# The OpenOCD output gives:
Warn : memory write caused data abort (address: 0x01000000, size: 0x4, count: 0xf24)

# It seems to be writing to Flash as if it were RAM.  My guess is that
# gdb also needs to be told where things are.

# The gdbinitscript I have for the Segger JTAG / gdbserver just talks
# to the monitor (gdbserver) giving it some non-standard commands to
# enable flash writing.

(gdb) monitor flash list
{name at91sam7 base 1048576 size 262144 bus_width 4 chip_width 0}
(gdb) monitor flash banks
#0: at91sam7 at 0x00100000, size 0x00040000, buswidth 4, chipwidth 0

# Ah, maybe it's protected memory?

(gdb) monitor flash info 0
#0 : at91sam7 at 0x00100000, size 0x00040000, buswidth 4, chipwidth 0
	#  0: 0x00000000 (0x4000 16kB) protected
	#  1: 0x00004000 (0x4000 16kB) protected
	#  2: 0x00008000 (0x4000 16kB) not protected
	#  3: 0x0000c000 (0x4000 16kB) not protected
	#  4: 0x00010000 (0x4000 16kB) not protected
	#  5: 0x00014000 (0x4000 16kB) not protected
	#  6: 0x00018000 (0x4000 16kB) not protected
	#  7: 0x0001c000 (0x4000 16kB) not protected
	#  8: 0x00020000 (0x4000 16kB) not protected
	#  9: 0x00024000 (0x4000 16kB) not protected
	# 10: 0x00028000 (0x4000 16kB) not protected
	# 11: 0x0002c000 (0x4000 16kB) not protected
	# 12: 0x00030000 (0x4000 16kB) not protected
	# 13: 0x00034000 (0x4000 16kB) not protected
	# 14: 0x00038000 (0x4000 16kB) not protected
	# 15: 0x0003c000 (0x4000 16kB) not protected

 at91sam7 driver information: Chip is AT91SAM7S256
 Cidr: 0x270b0941 | Arch: 0x0070 | Eproc: ARM7TDMI | Version: 0x001 | Flashsize: 0x00040000
 Master clock (estimated): 48054 KHz | External clock: 18432 KHz
 Pagesize: 256 bytes | Lockbits(16): 2 0x0003 | Pages in lock region: 128 
 Securitybit: 0 | Nvmbits(2): 0 0x0

# Switching off protection of the first two sectors:

(gdb) mon flash protect 0 0 1 off
cleared protection for sectors 0 through 1 on flash bank 0

# Something fishy..  The "flash info 0" command says the flash is at
# 0x00100000, while I'm trying to load it at 0x01000000?

# Do the SAM7S256 and SAM7S512 use different memory maps? No.

# Why is lma set to 0x01000000?  The error message also says that's
# the address with a write error.

# OK, that was stupid.  It was a linux/i386 elf.  Fixing that:

(gdb) load
Loading section .rom_vectors, size 0x40 lma 0x100000
Loading section .text, size 0x1805c lma 0x100040
Loading section .rodata, size 0x2084 lma 0x11809c
Loading section .got, size 0x23c lma 0x11a120
Loading section .data, size 0xcec lma 0x11a35c
Start address 0x100040, load size 110664
Transfer rate: 5 KB/sec, 10060 bytes/write.

# Then stepping through the code works, and is quite fast too.
# Breakpoints work up to 2.  My original app code for SAM7X512 does
# eventuall hang on the SAM7X256.  It freezes somewhere in HAL config.

# Let's see if upload speed can be set a bit higher.  It doesn't seem
# to be the JTAG speed (at 6MHz).  Something else causes only 5Kb/sec
# transfer rate.  Seems I'm not the only one with the problem[5] on
# this hardware.

# Using fast memory access (slow is potentially safer?) it does seem
# to work a bit faster: 5 -> 9 kB/sec.

(gdb) monitor arm7_9 fast_memory_access enable

[1] http://www.openhardware.net/Embedded_ARM/OpenOCD_JTAG/
[2] http://www.olimex.com/dev/sam7-h256.html
[3] http://www.olimex.com/dev/sam7-ex256.html
[4] entry://20100915-174237
[5] https://lists.berlios.de/pipermail/openocd-development/2010-July/015961.html