Mike,
Yes, it turns out i was using an older version of OpenOCD, i just tried with
the latest version, and its working fine.
Thanks so much for your help.
Drasko,
i am sorry i can't be of more help with your issue, i hope you find a
solution soon.
- Nived
On Wed, Sep 15, 2010 at 11:56 AM, Drasko DRASKOVIC <
drasko.drasko...@gmail.com> wrote:
> On Wed, Sep 15, 2010 at 8:28 PM, Drasko DRASKOVIC
> <drasko.drasko...@gmail.com> wrote:
> > On Wed, Sep 15, 2010 at 7:58 PM, Mike Dunn <miked...@newsguy.com> wrote:
> >> On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote:
> >>
> >> I sent in a patch a while back to fix this very problem on the xscale;
> i.e.,
> >> software breakpoints didn't work because of cache issues. The problem
> was
> >> clear: execution failed to halt on software breakpoints most of the
> time. And
> >> always if set a few instructions ahead of the current value of the pc.
> Once the
> >> code to clean and flush the cache was added, the problem went away and I
> haven't
> >> seen any issues since, and I use sw breakpoints frequently.
> > Yes, not hitting breakpoint can make one suspect on caches, i.e.
> > breakpoint was put in RAM, but not replicated in cache.
> > Here we are facing different behavior : breakpoint is always hit, no
> > mater at which instruction it is put.
>
> OK, writing previous e-mail, one thing crossed my mind : I was (and
> probably NIved also) putting breakppoints before starting a program,
> which in my case is e-Cos application.
> As e-Cos will initialize caches during the boot, bkpt instruction
> placed by the GDB in RAM will be replicated to the cache. But I never
> before did try to start e-Cos, stop it via GDB and place a SW
> breakpoint. This way, if it is really a cache problem, bkpt
> instruction will be placed in memory, but not replicated in cache and
> thus never seen when we do 'c'. And that is exactly what happens in my
> case - program never stops after.
>
> So, this can prove two things :
> 1) Problem comes from cache inconsistency.
> 2) My routines for cache flushing :
>
> printf ("Invalidate I$\n");
> retval = arm966e_write_cp15(target, 0x0f, 0);
>
> printf ("Invalidate D$\n");
> retval = arm966e_write_cp15(target, 0x0e, 0);
>
> are not good.
>
> My question is here can anybody, based on ARM946E doc given here :
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.arm9/index.html
> can give me valid parameters to write into CP15 with
> arm966e_write_cp15() function in order to flush I$, because I can not
> see what is wrong with the lines I came up with...
>
>
> Nived,
> as Mike pointed out you probably took old code without cache-handling
> patch.
>
> Can you also try to run your program without any breakpoint set, than
> stop it with CTRL+C, and then set breakpoint to some instruction that
> is after the address at which you stopped (yet to come in program
> execution flow), and continue execution (by putting 'c' in GDB). If it
> is a cache problem it will never stop on this new breakpoint.
>
> Best regards,
> Drasko
> _______________________________________________
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
