> Most of the time - in the jtag dongle - RTCK is implemented via software
> polling, and it ends up being slower. Adding a "timeout" in software (ie: in
> case the cable is not connected, or target is powered off) makes the
> software poll loop even slower. But - the vendor will not state that, or
Hello,
> I'm not familiar with the calc_checksum option. Sounds strange to have
> that built into the driver.
I agree on this, but let's just leave the feature there - for users convenience.
However, the preferred method shall be to externally calculate the checksum and
embed it into the image.
On Wed, Aug 27, 2008 at 3:50 AM, Martin Thomas <[EMAIL PROTECTED]> wrote:
> Hallo,
>
> I have just played a little bit with a LPC2378 on an Olimex LPC-2378-STK
> board using OpenOCD from SVN 971 (built with mingw/msys, running on
> WinXP with JTAGkey). The calc_checksum option is given in the flash
Hallo,
I have just played a little bit with a LPC2378 on an Olimex LPC-2378-STK
board using OpenOCD from SVN 971 (built with mingw/msys, running on
WinXP with JTAGkey). The calc_checksum option is given in the flash bank
definition and 'flash write_image erase project.elf elf' is used to
flash the
somebody >> STR912 now uses RCLK if available.
somebody>> Could i ask why? Because using rclk is slower.
somebody>> Is it?
somebody>> it has been on all the interfaces i have tested over the years.
somebody>> Even arm and segger mention this in their docs, if you have a
fast jtag tool
somebody
On Tue, Aug 26, 2008 at 8:23 PM, Spen <[EMAIL PROTECTED]> wrote:
>> >>
>> >> STR912 now uses RCLK if available.
>> >>
>> >
>> > Could i ask why? Because using rclk is slower.
>>
>> Is it?
>
> it has been on all the interfaces i have tested over the years.
>
> Even arm and segger mention this in the
On Tue, Aug 26, 2008 at 8:12 PM, Spen <[EMAIL PROTECTED]> wrote:
>> > I am struggling to see what gain this patch has brought
>> (unless i have
>> > missed something) - you are still calculating the checksum.
>> > you have just moved inline code to a inline function !!
>>
>> -O3 will remove the cal
> >>
> >> STR912 now uses RCLK if available.
> >>
> >
> > Could i ask why? Because using rclk is slower.
>
> Is it?
it has been on all the interfaces i have tested over the years.
Even arm and segger mention this in their docs, if you have a fast jtag tool
in theory it should be as close to the
> > I am struggling to see what gain this patch has brought
> (unless i have
> > missed something) - you are still calculating the checksum.
> > you have just moved inline code to a inline function !!
>
> -O3 will remove the calculation because the result of that
> calculation is not used.
>
On Tue, Aug 26, 2008 at 5:30 PM, Spen <[EMAIL PROTECTED]> wrote:
>>
>> Committed.
>>
>>
>
> I am struggling to see what gain this patch has brought (unless i have
> missed something) - you are still calculating the checksum.
> you have just moved inline code to a inline function !!
-O3 will remove
>
> Committed.
>
>
I am struggling to see what gain this patch has brought (unless i have
missed something) - you are still calculating the checksum.
you have just moved inline code to a inline function !!
Cheers
Spen
___
Openocd-development mailing
> $ gdb RTOSDemo.elf
> (gdb) load
> Loading section .text, size 0x3214 lma 0x0
> Loading section .rodata, size 0xe lma 0x3214
> Loading section .data, size 0x4 lma 0x3224
> Start address 0x0, load size 12838
> Remote connection closed
> (gdb)
>
> Then I tried various ways to make a reset (reset bu
I need crisper descriptions to take action...
There are a lot of factors involved here...
That's always the case for embedded work when getting things up and
running I guess.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
On Tue, Aug 26, 2008 at 12:21 PM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 26, 2008 at 12:09 PM, Valentin Longchamp
> <[EMAIL PROTECTED]> wrote:
>> On Tuesday 26 August 2008 08.34:16 you wrote:
>>> On Mon, Aug 25, 2008 at 11:00 PM, Valentin Longchamp
>>>
>>> I have noticed that the iM
Øyvind Harboe wrote:
> type "help reset"
>
Yes but that doesn't say what the parameters do.
> openocd.texi under subversion control. It is in sync w/source of course :-)
>
> to build a PDF file:
>
> make pdf
>
accessing the installed openocd.info is fine for me. (Although I got the
impres
--- On Tue, 8/26/08, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
> From: Øyvind Harboe <[EMAIL PROTECTED]>
> Subject: Re: [Openocd-development] ARM11 status
> To: "Valentin Longchamp" <[EMAIL PROTECTED]>
> Cc: "Openocd-Dev"
> Date: Tuesday, August 26, 2008, 9:09 AM
> On Tue, Aug 26, 2008 at 1:55 PM
On Tue, Aug 26, 2008 at 2:24 PM, Christian Jaeger
<[EMAIL PROTECTED]> wrote:
> Øyvind Harboe wrote:
>>>
>>> target state: halted
>>> target halted in ARM state due to debug-request, current mode: Supervisor
>>> cpsr: 0x00d3 pc: 0x
>>>
flash protect 0 0 2 off
>>>
>>> memor
Øyvind Harboe wrote:
>> target state: halted
>> target halted in ARM state due to debug-request, current mode: Supervisor
>> cpsr: 0x00d3 pc: 0x
>>
>>> flash protect 0 0 2 off
>>>
>> memory read caused data abort (address: 0x0001, size: 0x1, count: 0x1)
>> memory read ca
On Tue, Aug 26, 2008 at 1:55 PM, Valentin Longchamp
<[EMAIL PROTECTED]> wrote:
> On Tuesday 26 August 2008 12.21:35 Øyvind Harboe wrote:
>> On Tue, Aug 26, 2008 at 12:09 PM, Valentin Longchamp
>> > OK. I have noticed working with RealView ICE that mx31ads board JTAG
>> > chain is not optimal. Do yo
> target state: halted
> target halted in ARM state due to debug-request, current mode: Supervisor
> cpsr: 0x00d3 pc: 0x
>> flash protect 0 0 2 off
> memory read caused data abort (address: 0x0001, size: 0x1, count: 0x1)
> memory read caused data abort (address: 0x0002, size: 0x
PS. here's my openocd.cfg, just to make sure we know what we're talking
about:
telnet_port 5
gdb_port 50001
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG TINY"
ft2232_layout olimex-jtag
ft2232_vid_pid 0x15ba 0x0004
source /home/chrisarm/src/openocd-svngit--trunk/src/target/target/s
On Tuesday 26 August 2008 12.21:35 Øyvind Harboe wrote:
> On Tue, Aug 26, 2008 at 12:09 PM, Valentin Longchamp
> > OK. I have noticed working with RealView ICE that mx31ads board JTAG
> > chain is not optimal. Do you work with an ADS board Øyvind ? I will try
> > on our board, but I only have one a
Christian Jaeger wrote:
Øyvind Harboe wrote:
Try the attached patch.
It should cause an error rather than running into an infinite loop.
Hm, somehow today I'm only getting the "target not halted" and
subsequent "Target not examined yet" error when issuing "halt",
Ok I guess I should iss
Ooopss... fixed. Thanks!
On Tue, Aug 26, 2008 at 1:36 PM, Christian Jaeger
<[EMAIL PROTECTED]> wrote:
> Øyvind Harboe wrote:
>>
>> Committed.
>>
>
> Did you see my patch of your patch?
>
> SVN version 970 is giving:
>
> /home/chrisarm/src/openocd-svngit--trunk/src/flash/str9x.c: In function
> 'st
Øyvind Harboe wrote:
> Committed.
>
Did you see my patch of your patch?
SVN version 970 is giving:
/home/chrisarm/src/openocd-svngit--trunk/src/flash/str9x.c: In function
‘str9x_write’:
/home/chrisarm/src/openocd-svngit--trunk/src/flash/str9x.c:630: error:
redeclaration of ‘i’ with no linka
Committed.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-develop
Committed.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-developm
It looks like the driver or hardware is busted...
Have you tried a different JTAG debugger?
Too high clockrate?
Checked cables?
Tried a different target?
I'll need a sharper bug report to pursue this(otherwise it will take
too much time).
Info:122 284 jtag.c:1410 jtag_examine_chain():
On Tue, Aug 26, 2008 at 12:09 PM, Valentin Longchamp
<[EMAIL PROTECTED]> wrote:
> On Tuesday 26 August 2008 08.34:16 you wrote:
>> On Mon, Aug 25, 2008 at 11:00 PM, Valentin Longchamp
>>
>> <[EMAIL PROTECTED]> wrote:
>> >
>> > Here is what I get when I issue the reset halt command through telnet:
>
On Tuesday 26 August 2008 08.34:16 you wrote:
> On Mon, Aug 25, 2008 at 11:00 PM, Valentin Longchamp
>
> <[EMAIL PROTECTED]> wrote:
> >
> > Here is what I get when I issue the reset halt command through telnet:
> >
> > [EMAIL PROTECTED]:~/openocd/trunk/src$ ./openocd -f
> > target/target/mx31.cfg -
Øyvind Harboe wrote:
Try the attached patch.
It should cause an error rather than running into an infinite loop.
Hm, somehow today I'm only getting the "target not halted" and
subsequent "Target not examined yet" error when issuing "halt", even
with yesterday's code. I'd think the order i
On Tue, Aug 26, 2008 at 10:30 AM, Spen <[EMAIL PROTECTED]> wrote:
>>
>> Committed
>>
>> STR912 now uses RCLK if available.
>>
>
> Could i ask why? Because using rclk is slower.
Is it?
On the LPC2148 communication fails *just* above RCLK frequency.
Also, it is possible to redefine jtag_rclk (tcl
>
> Committed
>
> STR912 now uses RCLK if available.
>
Could i ask why? Because using rclk is slower.
Certainly for the odd case where you are using a slow clock (32kHz) it is
better, but that's about it.
What about all the other -S cores, do they default to using RCLK if
available?
Cheers
Sp
Øyvind Harboe wrote:
> Has anyone done any XScale testing lately?
I use IXP42x from time to time, although I don't pull svn updates very often -
the last version I used at work was svn:900.
cu
Michael
___
Openocd-development mailing list
Openocd-develo
34 matches
Mail list logo
