Обработка Faults на Cortex-Mx, Как используете? Опции

[Arlleex]

Интересует, как коллеги обрабатывают все Faults на микроконтроллерах Cortex-Mx.
Я про NMI, Hard, MemManage, Bus, Usage, SVCall, Debug Monitor, PendSV, Systick.
С SVCall, Debug Monitor, Systick все понятно, с PendSV в принципе тоже.

А что делаете с тяжелыми отказами, отказами шины и прочими? Сейчас я просто вывожу состояние нужных регистров и стек. Как правило, если где-то программа падает, я узнаю об этом на этапе отладки. Но ведь может быть такое, что устройство уже стоит у заказчика и частично подлежит отладке на объектах. И оно должно продолжить функционирование. Как обрабатывать тогда ошибки? Перезагрузка по WDT? Или все-таки грамотный обработчик исключения должен понять природу ошибки и попытаться исправить ее? Если да, то каким образом? Сейчас мне видится вариант с сохранением лога событий в памяти (допустим, SD карты) и перезагрузкой МК. Пока что больше хорошего развития событий не знаю. Отсюда и предположения для обсуждения:
1. Должны ли существовать обработчики исключения CPU, связанные с аварийным событием (промах по памяти, тяжелый отказ, например, и т.д.) только на момент разработки и отладки ПО и выявлять все проблемы именно на этапе разработки, а при этом в боевой работе устройство ни коим образом не должно ловить такие Fault-ы?
2. Пункт 1 влечет за собой следующий вопрос: если в боевом коде обработчики должны быть предусмотрены (я подразумеваю, что все-таки это именно так) - как правильно строить архитектуру обработки ошибок? Что должен делать код в обработчике, кроме как сообщать программисту (каким-то образом) о состоянии регистров?
3. Вопрос больше из разряда "как больше нравится" - код обработчика на ассемблере или на Си?
То есть, как вы поняли, вопрос в грамотном управлении ходом событий для обеспечения надежности и безотказности устройства.

Я задаю себе вслух вопрос: "причину отказа я установлю, но что мне с этим делать дальше?".
Вопрос не философский и хотелось бы узнать, как коллеги на реальной практике применяют обработчики исключений CPU для обеспечения надежности ПО и устройства в целом от сбоев. Только прошу, не хотелось бы услышать ответ "на столе отлаживать надо". Мы отлаживаем. И работает годами. Но бывают (уверен, у всех) непредвиденные случаи, когда устройство может "выстрелить себе в колено", не важно по вашей вине или вине заказчика, и нужно с этим разбираться.
Также был бы благодарен, если на эту тему существуют мануалы, но я об этом не знаю - будьте добры, поделитесь информацией

Сообщение отредактировал Arlleex - Jul 7 2018, 15:42

[aaarrr]

По-моему, так:
1. Должны быть и в релизе.
2. Регистры процессора, Fault Status'ы, содержимое стека сохранить в памяти, перезапустить процессор и
записать/отправить оповещение в штатном режиме.
3. Можно обойтись без ассемблера, это уже дело вкуса.

[ViKo]

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

[aaarrr]

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

1. Каким образом выйти?
2. А если дальше все пойдет еще хуже?

Безопаснее рестартовать, сохранив информацию о сбое.

[ViKo]

2. А если дальше все пойдет еще хуже?
Безопаснее рестартовать, сохранив информацию о сбое.

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

[jcxz]

А что делаете с тяжелыми отказами, отказами шины и прочими?

Определил для себя понятие "критическая ошибка". Это такая ошибка, возникновение которой не предусмотрено при создании программы, неизвестно "что делать?" при её возникновении и невозможно продолжать штатное функционирование устройства.
Такие ошибки у меня могут возбуждаться как аппаратными событиями (исключение от MPU при попытке недопустимого доступа к памяти, всяческие прочие HF (и Bus fault-ы и user fault-ы - для всех у меня делается эскалация до Hard Fault с общим обработчиком HF)); так могут вызываться и программно (набор функций trap(...)) если какая-то часть программы обнаружила недопустимое состояние (для каждого программного модуля/драйвера - свой класс возбуждаемых trap-ов). Обработчик trap() у меня висит на SVC.
При возникновении любого типа критической ошибки я делаю:
Защёлкиваю тип и ID критической ошибки состояние выполнения (регистры CPU, N слов от вершины стека), для программного trap() также защёлкиваю аргументы вызова. Для некоторых типов критических ошибок (например: неожиданное прерывание (которого не должно быть)) защёлкиваю состояние выполнения (регистры/стек) не текущего контекста, а прерванного. Далее - делаю базовый инит (выкл. всей периферии, останов DMA, инит базовой периферии - MPU и пр.) и дальше - в зависимости от состояния соответствующего ключа компиляции:
1) компиляция DEBUG: переход устройства в спец.режим "TRAP" - инит тактирования (PLL и пр.) для этого режима (минимальные частоты), инит отладочного UART, и циклический, раз в секунду, вывод "синего экрана смерти" - периодический дамп всех защёлкнутых данных в UART в текстовом виде; устройство находится в режиме TRAP до внешнего сброса/выкл. питания, обеспечивая фиксацию состояния ошибки.
2) компиляция RELEASE: аппаратный reset устройства.
И для того и для другого случая, копирую защёлкнутую инфу в спец. область памяти, которая не будет стёрта при reset-е, снабжаю её флагом и CRC. И, если устройство имеет non-volatile память, то после штатного рестарта, после начального инита периферии, эта инфа переписывается в журнал критических сбоев в этой non-volatile памяти.

