On Wed, Sep 8, 2010 at 9:40 PM, Øyvind Harboe <oyvind.har...@zylin.com> wrote: >> 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. > > Uhhh... I'd have to dive into it, which I won't at this point, but consider > the icache. > > Perhaps the icache is stuck with a software breakpoint?
Hi Øyvind, to find a root cause of this repetitive I tried using arm920t target and thus profit the implemented cache handling. So, I cahanged my configuration file, replacing line : target create $_TARGETNAME arm966e -endian big -chain-position my.cpu -variant arm946e with : target create $_TARGETNAME arm920t -endian big -chain-position my.cpu -variant arm946e For me it does not matter a lot because I have to use ARM946 which has caches and MPU (not MMU, though). I can connect to my target, and do the usual things. However, hitting the same breakpoint remains! Like something is preventing single step from this point on, GDB is receiving constant SIGTRAP, same breakpoint trap with every step. Based on this, I would say that the I-cache is not a guilty party for this phenomenon and that something else is broken, preventing ARM946 to use SW breakpoints. Do you have some other ideas based on these new facts ? Thanks and best regards, Drasko _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
