uC/OS-II и PREFETCH ABORT exception Опции

[gbcz]

Здравствуйте, уважаемые.
При работе с TCP-стэком в uC/OS-II постоянно происходит PREFETCH ABORT exception. Может быть кто-нибудь знает, от чего это происходит (видел кто-то писал о ретаргетинге библиотек, но невнятно) или как это можно обрабатывать?
Компилятор Keil.
Процессор LPC2378.
Заранее благодарен.

[aaarrr]

как это можно обрабатывать?

Смотрите LR_abt и содержимое стека того режима, в котором случился аборт.

[gbcz]

Смотрите LR_abt и содержимое стека того режима, в котором случился аборт.

Можно пояснить, что такое LR_abt?
Если имеется ввиду R14, то в нём мусор.

По поводу режимов. uC/OS работает в режиме супервизора. Когда случается аборт - проц переходит в режим аборт.
Может посоветуете, как в этом режиме смотреть содержимое стэка супервизора?

[AlexandrY]

Не должно там быть мусора.
Ставте точку останова прямо на входе в аборт.
Замечал что LR (R14) по какой-то причине теряет свое настоящее значение сразу после первых тактов выполения команд в режиме аборта, в ARM9 правда.

Можно пояснить, что такое LR_abt?
Если имеется ввиду R14, то в нём мусор.

По поводу режимов. uC/OS работает в режиме супервизора. Когда случается аборт - проц переходит в режим аборт.
Может посоветуете, как в этом режиме смотреть содержимое стэка супервизора?

[aaarrr]

Не должно там быть мусора.

Если уж случился prefetch abort, то может. Загрузили PC неизвестно откуда, вот и результат.

Замечал что LR (R14) по какой-то причине теряет свое настоящее значение сразу после первых тактов выполения команд в режиме аборта, в ARM9 правда.

Что-то странное, никогда такого не видел ни на 7-х, ни на 9-х.

[AlexandrY]

Не так много мест в адресном пространстве ARM-ов куда может залететь программа чтобы теряться в догадках.
В LR должен строго быть адрес последней инструкции в нескольких тактах от которой произошел сбой.
Ставите брекпоинт там и перехватываете ситуацию до аборта.
По содержимому рабочих LR и стека узнаете как минимум из какой задачи произошел сбой и что перед этим вызывалось.
Передвигая брекпойнт за пару итераций точно находите где что-то пошло не так.
Если причина в испорченом содержимом памяти, то брекпоинты можно поставить и по событию записи в память и точно узнать откуда произошла нелегальная запись
Короче проблема не больше чем на почаса при любом раскладе.
Главное что она стабильно воспроизводима.

Если уж случился prefetch abort, то может. Загрузили PC неизвестно откуда, вот и результат.

[aaarrr]

В LR должен строго быть адрес последней инструкции в нескольких тактах от которой произошел сбой.

В LR_abt будет адрес инструкции (точнее, адрес инструкции + 4), которую процессор уже не смог выбрать. Это с data abort все легко, а в случае prefetch abort/unknown instruction содержимое LR_abt может ничем не помочь.

А вот LR режима, в котором случился сбой, может дать какую-то зацепку. Впрочем, он вполне может указывать на недра стандартных библиотек или процедур ОС, вызываемых из тысячи мест.

[AlexandrY]

Перебор в слове "тысячи"
Еслиб все было так сложно реверсинженеры бы все посходили с ума.
Не понял почему вы видите трудность в том что сбойнула выборка инструкци и не данных.
Адрес того места все равно остается адресом и искать надо начинать от туда.
Даже если поиски увели в библиотечную функцию, то по MAP файлу ее название легко вычисляется.
Мест откуда вызывается библиотечная функция любая очень редко когда превышает десяток-другой.
А обычно одно только название функции уже дает ключ к понятию проблемы.
Поэтому я и оцениваю поиск в полчаса, а не в 5-ть минут

Другое дело, что prefetch abort обычно симптом плохо инициализированного контроллера памяти или PLL, что ведет к сбоям при чтении FLASH
и сносит крышу на самой шине AHB.
Тут значит сбои должны проявляться еще где-то. Только нам не говорят

В LR_abt будет адрес инструкции (точнее, адрес инструкции + 4), которую процессор уже не смог выбрать. Это с data abort все легко, а в случае prefetch abort/unknown instruction содержимое LR_abt может ничем не помочь.

А вот LR режима, в котором случился сбой, может дать какую-то зацепку. Впрочем, он вполне может указывать на недра стандартных библиотек или процедур ОС, вызываемых из тысячи мест.