Но ведь может быть такое, что устройство уже стоит у заказчика и частично подлежит отладке на объектах. И оно должно продолжить функционирование. Как обрабатывать тогда ошибки?

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

Сейчас мне видится вариант с сохранением лога событий в памяти (допустим, SD карты) и перезагрузкой МК.

В момент ошибки у Вас устройство уже работает, куча разной периферии/DMA работают, и если при этом произошла ошибка, то в этом окружении уже опасно дальше что-то делать, иначе можно получить каскад таких сбоев. Лучше просто защёлкнуть как можно быстрее инфу об ошибке в ОЗУ и сделать начальный инит периферии к минимальному функциональному состоянию - минимуму работающей периферии необходимой для записи события ошибки в какую-то энергонезависимую память, и записать эту инфу. А уж после рестартовать опять систему к полной функциональности.

в боевой работе устройство ни коим образом не должно ловить такие Fault-ы?

Фиксация и отработка сбоев должна быть и в боевом режиме.

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

У меня у обработчик общий, но имеет два входа: для программного возбуждения сбоя (trap()) и для аппаратного возбуждения сбоя (все типы fault-ов).

3. Вопрос больше из разряда "как больше нравится" - код обработчика на ассемблере или на Си?

Защёлкивание всей инфы (регистры, стек, состояние CPU и пр.) у меня на асме, а "синий экран смерти" (режим работы TRAP) - на си.

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

Если есть инфа, что где-то на объекте что-то сбоит, смотрим журнал критических ошибок устройства на объекте - их частота, кол-во, периодичность, какие типы и в каких местах программы и пр. Дальше смотрим листинги этой версии ПО, пытаемся воспроизвести ситуацию у себя на столе. Если не получается - снимаем сбоящее устройство и везём к себе.
Как-то так.

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

Если причина сбоя неизвестна (а она неизвестна по определению, иначе - почему тогда Вы его не исправили ещё на этапе написания ПО? то не то что продолжать работу дальше нельзя, можно даже просто не успеть и выйти и получить тут же следующий сбой. А может сбой уже разрушил память или нарушил взаимодействие с какой-то периферией и устройство уже не функционирует, а глючит?

[aaarrr]

Так же и сброс не всегда можно допустить, мало ли, какой процесс обслуживается.

Вы так и не рассказали, как собираетесь выбираться из fault'а.
"Мало ли какие процессы" должны контролироваться аппаратно и/или безболезненно переживать сброс.

[jcxz]

Вы так и не рассказали, как собираетесь выбираться из fault'а.

Типа как известный персонаж:

[aaarrr]

Типа как известный персонаж...

Так оно в ряде случаев вполне возможно - вон, на ARM7 так предлагали виртуальную память строить. Но прозвучало предложение "выйти из той функции", что уже действительно на грани фантастики.

[jcxz]

Так оно в ряде случаев вполне возможно - вон, на ARM7 так предлагали виртуальную память строить.

Ну так fault при доступе в несуществующую память, по которому соответствующий драйвер делает переназначение страниц памяти (или ещё каким образом делает подкачку из внешнего пула) - это штатная работа диспетчера виртуальной памяти, коли таковой есть. А ТС спрашивает о критических ошибках, т.е. - событиях не предусмотренных заранее при разработке ПО.
Это может даже на одном векторе висеть, а далее эти случаи должны разделяться программно.

[Arlleex]

Спасибо участникам обсуждения!
Примерно так я себе это и представлял, на самом-то деле. Однако предполагал, что существует некий сводный "мануал-ритуал", в котором жесткими канонами высечены такие правила

2) компиляция RELEASE: аппаратный reset устройства.
И для того и для другого случая, копирую защёлкнутую инфу в спец. область памяти, которая не будет стёрта при reset-е, снабжаю её флагом и CRC. И, если устройство имеет non-volatile память, то после штатного рестарта, после начального инита периферии, эта инфа переписывается в журнал критических сбоев в этой non-volatile памяти.

Ну то есть по сути в начале main()-а у Вас можно увидеть что-то наподобие:

Код

int main(void)
{
    if(GetCriticalErrorStatus() == ERROR_OCCURRED)
        WriteInfoAboutError();

    ...
}

где GetCriticalErrorStatus() - функция, которая читает флаг в ОЗУ, установленный trap()-ом или обработчиком HF. Верно?

P.S. И еще один вопрос. Если необходимо логгирование на SD-карту памяти, например. Есть ли предпочтение наличию файловой системы или безразлично? Сейчас использую с файловой системой, однако приходится держать файл открытым и через некоторое время сохранять. Но питание могут выключить в произвольное время. Так может потеряться информация о файле, поэтому я делаю дублирование файлов, и это выглядит костылем. Какие изящные программные способы логгирования вы применяете?

[jcxz]

где GetCriticalErrorStatus() - функция, которая читает флаг в ОЗУ, установленный trap()-ом или обработчиком HF. Верно?

Да. Читает и очищает.

Какие изящные программные способы логгирования вы применяете?

