I've got some thoughts on defining a crisper interface between the target_process_reset() and the target.
- the idea is to let the target be ignorant of reset modes. Reset modesrun, init, halt, run_and_init, etc. is something that is built on top of the target reset support. - a target is told to assert reset into the halted or into the running state. - a target may fail to reset a target into the halted state, in which case it is running. Why it fails to do so isn't important. - the target_process_reset() will detect that the target is running instead of halted and issue a halt if approperiate - since reset is now asynchronous, reduce usage of event callbacks and wait for halt + synchronous function calls more. This will make it clearer what happens when. - from a scripting api point of view, there will only be two types of reset that can be issued: reset run or reset halt. init scripts is built on top of the latter. from a scripting point of view there is no need to distinguish between a failed target reset+halt and reset+run&halt. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
