Непонятно поведение программы.
Через некоторое время работы (коннект по 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'ов, и исследовать их вывод.