Как понять, почему происходит исключение ARM?

Я пытаюсь понять, в чем причина возникшего у меня исключения ARM. Это происходит случайно во время запуска системы и может выглядеть по-разному.

Один из самых простых:

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)

Насколько я понимаю, было какое-то текущее исключение, которое можно увидеть в кадре 1. Он пытается сохранить регистры в стек:

101 stmfd sp !, {r0-r12} @ save r4-r12 пока мы на этом

Но указатель стека был неправильным:

ABT: R13 = 7FFFFF88

Я не понимаю обоих:

  1. Что может быть причиной такого значения SP в контекстах ABT и IRQ?
  2. что на самом деле в кадре 0? другими словами, как Cortex отреагировал на прерывание данных, уже находясь в обработчике исключений?

Обычно это устройство запускается нормально, такая ситуация бывает примерно 3 раза за 10 загрузок. Этого никогда не происходит при запуске из отладчика, только при выпуске и только при запуске из загрузчика.


person wiesniak    schedule 04.05.2018    source источник
comment
Ваша память испорчена. Я подозреваю, что это дикий указатель, который вызывает разные шаблоны доступа к памяти. Действителен ли код R14_SVC (0x22071)? Вы должны попробовать initcall_debug и другие значения kconfig, чтобы проверить наличие проблем с памятью.   -  person artless noise    schedule 04.05.2018


Ответы (1)


Две недели спустя...

Процедура загрузки следующая:

  1. Загрузчик 2-го этапа загружает приложение в память

  2. Загрузчик 2-го этапа переходит к запуску приложения.

  3. введена основная функция приложения.

Оказывается, иногда статически инициализированные значения приложения имеют правильные значения после 1 шага загрузки, но затем на 3 шаге они повреждаются. Я имею в виду, что изображение приложения повреждено.

Кеши не были очищены правильно между шагами 1 и 2.

Отключение кешей на 2-м этапе загрузчика решило проблему. Теперь нужно это исправить.

person wiesniak    schedule 14.05.2018
comment
Устанавливает ли ваш загрузчик таблицы трансляции MMU? Вы можете очистить память в нужный момент вместо отключения кеша. - person harper; 14.05.2018
comment
@harper, да, но нет трансляции адресов, но есть записи в таблицах трансляции (я имею в виду, что трансляция адресов всегда x в x). Отключение кешей было лишь своего рода подтверждением концепции. Теперь я очищаю кеши в загрузчике, в конце процедуры копирования образа. Похоже, проблема исчезла полностью. - person wiesniak; 14.05.2018
comment
Когда вы устанавливаете адрес таблицы MMU в CP15, таблица считывается из SDRAM. Если кеш не очищен в этот момент, вы можете получить недопустимые записи в таблице. - person harper; 15.05.2018