I’m new to OpenOCD and had it debugging out of RAM beautifully. I’ve
been getting sporadic errors verifying binary images I write to flash. This
got me interested in OpenOCD and its code. The rest of this email is a
long list of issues I encountered, some of which are probably due to
my own misunderstandings. I’d be happy to help in any way I can,
including contributing patches, but it would be nice to have somebody
orient me on some of these things first. I’d love to see OpenOCD be a
robust and widely adopted tool. My setup:
OpenOCD svn version 921 built today on Cygwin
Olimex ARM-USB-OCD
Olimex SAM7-EX256 board with at91sam7x256 processor
Default config files (see command line below)
This is the flash verification error that got this whole thing started. It
verifies properly maybe 10% of the time. When I go through SAM-BA
it’s always perfect, making me think it’s not a chip problem.
reset
JTAG device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x002058c0
flash write_image main_flash.bin 0x00100000 bin
wrote 35108 byte from file main_flash.bin in 1465.177002s (0.023400 kb/s)
verify_image main_flash.bin 0x00100000 bin
checksum mismatch - attempting binary compare
Verify operation failed address 0x00106e88. Was 0xe9 instead of 0xeb
Trying jtag_khz settings of 100, 10, and 1 just take longer and longer to
give the same error. I’m running the board from an external supply and
the ARM-USB-OCD through a powered hub, but this doesn’t make a
difference. It often fails at 0x00106e88 or at 0x001074ab. It doesn’t
seem to matter if “arm7_9 dcc_downloads” is enabled or disabled.
Several different MC_FMR flash mode settings (wait states and master
clock cycles) were tried from examples I found on the web, all with the
same results. Using the clock and flash settings that SAM-BA uses also
gave same results. Increasing nsrst_delay and ntrst_delay made no
difference. If it verifies once, it verifies over and over again.
Now some other issues.
First, I can’t create Wiki account – server error. Where is the most up
to date documentation? The Wiki? The doc directory? Are these
synchronized?
Comments at the end of lines do not work in telnet, which makes
pasting pieces of .cfg files in difficult.
Paths and command line: It seems that ideally you’d run it to use
the configuration files supplied for your interface and target like this:
./openocd -f interface/olimex-arm-usb-ocd.cfg -f target/sam7x256.cfg
When I build it, the executable ends up in src directory. It seems it
should either end up in the top directory or end up in the src/target
directory where it can find the .cfg files in interface/ and target/
directories. (Why is there a target subdirectory of target?)
It should be able to find paths to interface and target directory, but both
are under an “extra” target directory compared to the YAGARTO install.
It would be nice to have robust configuration files for all interfaces and
targets that work “as is,” but maybe the intention is to have these be only
examples. Is the OpenOCD_scripts page on the Wiki duplicating
information in svn and therefore subject to becoming out of sync (as they
are)? Should this page just link to the relevant files in svn?
My old command-line from r717:
./openocd -f interface/olimex-arm-usb-ocd.cfg -f target/sam7x256.cfg -c init -c reset
This quits. If I leave off the “-c reset”, the program stays alive and I can
telnet to it. This is different than how r717 behaved. I’m not sure why it
should quit, especially since adding “-c reset” is suggested all over the
documentation.
Interface config files: arm-usb-ocd.cfg and olimex-arm-usb-ocd.cfg are
redundant, but different. In fact, the one starting with “olimex-” seems
like it should be the preferred one, but it doesn’t work. The difference is
in the ft2232_device_desc: “Olimex OpenOCD JTAG A” (which works) vs
“Olimex OpenOCD JTAG” (which doesn’t). Even without including
the " A" it still finds it (debug output below). Maybe if it only finds one
device, it should assume that’s the one you want to use.
…
Error: 63 109 ft2232.c:1419 ft2232_init_ftd2xx(): unable to open ftdi device: 2
Error: 64 109 ft2232.c:1434 ft2232_init_ftd2xx(): ListDevices: 1
Error: 65 109 ft2232.c:1436 ft2232_init_ftd2xx(): 0: Olimex OpenOCD JTAG A
…
I don’t own an olimex-jtag-tiny device, but its config includes no
“ft2232_vid_pid” line. The arm-usb-ocd config files don’t seem to need it
either (I assume you’re auto-detecting or something now.) If this is the
case, these lines should probably be removed to simplify all of the .cfg
files.
The .cfg files for the chips are also non-uniform. Some atmel parts have
file names that start with at91 and others just launch right into the sam7.
The readme.txt file says that a target/xxx.cfg file can invoke another
target/yyy.cfg file, but doesn’t describe how.
I’m not actually sure how it finds the sam7x256_reset.script file since I
didn’t include an absolute path anywhere and it had trouble finding other
things.
The sam7x and sam7s configurations are identical except for calling
different reset scripts. But the reset scripts are identical except for extra
spaces at the end of some lines (violating your style rules.)
When I start up and do a “flash info 0” I get an error. I think it’s because
the target needed to be halted:
Debug: 87 9360 command.c:79 script_command(): script_command - info
Debug: 88 9360 command.c:96 script_command(): script_command - info, argv[0]=ocd_flash_info
Debug: 89 9360 command.c:96 script_command(): script_command - info, argv[1]=0
Debug: 90 9360 command.c:404 run_command(): Command failed with error code -304
After I halt, it works. This code -304 is ERROR_TARGET_NOT_HALTED,
but other places it’s actually reported back in text.
The info it displays looks like it could use some work:
flash info 0
#0: at91sam7 at 0x00100000, size 0x00040000, buswidth 4, chipwidth 0
#0: 0x00000000 (0x40000 256kB) protection state unknown
at91sam7 information: Chip is AT91SAM7X256
cidr: 0x275b0940, arch: 0x0075, eproc: ARM7TDMI, version:0x000, flashsize: 0x00040000
master clock(estimated): 49696kHz
pagesize: 256, lockbits: 16 0x0000, pages in lock region: 64
securitybit: 0, nvmbits(3): 0x4
Does the second line indicate that the same flash is also mapped to
location 0x00000000? (It is, in fact, the case for me.) It says the
protection state is unknown, but below it correctly displays the lockbits
indicating that none of the 64 pages are protected. How is the master
clock estimated? (After an erase, it gets estimated as zero.) 256 byte
pagesize times 64 “pages in lock region” gives only 1/16 of the 0x40000
256kB flash size. num_pages is correct in at91sam7.c I think I’m
missing something:
What’s the difference between a bank, a sector, a plane, and a page?
When you do “flash banks” it doesn’t know about the location and size
until you do a “flash probe 0” This is not in the documentation.
“flash erase_check” doesn’t work – erase state unknown
“flash erase_sector 0 0 0” works
“flash erase_sector 0 0 1” returns mysterious
“failed erasing sectors 0 to 1 (-901)”
rather than “ERROR_FLASH_SECTOR_INVALID” which it corresponds to.
“flash protect_check 0” returns “successfully checked protect state”
but then “flash info 0” still says “protection state unknown”
“flash protect 0 0 0 off” for the sam7
When I manually set the lockbits by writing to the right memory address,
“flash erase_sector” returns an appropriate error, but “flash info 0” still
says they are not set. In fact, I need to “shutdown” and restart openocd
before “flash info” will report the correct lockbits. When does this
information get set? Why doesn’t get it rechecked when you do another
“flash info”?