Hi all,
I have a rather interesting problem with a PPC440EPx-based system. I've localized the problem down to a single instruction in a function prologue that stores the return address to the stack:
stw r0,0x44(r1)
(lr is written to r0 earlier in the prologue.)
This code is in a normal device driver and is not being executed at interrupt level or in some TLB miss handler or anything arcane - it's just regular code (execution-context-wise).
It appears that if I just let the code run the write never makes it to the stack, thus setting the stage for very interesting function returns. Whatever value happened to be on the stack becomes the IP with the accompanying "excitement" that follows. If I single-step through the instruction using a JTAG debugger the write to the stack always occurs and the function does its work and returns correctly.
If I step right up to the stw, write a test value into 0x44(r1), then allow the processor to free run I am rewarded with an attempted return address equal to the test value I wrote to the stack - the stw memory write never makes it to the stack.
Because the code is compiled from C I'm limited in where I can sprinkle sync instructions but I've tried adding asm("sync") as close as possible to before (and after) the offending write - all to no effect. I'm at a loss to explain this as the remainder of the system seems to be running just fine but I get this particular behavior at will. More like its will than mine... :-{
Has anyone seen this kind of behavior with a PPC440 core? Please note that workarounds for all known CPU core errata for the PPC440EPx are already in place (based on the AMCC errata document).
Thanks very much, Dave