Greetings,
I've been using OpenOCD for a few years now. I've had great success
using it with the STM32 family of processors. I've just moved to a
new platform with the AT91SAM9G20 processor from Atmel.
I'm having a bit of trouble using the new processor in combination
with the Amontec JTAGKey.
You could use "catch {halt 0}" or modify handle_wait_halt_command to
be a silent no-op when ms=0
if poll has side effects that you want to avoid.
--
Øyvind Harboe
PayBack incident management system
Reduce costs and increase quality, free Starter Edition
http://www.payback.no/index_en.html
___
On Sun, 1 Mar 2009, Øyvind Harboe wrote:
> Please verify that all patches were committed correctly.
Yes, thanks.
Now I have another problem with the current code when it comes to reset
and halt. There used to be a time when the halt command didn't imply
wait_halt. now wait_halt is unconditio
On Mar 2, 2009, at 4:48 PM, Duane Ellis wrote:
Rick >> I like the patch already presented. rick >> ... Windows be
represented as "win32".
And then "win64" - and
Hence, WinXX .
It gets messy :-(
-duane
Win32 tends to correspond to the API, not the actual OS running.
People sti
Rick >> I like the patch already presented.
rick >> ... Windows be represented as "win32".
And then "win64" - and
Hence, WinXX .
It gets messy :-(
-duane
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.b
holger> Still this patch exports the OS to tcl. It does by itself
You have a good point.
I suspect this patch will be "useful for other purposes moving forward".
Meanwhile, a simple fix in the ftd2332.c file should be done also.
-Duane.
___
Openocd-d
> Rick Altherr> Can we fix this once and for all?
> [snip]
> Rick Altherr> ... a global variable in the TCL [snip]
> similar to __LINUX__, __WIN32__, __DARWIN__
>
> Oyvind> I don't particularly like the idea of opening up for
> communication between the OS and Tcl.
>
looks good except for b
On Mar 2, 2009, at 1:03 PM, Øyvind Harboe wrote:
The whole OMAP problem, AFICT, boils down to that "someone" has to
set aside the time to get this sorted. I believe by rewriting
ocd_process_reset
and a couple of patches it would be done. The piecemeal crisp
questions
& incremental patches
The whole OMAP problem, AFICT, boils down to that "someone" has to
set aside the time to get this sorted. I believe by rewriting ocd_process_reset
and a couple of patches it would be done. The piecemeal crisp questions
& incremental patches in the mailing list seems to be making some very
slooow pr
Øyvind Harboe wrote:
Ok. Maybe I missed something: Is it possible to use TCL commands like
'run_test' *before* jtag_init_inner() is executed? I'm not sure about
in what order what (commands in scripts vs. initialization functions
in jtag.c) is executed, yet ;)
Your target configuration script c
Øyvind Harboe wrote:
> Note that these are LENGTHY discussions and since there are several
> capable people involved, I'm kinda waiting for the dust to settle.
Where do you see the dust? At least regarding OMAP3 we now know how do
initialize ICEPICK [1] [2] (see below). For me, the dust is now ho
> Ok. Maybe I missed something: Is it possible to use TCL commands like
> 'run_test' *before* jtag_init_inner() is executed? I'm not sure about
> in what order what (commands in scripts vs. initialization functions
> in jtag.c) is executed, yet ;)
Your target configuration script can copy and past
Rick Altherr wrote:
>
> On Mar 1, 2009, at 12:08 AM, Dirk Behme wrote:
>
>>
Additionally, short status update from me:
>> ...
And, I wonder why the new version needs ~6 initial TAP_RESET moves
as marked with OMAP3_HACK in patch in attachment. Else, the ID code
won't be detec
Kees Jongenburger wrote:
> Hi
>
> I am trying to execute a simple ir/dr scan on the beagle(trying to
> read the ID code). but this doesn't work
> what am I doing wrong?
>
> ke...@ijssijs:~/repo/projects/beagle/openocd$ openocd_client
> Trying 127.0.0.1...
> Connected to localhost.
> Escape charac
Should a target_read/write_buffer() be a silent no-op or generate an explicit
error?
I have reason to believe 0 sized elf sections can occur...
Index: C:/workspace/openocd/src/target/target.c
===
--- C:/workspace/openocd/src/target/
On Mar 2, 2009, at 6:12 AM, Holger Schurig wrote:
I think the attached patch is OK, because it is a variable
that can take on some carefully defined values. Documentation
should go with this variable as well...
Still this patch exports the OS to tcl. It does by itself
nothing. You still have
> I think the attached patch is OK, because it is a variable
> that can take on some carefully defined values. Documentation
> should go with this variable as well...
Still this patch exports the OS to tcl. It does by itself
nothing. You still have to change all the interface tcl scripts.
In my
Duane Ellis wrote:
> Rick Altherr> Can we fix this once and for all? [snip]
> Rick Altherr> ... a global variable in the TCL [snip] similar to
> __LINUX__, __WIN32__, __DARWIN__
>
> Oyvind> I don't particularly like the idea of opening up for
> communication between the OS and Tcl.
>
> The atta
Dirk Behme> In [1] Rick proposed
Dirk Behme> "... that the C function for the irscan and drscan
Dirk Behme> commands needs to look for another argument
Dirk Behme> (namely the end state) and add a call to
Dirk Behme> jtag_set_end_state. This might also be
Dirk Behme> handled already with a 'end_s
On Mon, Mar 2, 2009 at 2:55 PM, Duane Ellis wrote:
> Rick Altherr> Can we fix this once and for all? [snip]
> Rick Altherr> ... a global variable in the TCL [snip] similar to __LINUX__,
> __WIN32__, __DARWIN__
>
> Oyvind> I don't particularly like the idea of opening up for communication
> betwe
Rick Altherr> Can we fix this once and for all?
[snip]
Rick Altherr> ... a global variable in the TCL [snip] similar to
__LINUX__, __WIN32__, __DARWIN__
Oyvind> I don't particularly like the idea of opening up for
communication between the OS and Tcl.
The attached patch is really all that
Hi, all!
Since I'm really interested in support for pxa270 in OpenOCD for my
OpenSurce - related projects,
I'd like to know what could I do for a project. I'm pretty good with C
and hopefully have enough
of knowledge about various ARM/PXA devices, I have very little
knowledge about JTAG/EICE.
But
Hi
I am trying to execute a simple ir/dr scan on the beagle(trying to
read the ID code). but this doesn't work
what am I doing wrong?
ke...@ijssijs:~/repo/projects/beagle/openocd$ openocd_client
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> scan_cha
Hi
On Mon, Mar 2, 2009 at 9:18 AM, Holger Schurig
wrote:
> On Sunday 01 March 2009 23:58:35 Rick Altherr wrote:
>> Ugh. Can we fix this once and for all? Win32 adds the A,
>> Linux and OS X do not.
For this specific problem perhaps we should simply rely on the
product/vendor name like
we do fo
On Sunday 01 March 2009 23:58:35 Rick Altherr wrote:
> Ugh. Can we fix this once and for all? Win32 adds the A,
> Linux and OS X do not.
If this is general, why let TCL handle this?
src/jtag/ft2232.c could contain code near
if (ft2232_device_desc)
{
openex_strin
I don't have a strong opinion about this, but I'm not sure how you would
make this work robustly.
Perhaps add a "configure" option with OS name that is visible in a
variable?
Perhaps a cfg file for each OS that is loaded before other config files?
linux.cfg could "set os linux", win32.cfg "set o
26 matches
Mail list logo