Лучше логи писать в журналы (без ФС) - оно как бы органически под это дело и подходит. Я так и делаю. Журнал у меня - это некая FIFO-структура во FLASH/FRAM, с размером элементов обычно кратным целому числу блоков записи (хотя это не обязательно). Каждый такой элемент - одна запись журнала (на одно событие). При старте ПО выполняется монтирование каждого журнала: поиск "головы", определение числа записей, проверка их валидности и т.п.
Хотя можно сделать устойчивую к сбоям свою ФС. Но это избыточно, так как ФС нужна для возможности произвольного доступа к файлам, что налагает значительные сложности в реализации. Но произвольный доступ не нужен для журналов, а значит - избыточен.

Так может потеряться информация о файле, поэтому я делаю дублирование файлов, и это выглядит костылем.

Так даже с дублированием инфа может потеряться. Ведь обычно в файловой системе при обновлении файла происходит неатомарная модификация разных областей на носителе. Вследствие чего могут возникнуть ошибки в FAT или записи каталога, которые приведут не только к порче записываемого в данный момент файла, но и других файлов (всякие cross-links and etc.).

[Arlleex]

Лучше логи писать в журналы (без ФС) - оно как бы органически под это дело и подходит. Я так и делаю. Журнал у меня - это некая FIFO-структура во FLASH/FRAM, с размером элементов обычно кратным целому числу блоков записи (хотя это не обязательно). Каждый такой элемент - одна запись журнала (на одно событие). При старте ПО выполняется монтирование каждого журнала: поиск "головы", определение числа записей, проверка их валидности и т.п.
...

Обобщая, я пришел к выводу, что двигаюсь в правильном направлении. Думаю, больше вопросов в этом плане не возникнет не должно возникнуть, спасибо большое

[aaarrr]

Если необходимо логгирование на SD-карту памяти, например. Есть ли предпочтение наличию файловой системы или безразлично? ...Но питание могут выключить в произвольное время.

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

[jcxz]

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

Вообще-то вероятность зависит от условий эксплуатации устройства автора. Вы откуда знаете какова у него вероятность?
А если у него при подаче питания на устройство, возможен дребезг контактов? При таком включении устройство может многократно включиться/выключиться.
Или например: пришла помеха - пачка импульсов (даже испытания на помехоустойчивость проводят пачкой импульсов) - тогда устройство многократно перезагрузится.
А теперь представьте, что у него в устройстве есть журнал включений/выключений, в который устройство должно писать инфу о включениях (сразу после вкл. питания). Какова будет вероятность попадания такого рестарта на момент записи? А если таких устройств у заказчика работает тысячи и работают они режиме 24/7? Как часто в такой системе будут происходить сбои ФС с потерями данных?

ФС нужна только если эту SD должны вынимать вставлять ещё куда-то (комп, etc.). Если нет и работа с SD производится только самим устройством, то ничто не мешает ему представить некий объект на SD (FIFO-журнал из секторов) как файл через свой внешний интерфейс. Даже хранить в таком журнале записи в бинарном виде (как удобнее для работы с ними), а выдавать пользователю через внешний интерфейс в текстовом виде (printf никто не отменял).
Я именно так и делал. Хранить удобнее бинарные записи (размер меньше, размер фиксированный), а при выдаче вовне переводить их в текст на лету.

[ViKo]

Так оно в ряде случаев вполне возможно - вон, на ARM7 так предлагали виртуальную память строить. Но прозвучало предложение "выйти из той функции", что уже действительно на грани фантастики.

Так PC и LR во время падения в HF сохраняются в стеке. Вот за них и потянуть. Можно просто выйти из HF и продолжить, как ни в чем не бывало.
Я не настаиваю. Предлагаю подумать.
Можно задачу удалить в РТОС, а потом снова создать.
А сбросить МК любой умеет.

[aaarrr]

Так PC и LR во время падения в HF сохраняются в стеке. Вот за них и потянуть.

А где сохраняется SP?

Можно просто выйти из HF и продолжить, как ни в чем не бывало.

Можно, но нужно или устранить причину fault'а, или привести ПО в безопасное состояние.

Вообще-то вероятность зависит...

Вообще-то я говорил о вероятности совпадения двух событий разной природы.

ФС нужна только если эту SD должны вынимать вставлять ещё куда-то (комп, etc.).

Если карту не предполагается вынимать, то и сама карта вроде бы ни к чему, нет?

Хранить удобнее бинарные записи (размер меньше, размер фиксированный)

Размер смущать в наше время не должен, а вот возможность непосредственного чтения человеком и гибкость формата являются преимуществом.

[Arlleex]

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

В этом, безусловно, огромный плюс... И это имеет смысл (в моем случае) для устройств, которые стоят на объектах и которые имеют возможность эту карту вытащить. Но есть и устройства, из которых SD-карта не вынимается, а стоит на плате жестко (припаяна или в слоте). В таком случае файлы .info выкачиваются по доступному интерфейсу и могут расшифровываться "налету". Сейчас же все-таки все равно сделано в текстовом виде и с файловой системой, гоню по Ethernet при выкачке на комп (кстати, вот как раз jcxz об этом и говорит как раз).
Кстати а можно ли каким-то образом сказать файловой системе (FatFS), что я часть карты использую для сырых данных (с такого-то по такой-то адрес), а остальную область она может использовать для себя? Грубо говоря, организовать ФС на карте и, одновременно, иметь возможность писать сырые данные в отведенную область (скажем, некая аналогия с разлиновкой памяти для МК)?

Вообще-то вероятность зависит от условий эксплуатации устройства автора. Вы откуда знаете какова у него вероятность?

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

