The new driver is working ok with the calls to tap_get_tms_path_len(start_state, goal_state);
If I use the old version of the new binary tms_seqs table with the new driver, I see the exact same behavior on my ARM9 board as with the ft2232.c in HEAD. If I use the new version of the binary tms_seqs table, I see less clock cycles being consumed and it is working at 99.9%. I think however the problem I am seeing with this combo is related to the new binary table and not this un-commited driver. new driver + old table = 100% OK new driver + new table = 99.9 % OK new table sends out less clocks. No timing information available yet, as to whether the reduced clock support was worth the trouble. But that will come. So I will use the new handy state transition logging to track down the differences in behavior and submit a final patch to ft2232.c sometime this week. This code adds: ** the reduced clock cycle support and ** the state transition logging and ** some asserts to trap buffer overruns. I have merged in the recent icebear patch. FYI, Dick _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
