Ядро процессора TI AM572x Cortex-A15 зависло

У меня проблема со стабильностью работы пользовательской платы на базе TI AM5728, похожей на Beaglebone X15. RTOS SW работает на одном ядре Cortex-A15 MPU0 и время от времени (чаще всего через несколько часов) зависает. При зависании невозможно подключиться к цели MPU0 отладчиком, в то же время без проблем могу подключиться к MPU1.

Ошибка отладчика:

CortexA15_0: проблема с остановкой целевого ЦП: (ошибка -1323 @ 0x1386AC) Устройству не удалось войти в режим отладки/остановки, поскольку конвейер остановлен. Выключите питание платы. Если ошибка повторяется, подтвердите конфигурацию и/или попробуйте более надежные настройки JTAG (например, понизьте TCLK). (Пакет эмуляции 6.0.504.1)

В целях тестирования я запустил простую программу на MPU1, и когда MPU0 зависает, MPU1 продолжает нормальную работу. Флаг WFE и WFI для MPU0 неактивен, более того, я сделал дополнительный тест с попыткой перевести MPU1 в состояние WFI/FORCED_OFF. Однако я все еще могу подключиться к отладчику и вывести его из состояния FORCED_OFF, как описано в техническом руководстве.

Сбросил регистры подключением к CS_DAP_DebugSS и ничего особенного не нашел. Дамп реестра прилагается:

MPU_PRCM_PRM_C0_PM_CPU0_PWRSTCTRL

MPU_PRCM_DEVICE_PRM_RSTST

MPU_WUGEN_WKG_CONTROL_0

MPU_PRCM_CM_C0_CM_CPU0_CLKSTCTRL

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

Какая аппаратная/программная проблема потенциально может вызвать такое поведение?

Спасибо за любые предложения.


person rhr    schedule 07.11.2017    source источник
comment
По-видимому, эта часть содержит 114 страниц опечаток. Что действительно может пойти не так.   -  person Lundin    schedule 07.11.2017
comment
Спасибо за совет, но это был первый документ, который я проверил, когда начал расследование этого вопроса. К сожалению, не могу найти ничего, связанного с моей проблемой.   -  person rhr    schedule 07.11.2017


Ответы (1)


Я просто сталкиваюсь с точно такой же проблемой. Вы проверили свой код по указанному адресу с ошибкой JTAG (Ошибка -1323 @ 0x1386AC)? В моем случае это доступ GPMC к FPGA, к которому я все еще могу получить доступ через CS_DAP_DebugSS. В настоящее время я просматриваю опечатки i878 из версии L документа. Поскольку зависание при стресс-тесте может занять более 48 часов, я не буду слепо применять обходной путь. Я изменю свой тест, основанный на i878, попытаюсь увеличить частоту отказов, а затем применю обходной путь.

person user10590848    schedule 01.11.2018