On Wed, Sep 8, 2010 at 9:13 PM, Øyvind Harboe <oyvind.har...@zylin.com> wrote: >> Øyvind, >> if I understood you correctly, currently we do not have support for >> arm966 for SW breakpoints (i.e. we will run into problem of repetitive >> breakpoint hit as I mentioned), i.e. this support can be added and >> should be similar to arm920t_write_memory(), but currently does not >> exist with arm966 ? > > Correct. I think most of the "hard" problems have been solved, > now there is a bit of tedium reorganizing and generalizing the code... > Which requires less knowledge about specific target architectures, > but is still quite a bit of work and tricky enough.
Øyvind, Thank you very much for these answers. I took a look at code and I can see that arm966e.c code uses : .write_memory = arm7_9_write_memory which writes only in physical memory, while arm920t.c uses : .write_memory = arm920t_write_memory which in addition handles the caches (by draining/flushing them). I still have one confusion, though. I can understand that breakpoint rests in cache and that it can not be deleted and will be hit upon next passage. But why it prevents me stepping on ? Any "n", "s" or "c" ends in hitting the same breakpoint immediately. Same with augmenting pc reg for 1 and continuing. This problem resemble one described here : http://forum.sparkfun.com/viewtopic.php?f=18&t=22578 but the solution with patching arm7_9->has_single_step does not work for me - still the same breakpoint is hit. Do you have any idea if this is due some other problem, or still to the "cache issue" mentioned before ? BR, Drasko _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
