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 pad patch) - now to find a
>> solution.
> 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 so that tap_length is divisible by 8 */
> while (tap_length % 8 != 0)
> {
> /* More of the last TMS value keeps us in the same state,
> * analogous to free-running JTAG interfaces. */
> jlink_tap_append_step(last_tms, 0);
> }
> byte_length = tap_length / 8;
>
> 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(): 0000 cf 00 08 00 ff 00
> and r1509
> Debug: 119 249 jlink.c:963 jlink_debug_buffer(): 0000 cf 00 07 00 7f 00
Well found, although it doesn't explain why it should work with >=r1509
after having previously worked with <=r1508.
Apologies for my misdirection about r1498. I saw large changes to the
testing code under svn blame, but they were merely refactoring, and
weren't substantive.
It also concerns me that padding with the last TMS is considered to be
universally OK. When you move to DR_SHIFT, there are side-effects
(starting to clock the value out!) if you introduce extra clocks.
Particularly with the XScale, it needs to be taken to DR_SHIFT via
pathmove(), and if anything introduces extra clocks after that, the data
will start to be clocked out.
I will try this change in isolation, and report back.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
