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

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

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



Сообщение отредактировал nanorobot - Dec 29 2015, 16:05

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

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

Сообщение отредактировал mantech - Dec 29 2015, 17:17

возьмите другую плату да проверьте.
у меня есть тоже запиленная до дыр 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. Вычислить адрес инструкции, на которой проц спотыкается, посмотреть, что там.

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

Сообщение отредактировал nanorobot - Jan 5 2016, 11:50

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

Сообщение отредактировал KnightIgor - Jan 5 2016, 13:15

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