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 режима, в котором случился сбой, может дать какую-то зацепку. Впрочем, он вполне может указывать на недра стандартных библиотек или процедур ОС, вызываемых из тысячи мест.