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

Что есть "солидное" число? 100? 1000? 10000? 100000? 1000000?
Опять же, нужно сделать обработчик hard fault, собрать всю имеющуюся информацию и точно установить причину.

солидное число- чисто прикидочно 1000-1500. Обработчик сделан. Из зслуживающей(на мой взгляд) вничания инфрмвции имеем следующее:
в регистре UFSR(старшие 16 бит регистра CFSR) наиболее часто установлен бит INVSTATE, значительно реже имеем установленным бит UNDEFINSTR.
всегда только один из них. Регистр HFSR всегда имеет установленным бит FORCED. При пошаговой отладке однажды было замечено, что ХФ происходит
при выполнении невинной строки типа(последняя строка)

Строку, содержащую whille никак нельзя назвать невинной
В ХФ улетает на конкретной ассемблерной команде. Вот ее надо найти, и крепко задуматься, отчего.

Писал и по 5000 раз - все нормально. Чип - VGT - тот, что на дискавери ставят. Сделайте подсчет контрольной суммы флеша, и сравнение с тем, что грузите, для того, чтобы убедиться, что не в нем проблема...

возьмите другую плату да проверьте.
у меня есть тоже запиленная до дыр discovery f429 , и подобные же спецэффекты не так давно начали проявляться , проблема судя по всему по питанию , ибо если на 0.1 V подать больше , то все работает.

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

Так же порекомендую проверить потребление питания. Возможно, задуматься о дополнительном питании (прямо на ножки питания 3V) от внешней LM1117-3.3 и тому подобных.
Похожая ситуация:
Контроллер посажен на АКБ -> LM1117 -> работает.
Контроллер посажен на БП (5V 2A) -> LM1117 -> Случайные сбросы и отказы программироваться.

Так же можно проверить ёмкости на плате.

Исключил из процедуры вызов библиотечной функцмм pow() - заменил самописаной - наваждение прошло...

А осадок остался.
Причина не найдена, что, скорее всего, означает, что глюк вернётся снова.

... накаркал. Типовая ситуация - в UFSR взводится бит INVSTATE, об'яснение из дефинитив гуиде - attempts to switch to an invalid state (e.g. ARM) - мож подтолкнете в верном направлении?

самое что убивает - при пошаговой отладке глюк практически никогда не воспроизводится

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

ощутил едва уловимый толчок...))

К какой точке приложения? .
TC: так где расчипятка актуального дампа hardfault? Если определится адрес слёта, берем карту памяти компоновщика, ищем, что там поблизости искомого адреса, находим тело функции. Потом можно под отладчиком там остановиться (даже если при этом не сгенерится исключение) и посмотреть, а нет ли там... рекурсии, которая съедает стек, которого, возможно, маловато будет! Как такая идейка?

Кстати - есть ещё в природе отладчики с функцией трэйсера! Очень пользительная вещь в данном случае!

CFSR = 0x20000
HFSR = 0x40000000
DFSR = 0x01
AFSR = 0x0
MMAR = 0xE000ED34
BFAR = 0xE000ED38
PSR = 0x60000000
LR = 0x800A1D7
R0 = 0x0
R1 = 0x2001D370
R2 = 0x2001D370
R12 = 0x0

LR содержит, если я правильно понимаю, адрес следующей инструкции по отношению к вызвавшей ХФ.
дизасм сотв фрагмента прилагаю. Судя по всему там содержатся сервисы ChibiOS, которую я использую.

Стек для задач попробуйте увеличить.

только что методом научного тыка проблема решилась, по крайней мере для данной процедуры. Процедура вызывается из треда(задачи) с приоритетом среднего уровня. В процедуре имеются локальные параметры. Я ко всем описаниям локальных параметров добавил спецификатор static. Проблема ушла. Хороший повод спросить более грамотных товарищей - имееи ли смысл об'являть статическими локальные переменные в процедуре вызываемой из треда(задачи), либо локальные переменные самого треда? По идее выхода из треда(имеется в виду связанной с ним процедуры) нет, значит локальные переменные не разрушаются и без статик.
вероятно Ваш совет к этой теме тоже имеет отношение, сейчас прпробую.
Благодарю Вас за ответ



Помогло. Премного благодарен. Успехов в новом году.

Квалификатор static указывает что переменную необходимо разместить глобально. В противном случае эта переменная будет размещена локально (то есть на стеке). Иными словами вы просто чуть уменьшили необходимый для задачи объём стека.
При использовании того или иного квалификатора надо чётко понимать зачем он нужен и как он работает. Здесь не может быть общих рекомендаций.

Зато могут быть танцы с бубном: "static! спасибо, прошло."

Побороли симптом.

Спецификатором static вы переместили эти переменные из стека туда же, где хранятся глобальные переменные. Возможно стек текущей задачи портился другой задачей. Теперь вы текущую задачу от этого защитили, а задача, которая портила ей стек, портит его другой задаче. :-)