On 04/28/2011 05:49 PM, Eric Cooper wrote: > On Wed, Apr 27, 2011 at 05:33:50PM -0700, Mike Dunn wrote: >> On 04/27/2011 03:12 PM, Eric Cooper wrote: >>> I think it must still be executing the unmodified instruction out of >>> the i-cache. Shouldn't openocd flush that when it sets a software >>> breakpoint? >> Yes, 'should' being the operative word. If you're sure that the execution >> path >> passes through this instruction, then yes, icache not being flushed is the >> likely explanation. I had to fix the same problem on xscale a while back. >> Not >> sure of the status on arm7_9. Again, maybe someone knowledgeable can chime >> in. > I've made a little progress on this. The Feroceon chip also has an L2 > cache. I added some code to invalidate this when setting breakpoints, > and now the target at least halts at the right place.
Awesome! > But openocd > doesn't notice it (I had to use poll to find out that it's halted), > and doesn't restore the original instruction when resuming. > Hmmm. I thought polling is done periodically while the the processor is executing. At least that's how I remember it for xscale. I see that there's a 'poll' command to enable/disable this, but I never had to mess with it. Maybe on this arch it's off by default for some reason? Sounds like support for this arch might be a bit rough around the edges. I'm sure that patches would be gratefully received :-) Being able to set breakpoints is kinda fundamental, and would be a huge contribution. Mike _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
