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 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
>
Yes, it definetly seems some JLinks dislikes 7 bit transactions, but not
always, not if they are in a good mode after running rev 1188.
We can patch all transactions to be a multiple of 8, but that has a
tendency of driving some arm7/9 targets into a strange state if the
endstate is IDLE, since this is the clock instruction into cpu. For
Cortex targets this is not a problem.
Still it would be very good to know if this is the problem for (at least
some of) the V6 adapters.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
