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
