One problem about jtag_add_end_state() is that it's effectively setting a global variable.
This makes it hard to tell, reading some code, what is expected to happen after a JTAG scan. Some other calling code invoked jtag_add_end_state() with some end state. Other than running the debugger, I don't know how to figure out what the end state is. Wouldn't it be better if the code had to pass in the end state as an argument to the scan operations? That way there would be some clue locally in the code as to what state the JTAG state machine moves to after a scan.... Is there a fundamental reason(other than that we need stability on svn head :-) why the following couldn't work: - remove jtag_add_endstate() - make it illegal to invoke jtag_add_x_scan() with TAP_INVALID as end state. The rollout plan would then be: - wait for a suitable time on svn head - make jtag_add_x_scan() w/TAP_INVALID deprecated. - switch over jtag_add_x_scan() on some reasonable schedule. Use numerous commits for bisecting purposes. - retire jtag_add_endstate() -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