ViKo, из Fault-обработчика то Вы выберетесь, элементарно ж. Но вот из функции, вызвавшей ошибку, находясь в прерывании, Вы не выйдете. Иначе надо знать размер каждой функции в памяти и состояние стека. Это не представляется возможным. Ваш подход насчет подумать "налету", не перезагружая процессор, был описан jcxz как некритическая ошибка, которую можно разрулить. Однако, если ПО довольно сложное и в нем крутится салат из многопоточных DMA, пересылок, обменов и т.д., выкрутиться из такой ситуации очень сложно (если не возможно вовсе) не затронув последствия такого разруливания. Ведь действительно, все может стать еще хуже: в реал-тайме полетит времянка из-за вовремя не остановленных процессов и т.д. Проще сбросить и начать сначала, с белого листа, указав разработчику на ошибку записью в какой-нибудь энергонезависимый накопитель Со временем такие ошибки минимизируются к 0, останутся только некритические ошибки, которые, как раз, как и Вы предлагаете, исправляются "on fly".

[ViKo]

А где сохраняется SP?

А он (они) не портится. Нужно только определить, который из них использовался перед улетом, и далее из стека извлекается всё нужное и ненужное. Если, конечно, не напортачить с выделением стека изначально.

[aaarrr]

Кстати а можно ли каким-то образом сказать файловой системе (FatFS), что я часть карты использую для сырых данных (с такого-то по такой-то адрес), а остальную область она может использовать для себя?

Если FatFS умеет работать с разделами, то почему бы и нет?

Да вот конкретно сейчас бытовой пример - у меня устройство настольное, не серийное, а некий макет для людей. Им пользуются в течение дня и вечером выключат питание. И так каждый рабочий день.

На макете можно и sync после каждой записи делать.

А он (они) не портится.

Да ну? То есть в произвольной точке функции Вы ожидаете увидеть то же значение SP, что и на входе?

[jcxz]

Размер смущать в наше время не должен, а вот возможность непосредственного чтения человеком и гибкость формата являются преимуществом.

Пока не изобрели МК с бесконечной памятью, он будет смущать.
Да и: скорость_записи=f(размер_записи).

[ViKo]

Да ну? То есть в произвольной точке функции Вы ожидаете увидеть то же значение SP, что и на входе?

Заваливаясь в HF, я всегда буду на вершине стека, относительно которой и находятся регистры PC, LR. То есть, я могу сохранить состояние ошибки, задать некий флаг ошибки и выйти из функции, используя сохраненный LR. Если внутри функции используется стек, тогда не знаю.

[aaarrr]

Пока не изобрела МК с бесконечной памятью, он будет смущать.
Да и: скорость_записи=f(размера_записи).

Размер типичной записи в лог - десятки байт-килобайты. Это явно не тот случай, когда экономия имеет смысл.
Вот если нужно в 24C04 лог писать - тогда другое дело

[jcxz]

В этом, безусловно, огромный плюс... И это имеет смысл (в моем случае) для устройств, которые стоят на объектах и которые имеют возможность эту карту вытащить.

Даже в этом случае имхо - надёжнее организовать журналы как я описывал. Просто дублировать их ещё и в ФС. Основное место хранения при этом - FIFO, а при старте ПО и при каждом обновлении FIFO-журнала ПО просто должно синхронизировать файлы по содержимому FIFO-журнала: удалять ненужные, или создавать отсутствующие (удалённые как сбойные при старте ПО и ремонте ФС).

Грубо говоря, организовать ФС на карте и, одновременно, иметь возможность писать сырые данные в отведенную область (скажем, некая аналогия с разлиновкой памяти для МК)?

Ну никто-ж Вам не мешает на этой SD ограничить размер раздела каким-то объёмом, а остальное место использовать для посекторного доступа. Фэйковые флешки с али, на которых написано 512 гиг, а по факту они - 8 гиг именно так и ремонтируются: раздел урезается до реальной ёмкости и всё. У меня несколько таких халявных флешек, работающих уже не один год

[aaarrr]

Если внутри функции используется стек, тогда не знаю.

Так о том и речь.

[ViKo]

Так о том и речь.

По моему, регистры в стек заносятся непосредственно при улете в HF. То есть, определить PC и LR и еще кучу регистров можно точно.

[jcxz]

То есть, я могу сохранить состояние ошибки, задать некий флаг ошибки и выйти из функции, используя сохраненный LR. Если внутри функции используется стек, тогда не знаю.

А какой толк-то? Вот у Вас произошло переполнение стека к примеру, в результате - разрушился счётчик цикла там хранившийся, потом по этому счётчику цикла производится цикл записи в память. В результате счётчик вместо скажем 10, стал равен 0xFFFFFFF и запись в память будет идти пока не дойдёт до границ региона, разрешённого для записи в MPU и не вызовется fault. И что - сохраните Вы ошибку и вернётесь куда - в полностью разрушенную программу (вся ОЗУ стёрта)? И что получите? Что устройство вылетит в следующий fault, и следующий и т.д.? И в результате потом даже неясно будет первоначальная точка fault-а? А может в очередной раз не вылетит в fault, а просто тупо повиснет - так лучше?
А в это время скажем какая-то нагрузка (которая в штатном режиме работы ПО устройства управляется ШИМ-ом) начинает поджариваться, так как силовой ключ остался во вкл. положении надолго, вместо перезапуска ПО и перевода всего и вся в безопасное положение.

[ViKo]

А какой толк-то? Вот у Вас произошло переполнение стека к примеру
...
вместо перезапуска ПО и перевода всего и вся в безопасное положение.

