This turned out to be a red herring:
https://lists.berlios.de/pipermail/openocd-development/2009-September/010692.html
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openoc
On Saturday 19 September 2009, David Brownell wrote:
> However that is not the cause of the new reset problems
> I'm seeing on an arm926. Still chasing those down.
Seems like it was just a JTAG clock rate issue ... now
that I'm trying to use OpenOCD to debug some bootloader
code, such issues beco
On Saturday 19 September 2009, Øyvind Harboe wrote:
>
> Another thing to try is to see if the recent change to
> ft2232 jtag_add_pathmove() broke your target...
I did a code review of that and it looks "obviously
correct" ... so I did some style cleanups, which are
now checked in. ;)
However th
Another thing to try is to see if the recent change to
ft2232 jtag_add_pathmove() broke your target...
Did 2722 break your target?
I.e. does 2721 work?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openo
Thanks for following up on this and some excellent
detective work.
Another clue is that 2047 has a quaint definition of
ARM11_TAP_DEFAULT.
#define ARM11_TAP_DEFAULT jtag_add_end_state(TAP_INVALID)
I have *no idea* what would happen if you tried your patch + the 2047
AR
Øyvind Harboe wrote:
arm11 code is broken in 2046->2047 ref:
https://lists.berlios.de/pipermail/openocd-development/2009-September/010644.html
I've looked at this and it is a pretty hellish problem to
figure out from a code inspection point of view.
Agreed; I went the route of instrumenting
arm11 code is broken in 2046->2047 ref:
https://lists.berlios.de/pipermail/openocd-development/2009-September/010644.html
I've looked at this and it is a pretty hellish problem to
figure out from a code inspection point of view.
Anyone taking the time to look at 2046 in detail will conclude
that
