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 is no RTCK singal on the TMS4
On Sun, May 31, 2009 at 3:25 AM, Peter Denison wrote:
> Many thanks! Somehow in my testing (probably to try to replicate XC's
> config) I had put jtag_rclk in my .cfg file.
>
> I've replaced it with jtag_khz 30, and I can at least initialise now. Sorry
> for the misdirection.
I am guilty here.
>
On Saturday 30 May 2009, Xiaofan Chen wrote:
> Do you know how to remove the warning?
> "Warn : DBGACK set while target was in unknown state. Reset or
> initialize target."
I consider that to be an initialization bug in the OpenOCD code.
One of several, actually ... sorting them all out will take
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 I send 8 bits:
>>>
>>> Debug: 192 667 jlin
On Sat, May 30, 2009 at 11:39 PM, 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 is no RTCK singal on the TMS470R1A256.
>
> For testing interface
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 I send 8 bits:
>>
>> Debug: 191 667 jlink.c:1032 jlink_usb_write(): jlink_usb_write, out_lengt
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 I send 8 bits:
>
> Debug: 191 667 jlink.c:1032 jlink_usb_write(): jlink_usb_write, out_length =
> 6, result = 6
> Debug: 1
On Sat, May 30, 2009 at 2:32 AM, Peter Denison wrote:
>> what jlink firmware version is this?
>> mine reports:
>> J-Link ARM V6 compiled Nov 5 2008 20:49:58
>
> J-Link ARM V6 compiled Mar 3 2008 18:04:42
>
> I don't think much of their revision control, to be honest. The
> capabilities of a lot
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:
>>
>
> > 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:
>
> Debug: 191 667 jlink.c:1032 jlink_usb_write
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
Hi
> a bit more debugging
> The issue seesms to be in the function jlink_tap_execute
>
> the change in r1509 that causes the issue is:
> // number of full bytes (plus one if some would be left over)
> byte_length = tap_length / 8 + !!(tap_length % 8);
>
> instead of r1508
>
> /* Pad last byte
> -Original Message-
> From: Magnus Lundin [mailto:lun...@mlu.mine.nu]
> Sent: 29 May 2009 16:42
> To: Spencer Oliver
> Cc: 'Dylan Reid'; openocd-development@lists.berlios.de
> Subject: Re: [Openocd-development] jlink issues
>
> Spencer Oliver wrot
Spencer Oliver wrote:
>>> svn head (currently r1943) fails when connecting using a
>>>
>> v6/v5.3 jlink
>>
>>> and
>>> stm32 target.
>>> Connecting using r1192 is ok, just a little slow.
>>>
>>> The strange thing is if i then connect using r1943 it will work !!
>>> Replug the jlink an
> > svn head (currently r1943) fails when connecting using a
> v6/v5.3 jlink
> > and
> > stm32 target.
> > Connecting using r1192 is ok, just a little slow.
> >
> > The strange thing is if i then connect using r1943 it will work !!
> > Replug the jlink and it will fail with r1943, run r1192
> th
> svn head (currently r1943) fails when connecting using a v6/v5.3 jlink and
> stm32 target.
> Connecting using r1192 is ok, just a little slow.
>
> 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.
>
Hi,
I have been running a few tests with regards to jlink support (win32)
svn head (currently r1943) fails when connecting using a v6/v5.3 jlink and
stm32 target.
Connecting using r1192 is ok, just a little slow.
The strange thing is if i then connect using r1943 it will work !!
Replug the jlink
18 matches
Mail list logo