А вы контролируйте стек периодически, чтобы не переполнялся.
А если у вас манипулятор переместился в крайнее положение и произошел сбой, то вам непременно нужно махнуть им в исходное положение в непредсказуемый момент времени (сброс), а не замереть?

[aaarrr]

По моему, регистры в стек заносятся непосредственно при улете в HF. То есть, определить PC и LR и еще кучу регистров можно точно.

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

А если у вас манипулятор переместился в крайнее положение и произошел сбой, то вам непременно нужно махнуть им в исходное положение в непредсказуемый момент времени (сброс), а не замереть?

А не нужно дергать манипуляторами по аварийному сбросу.

[ViKo]

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

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

[aaarrr]

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

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

[ViKo]

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

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

[aaarrr]

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

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

[ViKo]

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

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

[Arlleex]

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

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

[jcxz]

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

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

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

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

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

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

[ViKo]

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

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

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

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

[jcxz]

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

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

[ViKo]

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

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

[jcxz]

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

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

[ViKo]

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

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

[serglg]

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

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

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

[Pavia]

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

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

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

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

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

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

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

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

[haker_fox]

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

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

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

[aaarrr]

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

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

[ViKo]

Значит его нужно перзапускать, что и делает собака.

Есть не один способ сбросить МК без собаки. Зачем ждать, пока собака проснется?

[Arlleex]

А если на объекте появится, то... ну что поделать) Попробовать воспроизвести у себя.

Я еще понимаю, если устройство является технологическим (вспомогательным) и его отказ не оказывает влияния на всю систему.
А если этот ваш МК стоит на приводе управления тормозами поезда? А если в самолете? А если в дозаторе рентген-излучателя в медицине? Вам же хотелось бы быть уверенным, что не получите 100-кратную дозу при снятии рентгена грудной клетки? Вот и мне хотелось бы. Да куча примеров, в общем-то - думаю понимаете, к чему я веду. И даже из каждого недопустимого поведения устройства нужно делать выводы. И чем больше исходных данных - тем вкуснее пища для размышлений.
Насчет сторожевой собаки в данном конкретном случае - мне кажется это лишнее. Хотя кому как. Мне проще NVIC попросить сбросить МК сразу

Сообщение отредактировал Arlleex - Jul 11 2018, 11:54

[haker_fox]

А если в самолете?

Не переживайте так, я тоже озаботился этим вопросом Именно поэтому я развил тему авионики начиная отсюда, и тут.

[AlexandrY]

Интересует, как коллеги обрабатывают все Faults на микроконтроллерах Cortex-Mx.
Я про NMI, Hard, MemManage, Bus, Usage, SVCall, Debug Monitor, PendSV, Systick.
С SVCall, Debug Monitor, Systick все понятно, с PendSV в принципе тоже.

Ловить HardFault-ы в релизе во время эксплуатации нет особого смысла.
Слишком много информации надо зафиксировать о контексте события, слишком обременительно хранить историю версий и парсить многомегабайтные логи.
Лучше их выловить отладочным адаптером заранее.
Поскольку такие проблемы чаще всего из-за специфичной периферии SoC-а и происходят во время ее исследований.
Либо по причине некачественного интерфейса к внешней памяти.
Но тут надо не HardFault-ы ловить, а гонять разнообразные тесты.
Помню случай когда ошибка c DDR вылезала у меня только когда компилер генерил STM инструкцию с сохранением более 7 им регистров в определенной последовательности и никак иначе.
Это вызывало самые причудливые Hard Fault-ы всех сортов.
Никакие логи и дампы регистров и стека не помогали. После каждой смены опций компиляции картина ошибок менялась.

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

[haker_fox]

Я еще понимаю, если устройство является технологическим (вспомогательным) и его отказ не оказывает влияния на всю систему.
А если этот ваш МК стоит на приводе управления тормозами поезда? А если в самолете? А если в дозаторе рентген-излучателя в медицине?

И я вас уверяю, что если даже ваш контроллер протестирован ни на один раз, у вас небыло зависаний и выпадений в hf, никто в единственном экземпляре не поставит его на тормоза поезда, или в дозатор. Как минимум сдублируют. Хотя, может быть исключения и есть.

[AlexandrY]

И я вас уверяю, что если даже ваш контроллер протестирован ни на один раз, у вас небыло зависаний и выпадений в hf, никто в единственном экземпляре не поставит его на тормоза поезда, или в дозатор. Как минимум сдублируют. Хотя, может быть исключения и есть.

Только хочу уточнить, что тестирование делается перед каждым включением двигателя, актуатора или еще чего.
Тестируются все критичные области RAM-а и все объекты RTOS, включая сервисы как менеджер памяти, межпроцессорный обмен и т.д.
Тестирование всего этого также повторяется с заданной периодичностью, хоть и раз в 10 мс.

[haker_fox]

Лучше их выловить отладочным адаптером заранее.

Но как? Вот сегодня у меня. LPC4337. FreeRTOS. 12 задач. Снаружи 4 АЦП, память SDRAM, дисплей, ethernet, rs-485, реле и прочая дребедень, свойственная промышленному контроллеру. Периодически, один раз на 10 одинаковых событий вылетает hardfault, либо портится память в произвольной задаче (структуры данных в классе). Вот как искать? MPU? Но ему же закалебёшься объяснять, какая память какой задаче принадлежит. Ловушка переполнения стека в оси не срабатывает. Call Stack ничего полезного мне не даёт, либо я не умею читать между строк. В итоге я полдня сидели и комментировал задачи, пришёл к работоспособному варианту, и методом научного тыка разобрался, что вызывало ошибку. А это было у меня под носом. Но
пока пришёл к этому, затратил немало времени.

