|
uC/OS-II и PREFETCH ABORT exception |
|
|
|
Feb 3 2009, 14:15
|
Группа: Новичок
Сообщений: 6
Регистрация: 2-06-08
Пользователь №: 37 992

|
Здравствуйте, уважаемые. При работе с TCP-стэком в uC/OS-II постоянно происходит PREFETCH ABORT exception. Может быть кто-нибудь знает, от чего это происходит (видел кто-то писал о ретаргетинге библиотек, но невнятно) или как это можно обрабатывать? Компилятор Keil. Процессор LPC2378. Заранее благодарен.
|
|
|
|
|
Feb 3 2009, 15:14
|
Группа: Новичок
Сообщений: 6
Регистрация: 2-06-08
Пользователь №: 37 992

|
Цитата(aaarrr @ Feb 3 2009, 17:33)  Смотрите LR_abt и содержимое стека того режима, в котором случился аборт. Можно пояснить, что такое LR_abt? Если имеется ввиду R14, то в нём мусор. По поводу режимов. uC/OS работает в режиме супервизора. Когда случается аборт - проц переходит в режим аборт. Может посоветуете, как в этом режиме смотреть содержимое стэка супервизора?
|
|
|
|
|
Feb 3 2009, 15:22
|
Гуру
     
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448

|
Цитата(gbcz @ Feb 3 2009, 18:14)  Если имеется ввиду R14, то в нём мусор. Он самый. Мусор вполне вероятен, увы  Цитата(gbcz @ Feb 3 2009, 18:14)  Может посоветуете, как в этом режиме смотреть содержимое стэка супервизора? Переключитесь в режим супервизора, и смотрите. Скорее всего, у Вас или не хватает стека какой-то задаче, или же этот стек кем-то портится.
|
|
|
|
|
Feb 3 2009, 17:35
|
Гуру
     
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448

|
Цитата(AlexandrY @ Feb 3 2009, 20:21)  Не должно там быть мусора. Если уж случился prefetch abort, то может. Загрузили PC неизвестно откуда, вот и результат. Цитата(AlexandrY @ Feb 3 2009, 20:21)  Замечал что LR (R14) по какой-то причине теряет свое настоящее значение сразу после первых тактов выполения команд в режиме аборта, в ARM9 правда. Что-то странное, никогда такого не видел ни на 7-х, ни на 9-х.
|
|
|
|
|
Feb 3 2009, 19:22
|

Ally
     
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050

|
Не так много мест в адресном пространстве ARM-ов куда может залететь программа чтобы теряться в догадках. В LR должен строго быть адрес последней инструкции в нескольких тактах от которой произошел сбой. Ставите брекпоинт там и перехватываете ситуацию до аборта. По содержимому рабочих LR и стека узнаете как минимум из какой задачи произошел сбой и что перед этим вызывалось. Передвигая брекпойнт за пару итераций точно находите где что-то пошло не так. Если причина в испорченом содержимом памяти, то брекпоинты можно поставить и по событию записи в память и точно узнать откуда произошла нелегальная запись Короче проблема не больше чем на почаса при любом раскладе. Главное что она стабильно воспроизводима. Цитата(aaarrr @ Feb 3 2009, 19:35)  Если уж случился prefetch abort, то может. Загрузили PC неизвестно откуда, вот и результат.
|
|
|
|
|
Feb 3 2009, 21:02
|

Ally
     
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050

|
 Перебор в слове "тысячи" Еслиб все было так сложно реверсинженеры бы все посходили с ума. Не понял почему вы видите трудность в том что сбойнула выборка инструкци и не данных. Адрес того места все равно остается адресом и искать надо начинать от туда. Даже если поиски увели в библиотечную функцию, то по MAP файлу ее название легко вычисляется. Мест откуда вызывается библиотечная функция любая очень редко когда превышает десяток-другой. А обычно одно только название функции уже дает ключ к понятию проблемы. Поэтому я и оцениваю поиск в полчаса, а не в 5-ть минут Другое дело, что prefetch abort обычно симптом плохо инициализированного контроллера памяти или PLL, что ведет к сбоям при чтении FLASH и сносит крышу на самой шине AHB. Тут значит сбои должны проявляться еще где-то. Только нам не говорят Цитата(aaarrr @ Feb 3 2009, 22:29)  В LR_abt будет адрес инструкции (точнее, адрес инструкции + 4), которую процессор уже не смог выбрать. Это с data abort все легко, а в случае prefetch abort/unknown instruction содержимое LR_abt может ничем не помочь.
А вот LR режима, в котором случился сбой, может дать какую-то зацепку. Впрочем, он вполне может указывать на недра стандартных библиотек или процедур ОС, вызываемых из тысячи мест.
|
|
|
|
|
Feb 4 2009, 08:44
|
Группа: Новичок
Сообщений: 6
Регистрация: 2-06-08
Пользователь №: 37 992

|
Ситуация немного проясняется. Операционка работает нормально, стабильно. Никаких зависаний. Пока не выполнишь какое-нибудь действие с микриумовским TCP-стэком. И при работе с входящим, и при работе с исходящим TCP соединением ситуация одинаковая: всё, что выполняется в моем таске (открытие сокета, создание соединения, чтение, запись, закрытие сокета) выполняется без ошибок. После этого дебаггером я пошагово попадаю в IDLE_TASK, в его бесконечный цикл. Там тоже на протяжении сотен итераций всё гладко. И сказать что становится причиной prefetch abort невозможно. Брэкпоинта перед входом в экцепшен я поставить не могу, ибо не знаю где он. А брэкпоинт в самом эксцепшен-хэндлере малоинформативен. В регистре LR в режиме Abort лежит IP-адрес удалённого сервера куда я подключался. Эксцепшен-хэндлер восстанавливает режим супервизора. В LR регистре некий адрес 0x400038ac. Затем эксцепшен-хэндлер восстанавливает режим, из которого он вызван - то есть Abort, и бегает так по кругу.
Другое дело, что prefetch abort обычно симптом плохо инициализированного контроллера памяти или PLL, что ведет к сбоям при чтении FLASH и сносит крышу на самой шине AHB. Тут значит сбои должны проявляться еще где-то. Только нам не говорят
Это уже интереснее. Сам я не инициализиую ни контроллер памяти, не PLL. Всё это уже прописано в микриумовских исходниках. Если баги в них, то я уже не знаю, есть ли смысл в использовании их операционки.
|
|
|
|
|
Feb 9 2009, 12:37
|
Группа: Новичок
Сообщений: 6
Регистрация: 2-06-08
Пользователь №: 37 992

|
Тем, кто столкнулся с описанной выше проблемой, мои соболезнования. За неделю с лишним ковыряния стэка никаких положительных результатов. После долгой переписки с суппортом микриума они в конце концов ответили: "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, и он замечательно заработал.
|
|
|
|
|
Mar 18 2009, 11:34
|
Группа: Новичок
Сообщений: 6
Регистрация: 2-06-08
Пользователь №: 37 992

|
В связи с чрезвычайной удобностью 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.
За сим всё.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|