Hello , I have some questions about the DataAbort Handler in the “CORTEXA9Zynq_ZC702″ demo. // from ” FreeRTOSasmvectors.S “: https://github.com/jameswalmsley/FreeRTOS/blob/master/FreeRTOS/Demo/CORTEXA9ZynqZC702/RTOSDemo/src/FreeRTOSasm_vectors.S FreeRTOS_DataAbortHandler: /* Data Abort handler */ stmdb sp!,{r0-r3,r12,lr} /* state save from compiled code */ blx DataAbortInterrupt /* DataAbortInterrupt :call C function here */ ldmia sp!,{r0-r3,r12,lr} /* state restore from compiled code */ subs pc, lr, #4 /* adjust return */ // from” Xilinx asmvectors.s” https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/standalone/src/arm/cortexa9/gcc/asmvectors.S DataAbortHandler: /* Data Abort handler / stmdb sp!,{r0-r3,r12,lr} / state save from compiled code / ldr r0, =DataAbortAddr sub r1, lr, #8 str r1, [r0] / Stores instruction causing data abort / bl DataAbortInterrupt / DataAbortInterrupt :call C function here / ldmia sp!,{r0-r3,r12,lr} / state restore from compiled code / subs pc, lr, #8 / points to the instruction that caused the Data Abort exception */ My questions are : 1/ Why have you used “blx” instruction rather than “bl” ?: “blx DataAbortInterrupt” ( blx changes the instruction set). 2/ Why have you modified the original handler that gives the possibility to know the instruction causing data abort: ( r0 is a parameter for Xilinx C function : DataAbortInterrupt ) https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/standalone/src/arm/common/xil_exception.c ) P.S: the same problem exists with PrefetchAbortHandler. Thanks by advance. Gilles Peltier

I’m going to guess these changes arise form updates Xilinx have made themselves since the FreeRTOS demo was created. I think the address of the aborting instruction can be obtained inside the handler – it doesn’t need to be passed in as a parameter although the parameter method is more user friendly. As I recall BLX uses the least significant bit of the branch address to determine if it continues in ARM or THUMB mode.

Thank you Richard for your quick answer. You said: “I’m going to guess these changes arise form updates Xilinx have made themselves since the FreeRTOS demo was created.” You are probably right. Same reason for the code line at the end of the ISR : subs pc, lr, #4 // FreeRTOS_DataAbortHandler It should be : subs pc, lr, #8 // correct in the original Xilinx DataAbortHandler.