UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor timholt1958
Visitor
146 Views
Registered: ‎04-20-2018

Possible Cortex-A9 instruction failure with STRB R4,[R1,#-1]! where the R1 register is not decremented after millions of runs and corrupted memory

Anybody seen something like this with a rare failure to post decrement a register in store byte on Zynq 7020 666Mhz run afer hours?

Memory corruption in mov R4, 0; add R1, SP, #16; STRB R4,[R1,#-1]! on Cortex-A9 with cache enabled, many interrupts EMAC, Timers after hours run. Not seeing in errata. R1 is not decremented and results corrupted stack data abort. Debugger not factor.

I do not see anything like this in the errata for the Cortex-A9. This is a Zynq Z7020 running 666Mhz with dual cores and both levels of cache running. The compiler is GCC but the fact that this runs for many hours with this code hit millions of times makes me worried. The value at R0 is the top of the local stack frame and the final byte is a byte placed on the stack with the address taken at say 0x12345F but since it is not decremented it points to a register value pushed onto the stack at 0x123460 and the method call then writes the byte data back to the stored register value at 0x1234560 and corrupts it causing a data abort. Nothing else is corrupted just that one byte.

0 Kudos
1 Reply
Visitor timholt1958
Visitor
115 Views
Registered: ‎04-20-2018

Re: Possible Cortex-A9 instruction failure with STRB R4,[R1,#-1]! where the R1 register is not decremented after millions of runs and corrupted memory

The second core is not active.  This occurs on many Zynq 7020 based boards after some hours.  It only started to occur in our codebase after a byte aligned variable was placed on the stack, zeroed and provided to a method that expected a 8bit aligned storage address to write into. The failure to post decrement the R1 register in this case occured on all targets after the code was changed with no other changes in optimization etc.

0 Kudos