Доброго времени суток! Ранее не сталкивался с падением кода в Hard Fault, но недавно это случилось. Запустил дебаг в Keil, при падении получаю следующую картину:

Не могу идентифицировать, на что указывает содержимое регистра SCB->BFAR = 0x20031CDA... Там, как я понял, можно найти причину падения.
Содержимое регистра PC (на сколько понял, в нём сохранён адрес инструкции, вызвавшей падение) при этом ссылается на начало функции main(), на строку, где я присваиваю значение переменной. Но до момента падения код может спокойно и чётко выполняться в течение часа и более.


Есть идеи, куда нужно копать?

Добавлено after 1 hour 18 minutes 40 seconds:
Камень использую STM32L151CB-A. У него 128к флэша и 32к оперативы. Оператива начинается с 0x20000000, оканчивается соответственно 0x20007D00. Периферия начинается с 0x40000000. Так вопрос, тогда куда меня посылает дебаг по адресу 0x20031CDA?

Причину легко найти посмотрев в стеке последовательность вызовов функций. http://purebasic.mybb.ru/viewtopic.php?id=564#p7599

Там же галка PRECISERR стоит.
https://www.keil.com/dd/vtr/5094/8687.htm

Всё верно, галка стоит, смотрим адрес инструкции в PC.

Ну так вот, никак прога не может туда попасть, только через ресет

Добавлено after 3 minutes 34 seconds:

Жду падения кода, чтобы глянуть на стек вызовов. Уже час прошёл с момента запуска

Видимо Вы:
а) или раньше не работали с Cortex-M;
б) или очень аккуратный программист.

Не совсем так. Видимо это содержимое PC при котором произошёл HF. Хотя при PRECISERR - это одно и то же.

Добавлено after 1 minute 45 seconds:
Может. Если где-то портите стек.

Если причина HF - порча стека, то это ничего не даст. А с большой вероятностью это она и есть.

Увеличивайте все стеки на максимум, заполняйте шаблоном и после некоторого времени работы проверяйте уровень заполненности.

7 лет кортексы прогаю, но всё бывает впервые))
Подсказать можете, где в дебаггере глянуть заполненность ОЗУ?

7 лет "прогаете" и не знаете что такое "порча стека"?? Не верю!!!

Не ОЗУ, а стека. Смотрится на вкладке "память" или как она там в кейле зовётся.

Похоже, проблема с переполнением стека действительно имеет место быть. Заглянул в область оперативы при падении - от макушки до низа была занята. Хочу посмотреть на заполнение стека в процессе, нашёл способ "окраски" с помощью такой функции:


взял отсюда, вставил в конец стартапа - ничё не окрасилось.

Вопроса два:
1. Как всё-таки окрасить стек, куда правильно воткнуть эту функцию?
2. Что можно сделать для уменьшения расхода стека?

Добавлено after 11 minutes 27 seconds:
К стати, вопрос, что мне хотел сказать дебаггер записью SCB->BFAR = 0x20031CDA, для меня остался открытым. Перешёл по этому адресу, а там космос, память не доступна для чтения, оно и понятно, её там нет и быть не может

А что должно было "окраситься"?
Куда угодно. Главное выполнить её когда ещё стек не порушен.

Переработать алгоритм программы.

Видимо адрес, по которому обратилась ваша программа (обратилась та команда, адрес которой в PC).
Если произошло разрушение стека, то на это можно вообще внимания не обращать - это не причина HF, причина - разрушение стека.
А вообще - описание регистров ядра есть в мануале на ядро Cortex-M.

Тут есть пример, ищи Bad Address Read.

Возможно, у вас большая цепочка вызовов функций, при том что RAM и так занят, а там еще какое-нибудь прерывание стэк жрет - и в какой-то момент стэка однажды не хватает? Далее возможны варианты. Если у вас стэк был НАД переменными - вообще скажите спасибо что упало в hard fault а не просто глючило, перетерев стэком область переменных.

И не знаю как в кейле а gcc умеет репортить использование стэка и показывать наиболее прожорливые по стэку функции, вот как раз на такие случаи. Может прошляпить что-нибудь типа рекурсии или VLA, но так делать не надо. Наверное и в кейле что-то такое есть? Ну и как-то странно вы 7 лет эти штуки программили что не можете убедить их стэк константой заполнить. А "Как всё-таки окрасить стек, куда правильно воткнуть эту функцию?" - ответ на этот вопрос требует как минмум знания лэйаута RAM и понимания кто и что делает до и после вызова этой функции. И как это в кейле.

Я бы вообще
1) сперва проверил что ваша конструкция вменяемое значение адреса стэка в принципе возвращает.
2) а потом - что начало и конец стэка не перепутаны, что из вашего описания не совсем очевидно. А start действительно меньше top?
3) и хрен его знает насколько там оптимизатор прикалывается, оптимизатор на раз видит что результат нигде не используется и норовит забить на всю операцию. Формально volatile есть но лучше проверить что код по факту сгенерился и вызывается.
4) кто-нибудь опосля может что-то инициализировать наверное.

