Øyvind Harboe wrote: > On Tue, Sep 15, 2009 at 6:18 AM, michal smulski <[email protected]> > wrote: > >> I noticed that something was not right with my svn repo after doing >> various up-rev's and down-rev's and decided to start fresh. >> >> It turns out that last 'memwrite burst' working is actually rev 1824 and >> the failing one is rev 1825 and the offending change is somewhere in >> ft2232.c file (change r1814 -> r1825). >> >> I checked out two svn branches from fresh 'r1824' and 'r1825.' The first >> was still passes the memwrite test and the other one does not. It would >> explain why you cannot reproduce it on your jtag. >> >> Do you have access to ft* based JTAG hardware. Perhaps somebody else on >> this list can confirm this? >> >> Could you review the r1825 changes and point in the right direction to >> debug this problem? >> >> I attached a diffs (via svn diff and diff commands). >> > > First of all *great* find! > > But ouch.... This is going to be a tough one. Committing huge changes > like this in a single commit when it's possible to break it apart > is a faux pas, this being an excellent example of why. :-( > > Well, not really, some changes are major changes. This is, apart from some formatting changes, the "switch from long tms sequences to short tms sequences" ptch. It is not possible to switch only part of the ft2232.c to using the new tms sequence tables, and the support functions would never be called and tested if commited in an earlier patch.
So this seems to a "short tms sequence" issue. Does the same problems appear when switching to the short tms sequence in the jlink code. So anyone with a jlink and an arm1136 ? It is also possible to use the old, long, tms sequences by issuing the "tms_sequence long" command and check if this helps. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
