Spen wrote: >> Maybe so, I have not compared to the cortex code to get the >> full picture there, but the call to >> arm7_9_enable_breakpoints(target) in arm7_9_resume is >> necessary in debug_execution mode to enable the algorithm breakpoint. >> >> > > true for arm4_5 but not armv7. > I personally think the arm4_5 needs bringing upto the leval of the armv7 > > arm4_5 as such delays the breakpoints until a resume - not sure of why. > It is because on the armv7 we can communicate with the debug hardware while the target is running. In my opinion the strongest advantage of the armv7 architecture.
On the arm4_5 targets this communication is done by injecting arm32 code and data onto the processor bus, singlestepping the core and thus effectively running the code that modifies the debug hardware registrers on the target one instruction at a time without placing the code in memory. This cannot be done without halting the processor. A possibility is to do this halt/set breakpoint/resume sequence automatically but this has possible sideeffects for the running code, of course breakpoints will always have sideeffects. I am not yet sure what I would prefer, but i am leaning towards the armv7 way, when adding a breakpoint we set it up in hardware asap even if we have to halt and resume the target to do that, if this is possible. This is in contrast to Öyvinds preference that add_breakpoint should not touch the hardware. I would rather say that the meaning of add breakpoint is to touch the hardware as soon as possible. Regards Magnus _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