Только хочу уточнить, что тестирование делается перед каждым включением двигателя, актуатора или еще чего.
Тестируются все критичные области RAM-а и все объекты RTOS, включая сервисы как менеджер памяти, межпроцессорный обмен и т.д.
Тестирование всего этого также повторяется с заданной периодичностью, хоть и раз в 10 мс.

Сигнатуры в ОЗУ? Тестовые блоки с CRC? Не представляю, как можно тестировать менеджер памяти, межпроцессный обмен. Вы, как я понимаю, подобным занимаетесь. Может быть напишите нам подробнее эти тонкости, если они не затронут ноу-хау. Просто иногда хочется лбом об стенку биться, ибо не знаешь, где искать)))

[AlexandrY]

Периодически, один раз на 10 одинаковых событий вылетает hardfault, либо портится память в произвольной задаче (структуры данных в классе). Вот как искать?

Как правильно ловить hardfault-ы - https://www.iar.com/support/tech-notes/debu...lt-on-cortex-m/

Сигнатуры в ОЗУ? Тестовые блоки с CRC? Не представляю, как можно тестировать менеджер памяти, межпроцессный обмен. Вы, как я понимаю, подобным занимаетесь. Может быть напишите нам подробнее эти тонкости, если они не затронут ноу-хау. Просто иногда хочется лбом об стенку биться, ибо не знаешь, где искать)))

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

[Pavia]

Но как? Вот сегодня у меня. LPC4337. FreeRTOS. 12 задач. Снаружи 4 АЦП, память SDRAM, дисплей, ethernet, rs-485, реле и прочая дребедень, свойственная промышленному контроллеру. Периодически, один раз на 10 одинаковых событий вылетает hardfault, либо портится память в произвольной задаче (структуры данных в классе). Вот как искать? MPU? Но ему же закалебёшься объяснять, какая память какой задаче принадлежит.

Всё просто, но закалебёшься. Берём и пишем Unit-тесты на все случае жизни. Должны быть данные и проверочный-код который зайдёт во все ветки кода. Ошероув Рой.-Искусство автономного тестирования.
А по мимо автономной проверок ещё и внутренние делаются.
Проверка данных по входу обязательна для всех внешних систем.

Внутри задачи память линейна, так что проверку памяти можно туда вставить.

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

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

Я вот что думаю можно сделать так. Один раз пишется небольшая утилита которая внутрь каждой функции добавляет вывод в лог. И так же убирает.
Место вставки элементарно подсчетом скобок определяется. Только для каждого класса надо будет добавить GetDebugString

[Kabdim]

Всё просто, но закалебёшься.

И всё сломается на первом же забежавшем быстрым нейтроном.

[AlexandrY]

Ошероув Рой.-Искусство автономного тестирования.

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

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

[jcxz]

А если только MPU? Или у нас Cortex-M0 без оного?

Расчудесная и многими любимая фирма STMicroelectronics даже некоторые МК на Cortex-M3 умудряется делать без MPU. Видимо заботится о юзерах - чтоб мозги не перенапрягли, разбираясь в нём.

Есть не один способ сбросить МК без собаки. Зачем ждать, пока собака проснется?

Да знаем мы уже Ваш способ! этот способ - юзер с большим рубильником

А если этот ваш МК стоит на приводе управления тормозами поезда? А если в самолете?

...то их (девайсов) должно быть как минимум 4-ро. Если один вздумал вольнодумничать - 3 других дадут ему по шее, так чтоб перезагрузился. А если пойдут 2 на 2, то попросят помощи у машиниста/пилота.

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

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

Тестирование всего этого также повторяется с заданной периодичностью, хоть и раз в 10 мс.

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

MPU? Но ему же закалебёшься объяснять, какая память какой задаче принадлежит.

Вообще - это возможно. Если каждая задача работает только со своими переменными.
Собираем эти переменные в свои регионы памяти: для каждой задачи - отдельный регион, куда линкуются только её переменные; в хуке переключателя контекста (в uCOS такой уже есть, но если и нет - можно просто вставить в имеющийся переключатель) при переключении на какую-то задачу закрываем всю память от записи (или вообще любого доступа) кроме региона этой задачи.
Но так редко бывает, чтобы задача работала только со своими переменными без взаимодействия с другими задачами. Хотя тут тоже есть варианты.
А изначально Вам следовало определить причину HF. И от неё уже танцевать.
Конечно бывает, что HF вызывает вторичная причина (первичная просто разрушила чью-то память не вызвав HF, а когда пользователь этих данных полез к ним, то у него и случился HF). Тут уже сложнее. Но тоже есть варианты решений.

Место вставки элементарно подсчетом скобок определяется. Только для каждого класса надо будет добавить GetDebugString

Набежали, блин, PC-теоретики....

Замедление разработки в ответственных системах скорее всего даже полезно.

Да я тоже считаю что лучше 5 раз сходить на кофе-паузу чем 2!!! Ведь чем меньше времени программист проводит за клавиатурой, тем меньше у него времени плодить баги!
На прошлой работе у меня был коллега, так он так начальству и говорил: "Вот я сейчас лишние полчаса просидел в кафе, так я же это с целью ускорить разработку - иначе бы за это время успел написать баг, но поиски которого пришлось бы потратить несколько дней. А так - выпил лишнюю чашку кофе - и ускорил проект на несколько дней!"

