Добрый день.
Имеется прибор, внутри которого стоит 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).

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

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

Так что в общих чертах делает эта программа?

В надежности аппаратной части уверены?

Все обработчики прерываний окружить "ногодрыгом" - вывод в порты каких-то сигнатур. По возможности без вызова функций. По последней сигнатуре судить, где побывала программа. Вспомните, что диагностика про запуске персональных компьютеров выдавалась в виде числа в регистр, просто висящий на шине.
При отладке low-level функций иногда удобно "завешивать" в бесконечный цикл при наступлении каких-то неожиданных условий. При этом, подключенившись по jtag вы увидите место, где остановилось выполнение алгоритма и с неразрушенным стеком.

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

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

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

Кроме уже сказанного я бы подумал на предмет временного вырезания всего, что может быть вырезано из программы, с контролем стабильности с каждым "урезанием". Смысл заключается в том, чтобы сузить зону поиска до минимума. Почти уверен, что часть прерываний можно запретить, некоторые куски кода выкинуть и т.п.

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

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



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



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

Выдать сигнатуры... ВСЕ обработчики существуют? В них не остаемся? Их там не много, штук пять... Remap таблицы векторов случайно не включен (или включен не туда, где таблица векторов стоит)?

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

1. чип случайно не перегревается?
2. наколенный старинный вариант - вывести из камня либо а-ля SPI, либо паралельный регистр со светодиодами, а в корке для CPU1 дописать вывод в этот "отладочный интерфейс" например Program Counter или что там занимается адресами.. проц повис и по светикам можно понять примерный адрес..
2.1 мутированный вариант 2, но без паяльника, организовать регистровый вывод в сторону CPU0 и читать содержимое средствами линукса
3. хлопотный вариант - обкусить CPU1 до минимума (базового функционала) и довешивая куски кода, найти проблемную ветку..

Ни вскриков, ни стонов...

Существуют более изящные и функциональные готовые решения, например это: https://www.segger.com/systemview.html
Нужен тока JTAG на плате и любой не древний j-link