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

[gbcz]

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

[gbcz]

Ситуация немного проясняется.
Операционка работает нормально, стабильно. Никаких зависаний. Пока не выполнишь какое-нибудь действие с микриумовским TCP-стэком.
И при работе с входящим, и при работе с исходящим TCP соединением ситуация одинаковая:
всё, что выполняется в моем таске (открытие сокета, создание соединения, чтение, запись, закрытие сокета) выполняется без ошибок. После этого дебаггером я пошагово попадаю в IDLE_TASK, в его бесконечный цикл. Там тоже на протяжении сотен итераций всё гладко. И сказать что становится причиной prefetch abort невозможно.
Брэкпоинта перед входом в экцепшен я поставить не могу, ибо не знаю где он. А брэкпоинт в самом эксцепшен-хэндлере малоинформативен. В регистре LR в режиме Abort лежит IP-адрес удалённого сервера куда я подключался. Эксцепшен-хэндлер восстанавливает режим супервизора. В LR регистре некий адрес 0x400038ac. Затем эксцепшен-хэндлер восстанавливает режим, из которого он вызван - то есть Abort, и бегает так по кругу.

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

Это уже интереснее.
Сам я не инициализиую ни контроллер памяти, не PLL. Всё это уже прописано в микриумовских исходниках. Если баги в них, то я уже не знаю, есть ли смысл в использовании их операционки.

[aaarrr]

В регистре LR в режиме Abort лежит IP-адрес удалённого сервера куда я подключался.

Дык ведь нашли практически. Осталось установить, кто может этим адресом затереть не свою память.