Answering some of your questions here. Please keep tabs on your problems
and keep sending patches/bringing them up one by one :-)
There was a lot of good feedback in this email, but of course with so
many things in a single posting, there is the danger(certainty actually)
that some things will drop on the floor...
>> 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
I'd say this was communication error. 0xe9 is *almost* the same as 0xeb.
You can try to download the entire flash and compare it to see if there
are sporadic flipped bits. I guess that would indicate communication problems
(physical connectors?)
How well does the SAM7 work without RTCK? I don't know.
> 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?
The wiki is dead, but we seem to be unable to delete it. openocd.texi
under subversion is the authorative documentation for OpenOCD. It is
of course in synchronisation with the subversion version of the code
which is the added bonus. Especially since OpenOCD sees a lot of
changes these days.
> Comments at the end of lines do not work in telnet, which makes
> pasting pieces of .cfg files in difficult.
OpenOCD uses TCL now, but I did add support for # comments
at the end of openocd commands a while back.
Which subversion version are you running?
If you add "; # comment" to the end of the line, then the ";" indicates
a new Tcl statement and the # is the Tcl comment char.
Should work.
> ----
>
> 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?)
You need to create the distributable directory:
Run "make install"
This is standard autconf behaviour.
> 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
the wiki is dead, but we don't know how to delete it. It's really annoying.
> 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?
We continously improve the target/interface scripts. What's in subversion
is whatever latest version that someone submitted.
Please send patches w/fixes to target/interface scripts and we'll apply them.
> -----
>
> 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.
Please post a seperate email w/error message(debug_level 3) here. "quits" is
not sufficient description to work from.
> 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.
Add "script target/xxx.cfg".
Type "help script" in the telnet session.
> 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.)
I've deleted the sam7s files from subversion.
>
> -----
>
> 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.
I've committed fixes for a bunch of these cases in trunk. Basically
the error message
must be logged at the point where the error is reported according to OpenOCD
programming rules.
{
LOG_ERROR("Target not halted");
return ERROR_TARGET_NOT_HALTED;
}
>
> ----
>
> The info it displays looks like it could use some work:
Patches gladly accepted. ;-)
>
> ----
>
> 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.
Please submit a patch to docs/openocd.texi
> "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.
Really OpenOCD is moving away from error codes both from a point of view
of explaing what's wrong and as a way to communicate between layers.
A LOG_ERROR() + return ERROR_FAIL is the preferred implementation.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
