Отладка А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).

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

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

[aaarrr]

...Приблизительно установлено место в программе, в котором происходит зависание;

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

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

[Genadi Zawidowsk...]

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

Сообщение отредактировал Genadi Zawidowski - Feb 8 2017, 13:33

[jcxz]

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

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

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

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

[mantech]

Второе ядро (cpu1) выполняет программу реального времени, управляющую блоком в FPGA.

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

[Шаманъ]

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

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

Сообщение отредактировал Шаманъ - Feb 9 2017, 07:55

[Genadi Zawidowsk...]

в наиболее важные системные регистры процессора (во всяком случае отладчик не зарегистрировал обращений по этим регистрам перед зависанием): DDR Memory Controller, L2 Cache Controller, System Level Control Registers (slcr).

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

[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

[Genadi Zawidowsk...]

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

[jcxz]

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

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

[Jury093]

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

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

[Genadi Zawidowsk...]

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

[Forger]

2. наколенный старинный вариант - вывести из камня либо а-ля SPI, либо паралельный регистр со светодиодами, а в корке для CPU1 дописать вывод в этот "отладочный интерфейс" например Program Counter или что там занимается адресами.. проц повис и по светикам можно понять примерный адрес..

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