[aaarrr 63]

И к выходу из функции. LR

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

[ViKo 1]

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

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

[aaarrr 63]

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

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

[ViKo 1]

Главное ведь, не перезагружаться - то каждый может :biggrin:

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

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

[Arlleex 131]

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

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

[jcxz 184]

А вы контролируйте стек периодически, чтобы не переполнялся. :rolleyes:

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

 

И к выходу из функции. LR

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

 

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

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

[ViKo 1]

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

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

 

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

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

[jcxz 184]

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

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

[ViKo 1]

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

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

[jcxz 184]

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

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

Ааа!... Понял - это просто троллинг! :biggrin:

[ViKo 1]

Ааа!... Понял - это просто троллинг! :biggrin:

Я же писал, предлагаю подумать над. А то всё сброс да сброс. Скучно.

Мой HardFault обработчик состоит из двух ассемблерных команд. И ничего, прибор работает не хуже других. :laughing:

[serglg 0]

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

 

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

Изменено 10 июля, 2018 пользователем serglg

[Pavia 0]

Можно. Но восстановить историю использования SP в функции - нет. Соответственно, и выйти из функции не получится, только вернуться к точке сбоя.

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

 

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

 

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

 

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

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

 

Частичный отказ памяти маловероятен. А если он произойдёт то тут только дублирование железа поможет.

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

Изменено 10 июля, 2018 пользователем Pavia

[haker_fox 60]

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

 

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

 

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

[aaarrr 63]

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

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