Непонятно поведение программы.
Через некоторое время работы (коннект по CSD и прогон данных туда/сюда) процессор вылетает в префетч, При этом в LR бешеный адрес начинающийся на 0xD8.

Вопрос. Я правильно понимаю что каким-то образом портится стек? Как это можно проверить и собственно как его можно попортить? Все указатели прна копирование информации при этом остаются целехонькими соответственно вроде не они.

Подскажите способ каким образом можно отловить момент ошибки а то я что-то не очень понимаю как это побороть?

Для начала, крепко подумать, откуда на стеке может взяться "бешеный адрес начинающийся на 0xD8", иногда по числу удается понять, откуда оно пришло.

Еще можно порекомендовать посмотреть содержимое LR того режима, из которого влетели в аборт.

А нескромный вопрос мона? Какая среда программирования? Какой язык программирования? Тут не боги заседают.

Если это IAR, то нужно сделать следующее:

1. в опциях линкера включить генерацию map файла;
2. посмотреть в этом файле, где лежит сегмент CSTACK;
3. Аккуратно протопать отладчиком, заходя в процедуры и наблюдая за стек пойнтером. Как только SP станет меньше, чем начало сегмента CSTACK, улыбайтесь .
Кстати, отладчик может предупреждать о переполнении стека. Нужно смотреть в окне отладочных сообщений.

Среда и язык программирования к проблеме и методам ее локализации не имеют ну ни малейшего отношения, уж поверьте.


Да-да, отладчиком. Падает оно во время "коннекта по CSD", что несколько ограничивает использование этого инструмента, не находите?

Значение LR при perfetch слабо помогают, потомучто там в 99% случаев действительно дикие значения находятся.
LR помогает data abort отлавливать.
Пару месяцев назад я подобную тему поднимал в итоге пришёл к тому, что в handlere от perfetch вывожу через uart значение всех регистров и несколько десятков байт стека.
И по содержащимся там значениям, похожим на адреса, уже в рукопашную пытаюсь по дизасму находить похожие места.
Во всех случаях источником perfetchей было вызов функций по неинициализированным указателям.

LR_abt действительно слабо, а вот LR исходного режима - весьма сильно.

Пока не надоест

Особенно "полезная" фича, если используется, несколько переключаемых стеков, например, в операционных системах.
Просто надо действительно смотреть при вылете регистры и стек (до сих пор мне 16 значений стека для разборок).

Была у меня похожая проблема, при использовании вложенных прерываний. Так же вылетало в неопределенный момент времени.
В стартапе в обработчике ошибочка была.

Не согласен... Возможно иногда там и сохраняется, нормальный адрес возврата, но только если процессор не успел пробежаться по мусору или не встретил в этом мусоре ничего похожего на brunch. Когда процессор пошёл гулять по мусорным адресам из-за неинициализированного указателя, то первым гибнет корректное значение в LR регистре текущего режима.

По крайней мере мне ниразу не удавалось из LR исходного режима вытянуть полезной информации при perfetch abort, всегда там был мусор.
Другоe дело data abort

Совершенно неубедительно. Во-первых, обычно процессор влетает в prefetch abort или undefined instruction на первой же инструкции после ошибочного перехода. Во-вторых, LR, естественно, не "гибнет первым делом", т.к. для этого нужно или выполнить инструкцию с Rd=LR, или же выполнить инструкцию BL.

Вообще-то если проблема с перетиранием стека (то о чем Вы предположили в самом начале). То вылет по логике вещей должен произойти на выходе из функции сразу после выполнения
LDMIA !R13, {PC}... И LR должен быть целым

однако же там мусор. Perfech abort не той системы наверное.
А вообще не понятно о чём спор. Это вещь сугубо вероятностная.

Несомненно, только вот вероятность Вы оценили как-то странно - "первым гибнет корректное значение в LR регистре текущего режима". Это не так.

Там на самом деле разный мусор. Число каждый раз непонятное, ни очем не говорящее.



Смотрел. Влетаю явно из систем-режима, но в данном регистре вообще был нечетный адрес.

Проблема была хитрой. Парсер от процессора ловил некоторую сигнатуру в данных и принимал ее за команду и... всё.

Но она была явно не одна.

Сейчас наблюдаю вылет по данным.

Проблема в том что без отключенной оптимизации код вместе с сегментом констант и инициализированных данных не влезает в процессор. Соответственно под отладчиком посмотреть не получается - информация для него отсутсвует и он кажет хрень.

Закомментировал некоторое количество кода и запустил без оптимизатора (none и low) - сбоев нет. Включаю оптимизатор и сбоит, причем точку вылета поймать пока не удается - в отладчике опять охинея, плюс он подвисает в самый неудачный момент. Программа без операционки, но с кучей конечных автоматов. Хорошо хоть проблема стабильно проявляется.

Уарты все заняты и в консольку я выбросить ничего не могу, есть только вариант с USB. Однако непонятно как написав обработчик dataabort дотянутся до регистров system.

Чтобы сделать такого чтоб добраться до истока проблемы? Мозг уже сломал.


Не знаю чем поможет такое уточнение. Проц sams256 + IAR4.41A.


Угу. Это если ему будет угодно то да, покажет. Ну если конечно не зависнет.

И не надо ее отключать.


Просто переключиться в режим System.


Выкинуть отладчик, добавить нормальные обработчики abort'ов, и исследовать их вывод.

Туплю.

Как Вам уже рекомендовали, сделайте нормальный обработчик исключений. У меня, например, выдат такую информацию:

Еще ни разу не довелось не найти по ней причину. Адрес известен, функция по map файлу. Место по листингу, если оптимизация сильно мешает понять - отключается на конкретных местах, если функция не виноватая, типа "memcpy", то в Вашем распоряжении LR и стек для поиска первоисточника

Я безусловно приму рекомендации, просто не уверен что uSB у меня по прерываниям нормально сработает, а выдавать больше некуда. Надо думать а время заставляет прыгать и я боюсь напортачить.

Проблему решил. одна функция портила индексную пременную и при пробеге массива случался аборот. как оно работало при отключенном оптимизаторе сказать затруднительно.

Всем спасибо за соболезнования.

Добрый день. Поднимаю тему из-за непонимания.

Все таки, каким образом портится стек?
Ведь с ними работаю не я, а компилятор. Я же просто пишу функции в текстовом виде и обращаюсь к ним тоже в текстовом виде, а все адреса переходов и запоминание и восстановление регистров делает компилятор...

Написал программу, в которой появился Prefetch abort. Появляется он после следующей строки:



То есть, после восстановления регистров...
Но восстанавливается что-то странное. Значение R14 - 0x48d9055d, и, конечно, по этому адресу ничего нет...

Программа построена так:

3 юнита:
Процесс 1 (АЦП).с
Процесс 2 (LCD).с
Объединяющий процесс.с

Из объединяющего процесса запускаю Процесс 1, там по прерываниям опрашивается диапазон значений, после выставляется флаг окончания работы. Объединяющий процесс, среагировав на этот флаг, запускает отображение на LCD - Процесс 2. Заметил особенность - если Процесс 2 запускать из Процесса 1, то ошибки не возникает и все работает как надо.

Научите, как такие вещи лечить? Ну нашел я команду, после которой сбой возникает, но что делать дальше? И как таки эти ошибки возникают?

Спасибо.

Ну, это не совсем так. Компилятор, например, не следит за границами стека, если его не попросить.


Сначала посмотрите, где в этот момент находится SP.