[Arlleex]

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

А вот тут, пожалуйста, поподробнее. Интересно как ловятся такие эскалационные баги В терминологии ARM, нсколько я помню, это называется "не точный отказ" (not exact fault).

[haker_fox]

Расчудесная и многими любимая фирма STMicroelectronics даже некоторые МК на Cortex-M3 умудряется делать без MPU. Видимо заботится о юзерах - чтоб мозги не перенапрягли, разбираясь в нём.

Не работал с их МК старше Cortex-M0. А STM32F051 и подобные мне очень нравятся из-за богатых аппаратных возможнстей (система триггеров и передачи сигналов на запуск периферии). На "ура" на них делал источники тока с обратными связями, с многофазной системой синхронизации и т.п. Один из источников полностью программный. Т.е. связка таймер-ПДП-АЦП рулит ШИМ и обеспечивает цифровой ПИД-регулятор.

...то их (девайсов) должно быть как минимум 4-ро. Если один вздумал вольнодумничать - 3 других дадут ему по шее, так чтоб перезагрузился. А если пойдут 2 на 2, то попросят помощи у машиниста/пилота.

Угу. Смотрим на схемы Aribus A320, Boeing 7x7 как самые доступные в инете. Впечатляемся, и идём читать настоящие книжки)

А вот тут, пожалуйста, поподробнее. Интересно как ловятся такие эскалационные баги В терминологии ARM, нсколько я помню, это называется "не точный отказ" (not exact fault).

+1, тоже интересно. А ведь может быть и три таких ступени)

[jcxz]

А вот тут, пожалуйста, поподробнее. Интересно как ловятся такие эскалационные баги В терминологии ARM, нсколько я помню, это называется "не точный отказ" (not exact fault).

Вы не поняли. Я тут вовсе не говорил про эскалацию fault-ов. Баг не обязательно приводит к fault-у. Ну затёрла одна функция данные другой - с чего это может вызвать fault? А вот когда уже вторая функция начнёт пользоваться этими разрушенными данными, то может получиться fault. А может и не получиться, а порушатся данные третьей функции. И так далее. И когда это может привести к fault-у (а может и нет).
И вот - в конце концов получили этот fault, определили что он возник из-за того что в какой-то функции какие-то данные приняли недопустимое значение. Начинаем разбираться, а судя по коду - ну не может быть таких значений у этой функции. А всё потому что - это не первичный сбой. А первичную причину в таком случае установить уже гораздо сложнее, чем если бы первичная причина сразу вызвала fault.

А эскалация - это когда к примеру у Вас запрещён BusFault, но происходит причина его вызывающая и, так как он запрещён, то происходит эскалация до HF. У меня обработка всех fault-ов построена на эскалации до HF - так проще, чем писать кучу обработчиков с одинаковыми действиями. В ISR HF по регистрам всегда можно определить первоначальный источник, до эскалации.

И "неточный отказ" не имеет никакого отношения к эскалации. Это просто один из видов отказов по вектору BusFault. Неточный - это значит, что регистр адреса отказа не содержит точного адреса отказа. Например - из-за кеширования. Выполнили Вы запись в память, но из-за наличия буфера записи, данные не сразу физически запишутся в ОЗУ, а через некоторое время. И если эта запись вызовет fault, то PC к этому времени уже убежит на несколько инструкций. Вот тут и получите "неточный отказ".

[Arlleex]

А эскалация - это когда к примеру у Вас запрещён BusFault, но происходит причина его вызывающая и, так как он запрещён, то происходит эскалация до HF. У меня обработка всех fault-ов построена на эскалации до HF - так проще, чем писать кучу обработчиков с одинаковыми действиями. В ISR HF по регистрам всегда можно определить первоначальный источник, до эскалации.

Ну да. На самом деле-то вот что интересно: вообще возможно ли сделать так, чтобы "вычислить" начальное место, откуда пошло затирание памяти Вангую, что нет
Разве что всегда при входе проверять аргументы на заданные диапазоны (указатели тем более) и в случае чего делать assert() с тем же вызовом SVC и записью в журнал. Да и не совсем очевидно, что делать, если в функцию пришли не ожидаемые параметры (к пример, слишком большой объем запрашиваемых данных на копирование) - совсем не отрабатывать (прямой return из функции), копировать по максимальному ожидаемому размеру, и т.д. Обычно такие ситуации я передаю наверх по стеку вызовов и там уже на уровне логики принимаю решение - делать ли перезапрос, например
А вот насчет порчи памяти третьим лицом (функцией в нашем случае) - вещь тоже довольно интересная, случалось сталкиваться с таким, причем даже с отладчиком порой можно просидеть день, ничего не надебаживши. Правда в таких случаях меня все-таки спасают assert-ы по входу функций. Сразу видно кому снесло голову.

[jcxz]

Один из источников полностью программный. Т.е. связка таймер-ПДП-АЦП рулит ШИМ и обеспечивает цифровой ПИД-регулятор.

