On Fri, 6 Nov 2009, Tornado wrote:
> Im working with a router WRT320N with broadcom 4716 processor, mips32
> 74k core. I have no information to speak of on this board, I am used to
> an ir length of 5 or 8 for broadcom CPU's, Openocd complains about 5 or
> 8, with an error a bit 8. I have tried de
The current code for the USBprog adapter fails right after init when
trying to do the DRSCAN for IDCODEs with:
Info : 284 201 core.c:948 jtag_examine_chain_display(): JTAG tap: sam7x256.cpu
tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Warn : 285 201 core.c:986 jtag_examine_c
On Sat, 11 Jul 2009, Øyvind Harboe wrote:
There is one more thing that is unclear from what you have
reported.
Is this a problem with XScale or USBprog?
It's definitely a problem with USBprog.
What if your assumption false: USBprog could be working
just fine w/short sequences today
Gi
On Sat, 11 Jul 2009, Øyvind Harboe wrote:
On Sat, Jul 11, 2009 at 10:24 AM, Peter Denison wrote:
On Sat, 11 Jul 2009, Øyvind Harboe wrote:
If I could return to the original point of this thread - getting the USBprog
adapter to work at all - in the light of the other comments, are you going
to
On Sat, 11 Jul 2009, Øyvind Harboe wrote:
We need to move on with development and j-link is still being
discussed actively. 0.2 is likely to be cut in the next 24-48 hours.
We'll be releasing 0.3 soon after 0.2 anyway(a month or two), so
this shouldn't be so bad. There are a handful of other pr
On Fri, 10 Jul 2009, Øyvind Harboe wrote:
It's trivial in the sense that there's absolutely no way the adapter can
work with the short transition table,
Could you elaborate on this for those that read up on this thread later on?
The USBprog adapter expects 7-bit sequences to be sent as part
On Fri, 10 Jul 2009, Øyvind Harboe wrote:
This is not a trivial regression and I believe the XScale
target code needs to be fixed.
It's trivial in the sense that there's absolutely no way the adapter can
work with the short transition table, and some degree of getting it
working with the ori
I've recently had the opportunity to start testing the USBprog interface
again.
Since the introduction of the "short" tms transition table, the USBprog
interface has been broken. The attached patch fixes it in one way, but I
don't really like the fact that it can be undone from the command prom
On Sat, 4 Jul 2009, Ferdinand Postema wrote:
> I understand that you do not want to make any changes so close to the
> release of a new version. No problem.
>
> I made 3 changes in the table amt_jtagaccel_tap_move. This table defines
> how to move from one state to the other. It consists of two by
On Tue, 9 Jun 2009, Duane Ellis wrote:
> Could there be something we could put in the "configure script" - that
> tells CYGWIN - to behave?
> ie: Perhaps something like the SHELLOPTS thing?
>
> For example - maybe in the "bootstrap" script?
> And in the "CONFIGURE' script?
> And in the Makefiles?
On Tue, 2 Jun 2009, Spencer Oliver wrote:
> I have committed the attached patch to svn.
>
> - hack added to fix a issue with v5/6 jlink
> v5/6 jlink seems to have an issue if the first tap move is not divisible by
> 8, so we send a TLR on first power up
>
> Cheers
> Spen
Much better than my hack,
Some (all?) V6 firmware on the J-Link adapter fails to step the TAP unless
the first EMU_CMD_HW_JTAG3 command has 8 bits rather than 7, immediately
after adapter power-up. Add a hack to pad out to 8 bits, the first time
only.
Index: src/jtag/jlink.c
==
On Sat, 30 May 2009, Peter Denison wrote:
> On Sat, 30 May 2009, Magnus Lundin wrote:
>
>> It looks like you are using jtag_khz 0, this means adaptive clocking with
>> the RTCK signal. This work for LPC3148 that has a RTCK signal, but as far as
>> I can find there
The debugging code in jlink_tap_execute() called when _DEBUG_USB_COMMS_ is
defined was using the entire cached scan length to print the results
buffers, and not the correct length of each individual buffer.
Index: src/jtag/jlink.c
On Sat, 30 May 2009, Duane Ellis wrote:
> All,
> (especially david & zach, you seem to do this very well).
>
> Yes, this is some what "off-topic" for this list, but it is on topic
> because the list wants "small more reviewable patches". To that end, I'm
> looking for a better way to deal with pat
On Sat, 30 May 2009, Magnus Lundin wrote:
> Xiaofan Chen wrote:
>> On Sat, May 30, 2009 at 1:01 AM, Peter Denison
>> wrote:
>>
>>> Unfortunately not mine... I still get a 1 returned (instead of a zero) as
>>> the error code from EMU_CMD_HW_JTAG3, when
On Fri, 29 May 2009, Spencer Oliver wrote:
>>> Still it would be very good to know if this is the problem for (at
>>> least some of) the V6 adapters.
>>
>> Unfortunately not mine... I still get a 1 returned (instead
>> of a zero) as the error code from EMU_CMD_HW_JTAG3, when I
>> send 8 bits:
>>
>
On Fri, 29 May 2009, Magnus Lundin wrote:
>> I have attached logs of both rev, as you can see the line of interest for
>> r1508 is
>> Debug: 119 218 jlink.c:963 jlink_debug_buffer(): cf 00 08 00 ff 00
>> and r1509
>> Debug: 119 249 jlink.c:963 jlink_debug_buffer(): cf 00 07 00 7f 00
>>
>
On Fri, 29 May 2009, Spencer Oliver wrote:
>> Spencer Oliver wrote:
> The strange thing is if i then connect using r1943 it will work !!
> Replug the jlink and it will fail with r1943, run r1192
> then all is ok again.
>>>
>>> Tracing further in.
>>> For me the break is @ r1509 (tms pa
On Wed, 27 May 2009, Xiaofan Chen wrote:
> Thanks a lot for the help. I could not connect the TMS470R1A256 IAR
> Starter Kit properly to J-Link with the script. I have not used your patch
> yet as it seems more for the debugging part. I want to connect and then
> reset/halt first.
>
>
> mc...@ubun
On Wed, 27 May 2009, Xiaofan Chen wrote:
> On Wed, May 27, 2009 at 2:29 AM, Peter Denison wrote:
>> On Mon, 25 May 2009, Xiaofan Chen wrote:
>>> I do not think so. From the website, it does not
>>> even program AVR32 properly as of now.
>>
>> It does. The
On Mon, 25 May 2009, Xiaofan Chen wrote:
> 2009/5/25 SimonQian :
>> For supporting AVR32 debugging under IAR EWAVR32 and
>> AVR32Studio, you MUST emulate JTAGICE mkII.
>
> I see. Thanks.
USBprog does do full JTAGICEmkII emulation, I believe - I haven't tested
it myself doing debugging, but I thi
On Mon, 18 May 2009, Peter Denison wrote:
> On Mon, 18 May 2009, Peter Denison wrote:
>
>> Now, on to the actual crash. I will do more investigation, but for now,
>> here's the backtrace:
>>
>> Starting program: /src/.libs/lt-openocd -f
>> ../../../
On Mon, 18 May 2009, Peter Denison wrote:
> Now, on to the actual crash. I will do more investigation, but for now,
> here's the backtrace:
>
> Starting program: /src/.libs/lt-openocd -f
> ../../../openocd-usr8200-jlink.cfg
> Open On-Chip Debugger 0.2.0-in-development
On Mon, 18 May 2009, Øyvind Harboe wrote:
Try using
libtool gdb ../openocd
or the more pedantic (but future-proof):
libtool --mode=execute gdb ../openocd
Once a solution has been identified, it would be nice to have the BUGS
file updated...
Excellent! That (to be precise the
On Mon, 18 May 2009, Øyvind Harboe wrote:
$ gdb ../openocd --args openocd
... ends up running /usr/bin/openocd ...
Try
gdb --args openocd -f interface/xxx.cfg -f target/.cfg ...
This runs the one (r1409) in /usr/bin, not my newly compiled one.
If I find the actual executable, which I
On Mon, 18 May 2009, Øyvind Harboe wrote:
[Oops - failed to copy the original to the list...]
On Mon, May 18, 2009 at 8:21 AM, Peter Denison wrote:
On Sat, 16 May 2009, Øyvind Harboe wrote:
Could you post a GDB backtrace?
See:
http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
I
On Sat, 9 May 2009, Øyvind Harboe wrote:
Please report any problems you are experiencing with svn head.
Except for the performance regressions, which will be addressed
next week, there are no reported problems at this point w.r.t.
the JTAG API changes.
Every *other* time I run, I get this...
On Fri, 13 Mar 2009, Rick Altherr wrote:
> On Mar 13, 2009, at 2:47 PM, Peter Denison wrote:
>> There are also adapters (at least one - USBprog) that rely on the fact that
>> there are exactly 7 state transitions in every tms sequence. This is not
>> immutable, but it will
On Fri, 13 Mar 2009, Jeff Williams wrote:
El Mar 13, 2009, a las 04:30 , Duane Ellis escribió:
2) jtag/jtag.h. changing state numbers concerns me - but i see
*exactly* why you are doing this.
Perhaps this sort of stuff would have helped earlier with the beagle
board work.
And it looks lik
The XScale target uses JTAG_PATHMOVE to get the TAP to the DRSHIFT state.
This patch fixes subsequent scans on the USBprog and J-Link adapters, so
that they don't try to make another transition (7 clocks) to DRSHIFT.
It also fixes the USBprog adapter to flush any pending TAP moves before
doing
On Sun, 8 Mar 2009, Dirk Behme wrote:
> The main issue I see which needs to be addressed before is the "do
> always 7 clocks from one TAP state to an other" OpenOCD uses at the moment
>
> https://lists.berlios.de/pipermail/openocd-development/2009-February/004625.html
Please be aware that if you
On Sat, 7 Mar 2009, Peter Denison wrote:
> This write to DCSR should then let the target run (the debug code just
> loaded into the cache), and then the next read is from TX, which the
> debug handler should have written to. However, the 3 guard bits in
> fields[0].in_value[3] shou
On Sat, 7 Mar 2009, Duane Ellis wrote:
> Peter Denison wrote:
>> The symptoms are that the adapter will initialise OK, but toward the end of
>> a 'reset halt', after the 2030 TCK cycles, and after loading the Mini
>> I-cache, the DCSR write is OK, but the fir
Still trying to get my IXP422 target board working...
I have compared the debug output (with -d3 and _DEBUG_JTAG_IO_ enabled) of
someone else's Olimex JTAG-Tiny, which does work, with the output from
both an IAR J-Link adapter and the USBprog adapter, which don't work. The
target boards were id
operations? I'm a
little reticent about just putting in a change and trying it without some
feedback, in case I damage my target. My proposed change would be raising
TCK at the end of usbprog_runtest(), so the next L-H transition of TCK
inside the tms-chain function in the firmware has the
36 matches
Mail list logo
