Есть процессор с операционкой RTOS, но не стандартной, а специально написанной производителем под этот камень.
Есть таблица прерываний, где четвертым значится "Abort Function".

При очень странных обстоятельствах программа вылетает с этим прерыванием:
при определенной конфигурации портов I/O все ОК, а при небольшом переконфигурировании, которое вообще говоря никак влять не должно, возникает это прерывание и все умирает.

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

Вопрос:
Как можно отловить ПРИЧИНУ этого прерывания? В мане описания не нашел.
То есть мне надо узнать почему такое прерывание может появиться - из-за переполнения стека/памяти/еще чего, чтобы копать уже туда.

Сто раз тут уже писалось - УКАЗЫВАЙТЕ КАКОЙ КОНКРЕТНО CPU
Здесь не телепаты....
Вероятно у вас ARM7 или ARM9.
Тогда у вас возникает "Prefetch Abort". В описании на ядро расписано, что это такое и когда возникает.
Скорей всего - у вас выполнение кода улетает куда-то в недопустимое место и оттуда делается попытка чтения несуществующей памяти.
Отловить точку откуда улетает может быть довольно сложно даже с нормальным jtag-ом.
Хорошо если улёт произошёл по BL-команде, тогда можно посмотреть регистр LR и стек раскрутить.
Если же улёт произошёл по обычному branch или выборке из стека неверной точки возврата (наиболее вероятный случай), либо выборке адреса ISR из неверного места таблицы прерываний, то найти будет трудно.
Восстановите контекст который был перед Abort (по SPSR) и анализируйте содержимое регистров (особенно SP) и режим процессора в точке Abort.

PS: А зачем собственно юзать эту "нестандартную" ОС если есть куча "стандартных"?

Да, прошу прощения.
ARM11.

ОС нестандартная - потому что под эту операционку производителем написано огромное количество нетривиального "demo" кода, которое используется в проекте. Портировать на другую ОС очень много времени требует, да и незачем, вроде как и эта устраивает.

SP перед функцией, откуда возникает Abort, в порядке. Все адреса функций совпадают с map-файлом, дизассемблер дает по этим адресам их нормальный текст.

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

ЗЫ: С ARM11 не имел дела к сожалению

Если процессор попадает в Prefetch Abort, проверьте состояние IFSR.

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

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



о, точно, спасибо!

Это регистр, указывающий откуда данный fault случился? И какой толк? Ну увидит он что процессор попытался выбрать инструкцию с какого-то недопустимого адреса. И что?
Как туда попало управление он не узнает.

Не откуда (это и так известно), а по какой причине. Уменьшение неопределенности.
Или Вы считаете, что информация о внутреннем или внешнем характере аборта никакой ценности не представляет?

Я наверное не селен в работе с операционками, но когда я начинал в дремучие года ЖТАГИ стоили по 700 баксов, а зарплаты были оп 200. Потому все прекрасно обходились без жетага.

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

В чем проблема? или я чего то не понимаю?

П.С. Раньше любой проект начинали с наладки связи по ком порту, да я и сейчас так часто делаю, даже прошу в схемах учитывать эту возможность, отладка с сообщениями иногда работает на порядок лучше ЖЕТАГА со всеми его брекпоинтами...

КОМ порт налажен конечно.
Место мне известно. Нужна причина...

+100
и даже обычный светодиод подходит для ловли и более крутых заморотов. всё дело в упорстве, умении и времени на это затраченное.

мда уж, светодиодом отлаживать медиаприложение как-то слишком уж сурово даже для челябинца

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

А дальше все зависит от того для кого вы пишите и чем отвечаете за сбои....