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

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

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

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

Он самый. Мусор вполне вероятен, увы


Переключитесь в режим супервизора, и смотрите.

Скорее всего, у Вас или не хватает стека какой-то задаче, или же этот стек кем-то портится.

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

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


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

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

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

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

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

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

Потому что в этом случае для выяснения адреса "беды" возможно придется и в стеке покопаться. А если он запорот весь?
Т.е. вполне возможна такая ситуация: в LR_abt ерунда, в LR режима тоже (ну, мало ли, сохранили адрес возврата на стеке, а LR пустили в расход), стек перетерт.


Это от лени человеческой. Мне и в десяти потенциальных источниках проблем лень копаться, поэтому стараюсь свести к одному

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

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

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

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

Тем, кто столкнулся с описанной выше проблемой, мои соболезнования.
За неделю с лишним ковыряния стэка никаких положительных результатов.
После долгой переписки с суппортом микриума они в конце концов ответили: "Looks like the engineer thinks it might be a problem on our side, tools, than with our SW. Like I said we know the example project works and they just tested it. Your support would fall out of the non-license support."
Что, по-русски говоря, значит примерно следующее "наш косяк, но править не будем, потому что вы лицензию не купили". А покупать лицензию на заведомо нерабочий продукт желания нет никакого.

Поэтому я скачал с сайта NXP стэк NicheLite, и он замечательно заработал.

Скорее всего у вас банальная нехватка стека для какой-то задачи. В IAR есть plug-in для uCOS, которым можно удобно смотреть процент использования стеков. В Кейл не знаю. Но можно оценить, переполняются ли стеки или нет, посмотрев в отладчике массивы стеков для каждой задачи. Потом, если у вас сбой повторяющийся при определенных манипуляциях - то найти причину, дело техники и опыта. Так что лучше постарайтесь разобраться и получить этот опыт, чем с Микриумом переписываться. Они вас просто отфутболили, потому что у них нет интереса искать ваши же косяки, причем вы у них действительно не покупали софт.

В связи с чрезвычайной удобностью uC/OS и необходимостью всё же иметь ethernet, пришлось вернуться к попыткам подружить ОС с её же стэком uC/TCP. Результат оказался положительный, хотя попотеть пришлось с неделю.

Первое, что захотелось сделать, это по совету комрада посмотреть все стэки. Примочка эта есть только в ИАРе, к тому же КЕЙЛовская оболчка мне категорически не нравится (компилятор правда у них хороший). Но не всё так просто, версию ИАР-АРМ 4 найти сложно, а имеющаяся 5-я проект от микримуа компилить не хочет ни в какую. Скачал с микриумовского сайта 4 разных проекта под разные процессоры, в итоге один заработал (uC/OS + uC/LCD + uC/Probe без uC/TCP для LPC2468 (на всякий случай называется LPC2468-SK-OS-Probe-LCD-v5-2.eww)). Заменил в нём все настройки на 2378, добавил uC/TCP из проекта uC/TCP для LPC2378 - и всё скомпилилось.

Второе, в проекте от микриума большой косяк в функции инициализации EMACa, он тупо зависает. Переписал его по даташиту от NXP - заработало.

Третье, при обычной работе тцп-стэка - все его стэки ведут себя как надо. Но при создании исходящего соединения переполняется сначала стэк вызвавшей задачи (я сделал APP_CFG_TASK_PROC2_STK_SIZE равным 400, стало хватать), а затем стэк NET_OS_CFG_IF_RX_TASK_STK_SIZE. Его я сделал равным 300.

За сим всё.