[GreatGehar 0]

Добрый день.

Имеется прибор, внутри которого стоит 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 63]

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

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

 

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

[GenaSPB 11]

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

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

Изменено 8 февраля, 2017 пользователем Genadi Zawidowski

[jcxz 184]

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

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

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

Если нет функции обратной трассировки в отладчике/МК (типа ETB) можно попробовать эмулировать какое-то её подобие.

Я уже описывал здесь на форуме как:

Запустить высокочастотное периодическое прерывание и в его ISR записывать состояния процессора (регистры, несколько слов стека) в кольцевой буфер. Если частота прерывания достаточно высока, то так можно получить точки записи через каждые неск. команд и локализовать место.

И полезно поставить ловушки на все исключения процессора.

Да и MMU поди есть в МК? А значит надо с его помощью разрешить доступ только в нужные регионы памяти. Остальные - на исключение и ловушку.

[mantech 33]

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

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

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

[Шаманъ 0]

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

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

Изменено 9 февраля, 2017 пользователем Шаманъ

[GenaSPB 11]

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

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

[GreatGehar 0]

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

 

Если нет функции обратной трассировки в отладчике/МК (типа ETB) можно попробовать эмулировать какое-то её подобие.

Я уже описывал здесь на форуме как:

Запустить высокочастотное периодическое прерывание и в его ISR записывать состояния процессора (регистры, несколько слов стека) в кольцевой буфер. Если частота прерывания достаточно высока, то так можно получить точки записи через каждые неск. команд и локализовать место.

И полезно поставить ловушки на все исключения процессора.

Да и MMU поди есть в МК? А значит надо с его помощью разрешить доступ только в нужные регионы памяти. Остальные - на исключение и ловушку.

 

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

А мысль про высокочастотное прерывание интересна.

 

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

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

 

Взаимодействие с FPGA в какой-то степени проверяли, полностью исключить пока нельзя, но не думаю, что она. FPGA в этом приборе работает только на чтение памяти, и это чтение отключали, не помогло.

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

 

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

 

CP15 проверить не догадался.

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

Изменено 10 февраля, 2017 пользователем Gehar

[GenaSPB 11]

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

[jcxz 184]

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

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

[Jury093 2]

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

1. чип случайно не перегревается?

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

2.1 мутированный вариант 2, но без паяльника, организовать регистровый вывод в сторону CPU0 и читать содержимое средствами линукса

3. хлопотный вариант - обкусить CPU1 до минимума (базового функционала) и довешивая куски кода, найти проблемную ветку..

[GenaSPB 11]

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

[Forger 17]

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

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

Нужен тока JTAG на плате и любой не древний j-link