"FreeRTOS_DataAbortHandler" implementation in "CORTEX_A9_Zynq_ZC702 demo " project

peltier wrote on Tuesday, February 12, 2019:

Hello ,

I have some questions about the DataAbort Handler in the “CORTEX_A9_Zynq_ZC702” demo.

// from " FreeRTOS_asm_vectors.S ":
https://github.com/jameswalmsley/FreeRTOS/blob/master/FreeRTOS/Demo/CORTEX_A9_Zynq_ZC702/RTOSDemo/src/FreeRTOS_asm_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 asm_vectors.s" https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/standalone/src/arm/cortexa9/gcc/asm_vectors.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

rtel wrote on Tuesday, February 12, 2019:

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.

peltier wrote on Wednesday, February 13, 2019:

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.