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