Ну, вышли с испорченными регистрами и SP - сильно легче стало?

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

Еще проанализировать, куда сохранили испорченные регистры, тоже восстановить... Главное ведь, не перезагружаться - то каждый может

У меня сброс прибора не пройдет незамеченным для пользователя. Так зачем напрягаться? Сам и передернет питание, если увидит, что прибор завис.
У меня комп на работе по некой причине каждое утро перезагружается с голубым экраном. А после этого трудится весь день без сбоев. В чем причина, не знаю. То ли питания мало, то ли ломалка так работает. Но очень неприятно. Сидишь, мышой водишь, и вдруг бац!

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

Спасибо, что разъяснили! И правда - зачем ПО отлаживать? Ведь надо просто не делать багов!


Попробуйте как нить запустить отладчик, запустить программу, а потом в произвольной функции остановить выполнение и переместить PC на команду BX LR и продолжить выполнение кода. Увидите что будет, теоретик Вы наш.


Да ужжж.... больше нет слов. Остаётся только посочувствовать пользователям ваших девайсов.....

У меня не виснет, можете не сочувствовать. Раньше висло, бывало. В последний раз в попытке усовершенствовать выскочила потенциальная вероятность деления на ноль. Исправил. Теперь никто не жалуется. А если что - прошивку можно обновить через загрузчик. Но никто не обращался.


А вы на флаг поглядывайте, был HF или нет. И в зависимости от меняйте поведение функций.

Что за флаг? И как менять поведение?

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

Вы что-ж предлагаете в memcpy() перед копированием каждого байта этот десяток флагов проверять???
Ааа!... Понял - это просто троллинг!

Я же писал, предлагаю подумать над. А то всё сброс да сброс. Скучно.
Мой HardFault обработчик состоит из двух ассемблерных команд. И ничего, прибор работает не хуже других.

Первый совет у любой техподдержки - выключите устройство и опять включите. :-)

Сообщение отредактировал serglg - Jul 10 2018, 14:27

Ребят, а что try except finally - запрещены?

В try сохраняете SP в SEH-стек при Faults SP восстанавливается из этого стека.

Переполнение стека вообще неплохо отлавливается статическим анализатором. А для редких случаев как уже говорили надо контролировать периодической проверкой.


Где-то я видел требование считать memcpy() - безопасной функцией. Просто иначе не получается доказать безопасность кода(доказательная безопасность). Но как по мне она небезопасна, но ведь достаточно перед ней поставить проверку и все дела. А если у вас есть вероятность отказа памяти, то как тут верно заметили есть дублирующий код который другим методом делает.

Частичный отказ памяти маловероятен. А если он произойдёт то тут только дублирование железа поможет.
Вероятность того, что память закончится отметается нагрузочным тестированием. А если при работе произойдёт, то используем стек прерывания/ядра сохраняем код ошибки в SD и перезагружаем устройство. При загрузки анализируем предыдущий отказ.

Сообщение отредактировал Pavia - Jul 10 2018, 15:12

Мой обработчик HardFault состоит из диагностического вывода в консоль содержимого регистров. Взят на просторах инета. Плюс к этому блокируются все прерывания, и через некоторое время прибор перезагружается по собаке. Событие пишется в журнал, но лишь как HARDFAULT_EVENT". В журнал уже не кладу никакой другой полезной информации. Полагаю, что на этапе отладки нужно минимизировать вероятность этого события. А если на объекте появится, то... ну что поделать) Попробовать воспроизвести у себя. Поэтому расчёт на пса, и собственные силы в отладке.

Продолжать работу после hard faulta не считаю разумным, т.к. причин этого явления может быть несколько разных. Например, невыровнный доступ к памяти. И что с этим делать? Если это правится в исходниках, там и нужно поправить. Если это "случайная" ситуация, зависиящая от внешней среды... то тоже исходники править, только больше алгоритмически. Или улетели с нулевого указателя? И вот что с этим делать? Прибор не может работать, не обратившись к нужной функции. Значит его нужно перзапускать, что и делает собака.

Как правило, приборы, особенно построенные на МК без MMU - не компы. Операционных систем, которые берут на себя весь процесс восстановления и защиты экосистемы, там нет. Писать это и тестировать самому - не одного ежа можно родить) А если только MPU? Или у нас Cortex-M0 без оного? Считаю, что лог + перезапуск самое то)

Не факт, что будет легко воспроизвести на столе. Лучше добавить в лог хотя бы содержимое регистров и адрес события.