В XMC4xxx можно периферию связывать между собой ещё более аппаратно - даже без использования DMA, который вносит непредсказуемую задержку.
Например в текущем проекте у меня передача блока данных по UART запускается сигналом от таймера (аппаратным сигналом без всяких DMA). Это позволяет устройству-приёмнику синхронизировать свои часы с передатчиком с точностью до такта CPU. С DMA такое не сделаешь.
Или например: АЦП по нескольким каналам измеряет и суммирует данные с большой скоростью, но пропускает окна из заданного числа тактов вокруг интервалов мёртвого времени от 3-фазного ШИМ (сигналы у переключении ключей на время замораживают АЦП), убирая таким образом из измерений помехи в моменты переключения мощной нагрузки.
Да ещё много что возможно.

Ну да. На самом деле-то вот что интересно: вообще возможно ли сделать так, чтобы "вычислить" начальное место, откуда пошло затирание памяти Вангую, что нет

В общем случае нет, но в части таких случаев - возможно. Нужны соответствующие инструменты.
Вот тут коллега haker_fox (вроде?) писал, что работает с LPC43xx. Так в нём есть ETB. Он позволяет сделать обратную отладку. И если со времени первопричины прошло не очень много времени, то так можно найти её.
Ну или эмулировать возможности ETB программно: у меня например для этого во многих проектах реализован "Монитор выполнения" - это высокочастотное периодическое прерывание, в котором в FIFO фиксируются регистры CPU и верхушка стека. Он не раз мне тоже помогал находить такие сложные ошибки с разрушением памяти.

А вот насчет порчи памяти третьим лицом (функцией в нашем случае) - вещь тоже довольно интересная, случалось сталкиваться с таким

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

[Arlleex]

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

Вот тут я Вас очень даже понимаю. Бывает над одним проектом работает несколько человек и у каждого "работает все".
Про ETB спасибо, кстати, надо бы до конца поразбираться со всякими CoreSight финтиклюшками - ITM, TPIU, ETB (Embedded Trace Bus который) и т.д. А то может уже все придумали давно а мы я не пользуемся(-юсь)

[jcxz]

ETB (Embedded Trace Bus который)

Embedded Trace Buffer

[Kabdim]

"вычислить" начальное место, откуда пошло затирание памяти Вангую, что нет

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

[AlexandrY]

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

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

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

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

Ну и последняя модная фишка от IAR 8.20 - стековые канарейки (stack canaries)
Такая фича компилера, когда он автоматом вставляет некую проверку стека на целостность в каждую подозрительную функцию.

Кста, если кто забыл. Есть еще такая фича у IAR как С-RUN Runtime Checking, тож проверяет кучу косяков в риалтайме как и Ubsan

[haker_fox]

Ну и последняя модная фишка от IAR 8.20 - стековые канарейки (stack canaries)
Такая фича компилера, когда он автоматом вставляет некую проверку стека на целостность в каждую подозрительную функцию.

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

[AlexandrY]

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

Нет не только. Сейчас в активной поддержке у меня проекты в Keil 4, Keil 5, IAR 7 , MPLAB
А вот как раз на 8-й IAR я еще не перешел. Жду плагина под MQX.

[jcxz]

Нет не только. Сейчас в активной поддержке у меня проекты в Keil 4, Keil 5, IAR 7 , MPLAB
А вот как раз на 8-й IAR я еще не перешел. Жду плагина под MQX.

А что - с 7-го IAR на 8-й надо как-то переходить?
У меня довольно большой проект нормально компилится и работает как под IAR7.80 так и под IAR8.20. И разницы в работе не заметно. Разве что в размере кода небольшая.

[haker_fox]

Жду плагина под MQX.

Странно, что NXP купив Freescale не портировал MQX на LPC серию.

[Kabdim]

Зато они сменили лицензию на 5 версию. За деньги что-нибудь может и будет портировано.

[Arlleex]

Кстати, коллеги.
А нормальная ли практика фиксировать критические события во внутреннюю Program Flash МК? Обычно для внутрисистемных (внутри МК, в смысле) ошибок не требуется много памяти. Выделить два куска по N кБ и цикличный автомат журналирования организовать (чтобы при потере питания последние записи не потерлись). А то я, конечно, сам ставлю на все устройства внешнюю память, но интересует опыт (положительный/отрицательный) журналирования в набортную память МК. ИМХО, если не злоупотреблять printf() с прямым текстом в лог и только регистровые фреймы хранить, самое оно.

[AlexandrY]

Кстати, коллеги.
А нормальная ли практика фиксировать критические события во внутреннюю Program Flash МК? Обычно для внутрисистемных (внутри МК, в смысле) ошибок не требуется много памяти. Выделить два куска по N кБ и цикличный автомат журналирования организовать (чтобы при потере питания последние записи не потерлись). А то я, конечно, сам ставлю на все устройства внешнюю память, но интересует опыт (положительный/отрицательный) журналирования в набортную память МК. ИМХО, если не злоупотреблять printf() с прямым текстом в лог и только регистровые фреймы хранить, самое оно.

Расскажите лучше как вы по регистровым фреймам способны хоть что-то понять о причине сбоя.

[aaarrr]

А нормальная ли практика фиксировать критические события во внутреннюю Program Flash МК?

Не лучший вариант, если принять во внимание сложность реализации и возникающую привязку к железу.
EEPROM стоит копейки, ни к чему экономить.

Расскажите лучше как вы по регистровым фреймам способны хоть что-то понять о причине сбоя.

Аншлаг прям.

[jcxz]

А то я, конечно, сам ставлю на все устройства внешнюю память, но интересует опыт (положительный/отрицательный) журналирования в набортную память МК.

Во всех устройствах, где надо было вести журналов сбоев, до сих пор располагал его только во FRAM/MRAM.