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

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


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


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


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


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

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


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

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

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

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


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


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

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

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

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

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


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

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

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

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

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

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


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

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