А так - я например стэк повесил в самом низу, если переполняется - hard fault сразу, за факт обращения ниже 0x20000000, еще на моменте сохранения в стэк процом. Порушиться соответственно не успевает (однако часть стэкфрейма потеряна, корректно вернуться нельзя, равно как и трейс будет инопланетный). А у handler'ов на такой случай я свой стэк в msp, выше основного сделал, так они свой стэк получат в любом случае. В L15x наверное можно MPU и без этого обойтись, но в F1xx MPU нету...


При переполнении стэка код дуреет а состояние системы разрушено. Может быть что угодно - состояние системы нельзя считать достоверным. Бывает и похуже чем harffault, у тойот например водитель отпускал педальку - а авто уходило в разгон, потому что стэк вырос ниже области переменныз, перетер переменные - и вообще красота. С тех пор некоторые стали класть переменные выше стэка - harffault лучше чем это. А как у вас - кто ж его знает, весь layout не видно. А куда указывает тот или иной адрес по идее в map-файле пишется. Если кейл конечно умеет что-то такое генерить. Наверное должен, это почти любой вменяемый компилятор умеет.

Похоже здесь народ под "порчей стека" понимает только "переполнение стека". Хотя я вроде ясно выразился именно "порча стека", а не только его переполнение.
Переполнения может и не быть, а содержимое стека испортиться из-за багов в программе (например: из-за обращения по указателю к локальным переменным (на стеке)).
Порчу содержимого стека не увидеть всякими заполнениями шаблоном и просмотром в отладчике.

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

Элементарно:

Элементарная невнимательность. Сначала написал код, а потом что-то добавил не глянув на размер буфера.

Кошмар, это в фирмвари МК такое?! За такое сейчас в обычных то программах в приличных местах норовят покрыть матом статическим анализом и проч - чревато крахами а то и уязвимостями . Эту функцию вообще использовать не следует. Она с самого начала проблемная.
Поэтому умные люди давно придумали штуки типа правил MISRA, исключающие подобные ситуации. Как мне кажется, при серьезном увлечении МК неплохо бы прочитать что-то такое, чтоли. Тогда писать такой код просто в бошку не придет, на уровне рефлексов просто.

Пардон за флейм, лучше пойду dma по кольцу кодить. Вот оно стремноватое by design, это да. Но там на это есть хорошие причины хотя-бы.

Это для примера. Разумеется - лучше использовать какой-то вариант sprintf() с контролем размера буфера. Но это не убережёт от ошибок в арифметике указателей.

Не писать код с указателями? Да, можно конечно на яве писать, но при этом потеряв кратно в эффективности и быстродействии кода.
Тогда уж и на бейсике можно.

Можно ведь и котлован под дом копать детским совочком. Ведь ежли экскаватором - то можно и покалечить кого-нить невзначай. А совочком - оно безопаснее ведь, правда?
Вот только почему-то не отказываются от экскаваторов....

Чем вам бейсик неугодил что вы его приравняли к java?
Для армов бейсиков немного (а те что есть не самые лучшие), а для компа встречаются хорошие экземпляры.

Поэтому ее должно быть как можно меньше и только по делу, под особым вниманием, логично же.

Вообще не использовать указатели не получится - хотя-бы для регистров все же надо. Но вот арифметика там ни к чему - все можно как compile-time constant оформить. Это сильно уменьшает риски. И как сказал один почтенный человек, преждевременная оптимизация - корень всех зол. Глядя на это - а ведь он прав!


Мне кажется есть 2 полюса:
- Ламеризм типа бэйсика, когда програмер не рубит что и почему, оптимальность - "индусы лучше". За програмера подумает бэйсик. А может и не подумает, как это часто оказывается. Но в этом случае картина выглядит жалко.
- Хакеризм, код изобилует выходками во имя эффективности а то и трюкачества. Код может и эффективный, но баги крайне неочевидные, а попытка что-то менять, особенно другим человеком - ломает все. К тому же програмер и сам через год забудет где свинью разложил.

И вот именно поэтому умные люди и придумали наборы правил, позволяющих подобных ситуаций избегать. Чтобы не шарахаться в крайности и получить какой-то разумный баланс сил, когда и код не глюкавый и оптимальность не бэйсиковая.

Еще можно пригнать состав с динамитом и взорвать. Пусть экскаваторщик выкусит! Сколько он с таким котлованом копаться будет?! А тут бах и готово. Потом правда никто не понимает на что указывает табличка "дом номер 20". Толи эти руины и правда он, толи ее взрывом принесло.

p.s. а на месте жавистов я бы обиделся что их к бэйсику приравняли. Эти по крайней мере бизнеслогику кодят, любителей бэйсика туда никто близко не подпустит.

Не можно. Если реализуете задачу сложнее чем мигание парой лампочек. В реальных задачах без указателей или индексов в массивах - не обойтись никак.

Не рискует только тот, кто ничего не делает.

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

На мой вкус, если в результате оптимизаций заканчивается вынесенным стэком - возникает вопрос: а оно того стоило?!

Почему-то при этом вспоминаются горы мяса и металла пытавшиеся проскочить перед поездом. Они, несомненно, пытались оптимизировать себе 2 минуты времени, но глядя на результат вышеупомянутый вопрос все же возникает. Как мне кажется, не любая оптимизация стоит рисков. И если кто-то в результате выносит стэк... это даже на PC у раздолбайских програмеров нехилая экзотика.