How to understand why an ARM exception happens?

I'm trying understand what is the reason of ARM exception that I encounter. It happens randomly during system startup, and may looks in few different ways.

One of simplest is following:

0x8004e810 in ti_sysbios_family_arm_a8_intcps_Hwi_vectors ()
#0  0x8004e810 in ti_sysbios_family_arm_a8_intcps_Hwi_vectors ()
#1  0x80002f04 in ti_sysbios_family_arm_exc_Exception_excHandlerDataAsm(int0_t) ()
at /home/rnd_share/sysbios/bios_6_51_00_15/packages/ti/sysbios/family/arm/exc/Exception_asm_gnu.asm:103
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

r0             0x20000197   536871319
r1             0x20000197   536871319
r2             0x20000197   536871319
r3             0x20000197   536871319
r4             0x20000197   536871319
r5             0x6  6
r6             0x80000024   2147483684
r7             0x80007a0c   2147514892
r8             0x8004f0a8   2147807400
r9             0x80041340   2147750720
r10            0x80040a3c   2147748412
r11            0xffffffff   4294967295
r12            0x20000197   536871319
sp             0x7fffff88   0x7fffff88
lr             0x80002f04   2147495684
pc             0x8004e810   0x8004e810     <ti_sysbios_family_arm_a8_intcps_Hwi_vectors+16>
cpsr           0x20000197   536871319
PC = 8004E810, CPSR = 20000197 (ABORT mode, ARM IRQ dis.)
R0 = 20000197, R1 = 20000197, R2 = 20000197, R3 = 20000197
R4 = 20000197, R5 = 00000006, R6 = 80000024, R7 = 80007A0C
USR: R8 =8004F0A8, R9 =80041340, R10=80040A3C, R11 =FFFFFFFF, R12 =20000197
 R13=80212590, R14=80040A3C
FIQ: R8 =AEE1D6FA, R9 =C07BA930, R10=1B0B137A, R11 =7EC3F1DF, R12 =2000019F
 R13=80065CF8, R14=00000000, SPSR=00000000
SVC: R13=4030CB20, R14=00022071, SPSR=00000000
ABT: R13=7FFFFF88, R14=80002F04, SPSR=20000197
IRQ: R13=F4ADFD8A, R14=80041020, SPSR=8000011F
UND: R13=80085CF8, R14=ED0F7EF1, SPSR=00000000
(gdb) frame 
#0  0x8004e810 in ti_sysbios_family_arm_a8_intcps_Hwi_vectors ()
(gdb) frame 1
#1  0x80002f04 in ti_sysbios_family_arm_exc_Exception_excHandlerDataAsm(int0_t) ()
at /home/rnd_share/sysbios/bios_6_51_00_15/packages/ti/sysbios/family/arm/exc/Exception_asm_gnu.asm:103
103         mrc     p15, #0, r12, c5, c0, #0 @ read DFSR into r12
(gdb) list
98          .func ti_sysbios_family_arm_exc_Exception_excHandlerDataAsm__I
99  
100 ti_sysbios_family_arm_exc_Exception_excHandlerDataAsm__I:
101         stmfd   sp!, {r0-r12}   @ save r4-r12 while we're at it
102 
103         mrc     p15, #0, r12, c5, c0, #0 @ read DFSR into r12
104         stmfd   sp!, {r12}      @ save DFSR
105         mrc     p15, #0, r12, c5, c0, #1 @ read IFSR into r12
106         stmfd   sp!, {r12}      @ save DFSR
107         mrc     p15, #0, r12, c6, c0, #0 @ read DFAR into r12
(gdb) monitor cp15 6 0 0 0 
Reading CP15 register (6,0,0,0 = 0x7FFFFF54)

My understanding is that, there was some ongoing exception, which can be seen in frame 1. It tries to save registers onto stack:

101 stmfd sp!, {r0-r12} @ save r4-r12 while we're at it

But, stack pointer was incorrect at:

ABT: R13=7FFFFF88

I don't understand both:

1. What can be a cause of such value of SP in ABT and IRQ contexts ?
2. what is actually in frame 0 ? in other words, how Cortex reacted to data abort while being already in exception handler ?

This device usually starts normally, such situation happens like 3 times per 10 boots. It never happens when starting from debugger, only release and only when started from bootloader.

Two weeks later...

Boot procedure is following:

1. 2nd stage bootloader loads application to memory

2. 2nd stage bootloader jumps to application start.

3. main function of application is entered.

It turns out that sometimes statically initialized values of application have correct values after 1 step of booting, but then in 3 step they are corrupted. I mean application image is corrupted.

Caches haven't been flushed correctly between step 1 and 2.

Disabling caches at 2nd stage bootloader fixed problem at all. Now need to fix that correctly.