Отладка АRMv7 (Cortex-A9), Нужна помощь, советы, идеи в поиске неординарной ошибки Опции

[Gehar]

Добрый день.
Имеется прибор, внутри которого стоит 2х-ядерный Cortex-A9 (производства Xilinx, семейство Zynq). Система работает в AMP режиме: cpu0 - Linux, cpu1 - standalone, то есть без ОС. Второе ядро (cpu1) выполняет программу реального времени, управляющую блоком в FPGA. Обнаружено, что при определенных условиях процессор "помирает", да так помирает, что не возможно подключиться даже отладчиком (через JTAG) к нему и посмотреть состояние памяти, регистры, на каком месте остановилось управление, отладчик выдает ошибку таймаута. Никаких следов, что случилось, после этого не остается.
Что сделано:
1. Определены условия, при которых процессор зависает ("помирает") и написана программа управления прибором, способная за 30-60 секунд повесить процессор (именно процессор, а не программу);
2. Приблизительно установлено место в программе, в котором происходит зависание;
3. Проверено, что программа не пишет ничего в наиболее важные системные регистры процессора (во всяком случае отладчик не зарегистрировал обращений по этим регистрам перед зависанием): DDR Memory Controller, L2 Cache Controller, System Level Control Registers (slcr).

Занимаюсь этой ошибкой (активно) уже около месяца и никак не могу понять, что происходит. Может быть кто-то сталкивался с подобной ситуацией?
Сегодня появилась мысль попробовать аппаратный трассировщик, может быть с его помощью удастся зарегистрировать что происходит с системой перед смертью? Только его пока у нас нет, нужно покупать... И какой брать тоже не известно пока, у нас никто с ними не сталкивался.

Так же есть другой прибор (с другим назначением, кодом, но идентично помирающий), тоже требуется понять, в чем причина...
Есть ли у кого-либо идеи, как отловить ошибку?

[jcxz]

программа не пишет ничего в наиболее важные системные регистры процессора (во всяком случае отладчик не зарегистрировал обращений по этим регистрам перед зависанием):

Вот в этом есть сомнения.

Есть ли у кого-либо идеи, как отловить ошибку?

Если нет функции обратной трассировки в отладчике/МК (типа ETB) можно попробовать эмулировать какое-то её подобие.
Я уже описывал здесь на форуме как:
Запустить высокочастотное периодическое прерывание и в его ISR записывать состояния процессора (регистры, несколько слов стека) в кольцевой буфер. Если частота прерывания достаточно высока, то так можно получить точки записи через каждые неск. команд и локализовать место.
И полезно поставить ловушки на все исключения процессора.
Да и MMU поди есть в МК? А значит надо с его помощью разрешить доступ только в нужные регионы памяти. Остальные - на исключение и ловушку.

[Gehar]

Вот в этом есть сомнения.

Если нет функции обратной трассировки в отладчике/МК (типа ETB) можно попробовать эмулировать какое-то её подобие.
Я уже описывал здесь на форуме как:
Запустить высокочастотное периодическое прерывание и в его ISR записывать состояния процессора (регистры, несколько слов стека) в кольцевой буфер. Если частота прерывания достаточно высока, то так можно получить точки записи через каждые неск. команд и локализовать место.
И полезно поставить ловушки на все исключения процессора.
Да и MMU поди есть в МК? А значит надо с его помощью разрешить доступ только в нужные регионы памяти. Остальные - на исключение и ловушку.

То, что программа что-то куда-то пишет, но не туда, куда надо, в этом сомнений почти нет. Возможно в какой-нибудь жизненно-важный регистр, там этих регистров... Устройств только несколько десятков (Zynq 7000), а общее число регистров под 1000...
А мысль про высокочастотное прерывание интересна.

Это взаимодействие проверяли? ФПГА связано с шинами проца, может что выставляет туда "нехорошее". Можно попробовать пока его отключить и сэмулировать функционал программно...
И второе, линукс, который на первом ядре, точно не вносит в работу никаких особенностей, может проверить пока без него?

Взаимодействие с FPGA в какой-то степени проверяли, полностью исключить пока нельзя, но не думаю, что она. FPGA в этом приборе работает только на чтение памяти, и это чтение отключали, не помогло.
Linux вчера пробовал отключить: полностью исключить его работу сложно, он выполняет функции связи с внешним миром, но после получения всех нужных параметров программа на cpu1 отключала тактовую частоту и подавала сигнал сброса на ядро с Linux, после чего Linux переставал существовать, а cpu1 спустя 10 секунд завис.

Остальные (кроме перечисленных) тоже важные... Весь набор CP15 например, GICC_PMR тоже не последнюю роль играет.

CP15 проверить не догадался.
Только что проверил "по-быстрому": запретил изменять "Некоторые регистры GIC и CP15" (так написано в документации), процессор завис в положенный момент времени.

Сообщение отредактировал Gehar - Feb 10 2017, 05:20

[jcxz]

То, что программа что-то куда-то пишет, но не туда, куда надо, в этом сомнений почти нет. Возможно в какой-нибудь жизненно-важный регистр, там этих регистров.

Кто же Вам мешает это место найти используя защиту памяти?