Как поймать "Баг" на скорости 72 МГц ?
(тема для обсуждения и поиска решения)

Задача: Есть условное устройство на базе STM32F103C8 (Cortex-3M) которое работает на максимально разрешенной частоте в режиме максимальной нагрузки, то есть активно работает ядро АРМ, периферия, порты ввода-вывода, DMA, таймеры.
В процессе длительной работы (неделя) систематически происходит сбой. Зацикливание, спонтанный неконтролируемый сброс МК и т.д.
Всё это возможно по ряду причин: Сбой по питанию, переполнение стека или "кучи", кривой арбитраж шин или прерываний, неисправность МК. Причин масса.

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

Стало быть нам придётся думать самим. Что у нас есть? Есть отладочная система CoreSight.
Есть две "собаки" WatchDog таймера. Внутренний, зависимый от периферии и независимый автономный.
Внутренний оконный WWDT, перед командой Сброса МК может сгенерировать прерывание. Данная опция специально разработана инженерами из STM для того, чтобы иметь возможность сделать дамп данных (память, состояние регистров, состояние периферии и т.д) перед сбросом системы МК.
Что может быть проще? Написали в обработчике прерывания от "собаки" процедуру инициализации SPI,UART
или I2C и выплюнули в внешнюю Флэш-память дамп всей оперативной памяти + состояние регистров.
Далее считал с флэши и сиди анализируй - где споткнулся или завис МК. Бинго !

Это я описал самое очевидное и "тепличное" развитие событий. ТАК бывает... Но редко...
А если контроллер прерываний "упал" или зациклился в одной точке? Если вообще ядро АРМ "упало" или
зациклилось? А может вообще - стек налетел на "кучу" и управляющая программа рандомно пошла вразнос и
остановила генераторы шин или периферии? В данном случае "собака" WWDT бессильна. Она мертва.
Есть конечно ещё независимый IWWDT - но он не генерит прерываний - тупо сбрасывает контроллер.
Есть отладочное CoreSight - до которого тоже ещё надо уметь достучаться.

Так что Давайте высказываться, Уважаемые участники сообщества. У кого какие есть на это мысли и решения?

Постараться делить неопределенность на малые куски. Есть подозрение на питание - проверяйте на стенде с хорошим источником. Есть/нет? Есть подозрение на свою криволапость - подробные логи и отдавать их наружу. Думаете что срабатывает внешняя собака - сделать технический бутлоадер, который отдает содержимое рам наружу. Думаете про стеки - сделайте их защиту или вычислите их максимальное значение для каждой задачи. И т.д. А в аппаратные сбои блоков процессора без наличия проблем с питанием, я простите не верю.
Ну и банальщина - все предупреждения, компиляция с макс оптимизацией.

А эта темпа предметная или пофлудить об абстракте?

Обычно помогало постепенное упрощения функционала до момента когда перестает "зацикливаться, перзагружаться, вешаться", а дальше логическая цепочка и высшие силы)

Скорми проект бешеной лошади. Уверен что она найдёт огромное количество ошибок.
Потому как проектов без ошибок не существует. (Если проект не содержит ошибок - значит сам проект ошибка.)

Я только немного добавлю...
Есть сокращение DFT. Там много чего написано, но это надо изучать ДО ТОГО КАК аппаратура сделана...

https://www.google.ru/search?q=Design+For+T...ameter}ie=UTF-8

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

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

Сделать 10 одинаковых устройств, функционал распределить между ними. Там где сломается - там проблема.
Вообще тема тестирования бесконечна.
Если время=деньги, тогда надо брать крутой отладчик типа ULINKpro и через него писать лог в компьютер.

Элементарная обработка исключений хотя-бы сделана?

Есть такая мысль. Решил слизать с промышленных контроллеров. Там один 8-ми битный порт отдают на real-time bug catcher.
его подключают к прозрачному регистру-защёлке типа 74HC573 а выходы на 7 светодиодов. 7-бит "красный", 6-й "зелёный", остальные "жёлтые"
Суть такая: Присваиваются номера. Процедурам на вход и на выход и нее, и прерываниям на вход и на выход.
Например: Процедура A (0x01 -IN, 0x02 - OUT) , Процедура B (0x03-IN, 0x04 - OUT)..... и т.д.
Прерывание A (0x41 -IN, 0x42 - OUT) , Пррерывание B (0x43-IN, 0x44 - OUT)..... и т.д.
При прирывании по WWDT перед сбросом в информационном байте устанавливается 7-й бит в 1, это чтобы после сброса
при начальных установках не скинуло содержимое регимтра-защёлки подключенной к bug-catcher порту.

Процедуры и прерывания пишут свои номера при входе и выходе в порт. Регистр-защёлка их запоминает. В случае ступора или сброса,
на светодиодах видно - где споткнулся МК.




50/50... Есть проект "маршрутизатор-переводчик" промышленный. По 485-му "мастер" разговаривает с 232-ми "слейвами". Протоколы разные.
они известны, но изменить их нельзя. Данный девайс получает пакеты, переводит их в нужный формат и отдаёт "слейвам", получает от них ответ, опять переводит в другой протокол и отправляет "мастеру".
Вот такая штука из "говна и палок", работает... Но с глюками. Спонтанными. Может долго работать без сбоев. Но иногда частит. Суть в том,
что глюки начинают вылазить при оживленном траффике по сети, если запросов-ответов мало может неделями работать без проблем.

А вообще - то, мне тема интересная. Я большой любитель ловли "багов", и пофлудить не прочь. В любом случае это - ОПЫТ.

При такой постановке - устроить флуд по каналам. Скорее всего либо проблемы на каком-то протоколе, либо при флуде вообще - всплывут.

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

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

После перезапуска проверять состояние регистров причины и отсылать сообщения / писать их в логи?
Ну это как вариант.
А вообще - хороший вариант - внутренняя же трассировка проблемного события.
Это когда код вместо резкой перезагрузки сохраняет состояние системы и пишет в консоль (или файл, а лучше в два) сообщение о том что произошло, когда, почему и дампы, дампы, дампы...

Внимательное ревью кода и обработка исключений творят чудеса даже при самых спонтанных багах

Если честно - "Это не моя война..." (с)

Софт писали какие-то студенты на Cube-HAL-е... Потом они уволились, допиливали другие... и т.д.

Я привёл данный случай как пример. Но если софт писали дилетанты - это не значит, что не глючит софт написанный профессионалами,
по всем канонам и со всеми ритуалами.

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



Построить "своречник" вокруг столба с "девайсом", поставить там ноутбук и жить там-же... круглосуточно...

Это устройство не в процессе разработки и не на стадии тестирования. Оно уже в сети, и на нем завязано производство.

Я понимаю Вас. Меня интересуют "методы", пусть даже нестандартные. Возможно даже кто-то здесь имеет в своём распоряжении
самопальные компактные супервазеры для STM32, я-же не прошу схему, код и готовые решения на халяву. Я ищу ВЕКТОР направления
в котором двигаться.

На самом деле это будет только началом. Дампы дают очень мало информации.
Берите в качестве примера лучшие практики.
А лучшие практики можно найти в методах отладки стека протоколов поверх TCP.
Издревле там люди применяют счетчики и статистики.
Скажем счетчики SNMP. Там на одном только MAC уровне их несколько десятков.
В хороших чипах эти счетчики сделаны аппаратно.
Даже если вы не понимаете назначение многих их них один взгляд на поведение счетчиков может дать идеи где искать проблему.

Дальнейшими шагом было бы применить RTOS с автодиагностикой стеков, задач и объектов синхронизации.
Дальше можно было бы применить визуализаторы типа https://www.segger.com/products/development...ols/systemview/

Эффективный поиск багов всегда должен включать рефакторинг, а не ревью.

Если с этой точки зрения, то вот что я могу добавить.
Если разработку рассматривать как переходный процесс, то за 3 "тау" мы придем к уровню 5% ошибок. И для кого-то этого будет вполне достаточно, т.к. для этого типа аппаратуры 5% ошибок будут не критичны. Ну например домофон или аэрогриль. Ну, сбойнут или зависнут. Не так страшно. А если аппаратура работает долго, и ошибки фиксируются как нарушение работы, то тогда и 1% ошибок будет неприемлем. Да вот только для 1% а уж про 0,1% нужно столько этих "тау", да еще не в лаборатории, а в труднодоступном месте.
Вот потому "промышленная" аппаратура имеет гораздо более высокую цену.
И потому для "промышленной" аппаратуры все возможные виды тестирования и поисков неисправностей необходимо закладывать как рабочее программное обеспечение. А в идеале - с удаленным доступом. Иначе пара судебных исков и фирму можно будет закрыть...

И эта фраза:"Построить "своречник" вокруг столба с "девайсом", поставить там ноутбук и жить там-же... круглосуточно..." Говорит о том, что ТС еще не натрахался "в поле"...

Стек "растёт" в сторону младших адресов - убираете его в начало ОЗУ: уберёте один пункт головной боли и получите один чёткий индикатор, когда стек достигает "дна". Куча и статическая память из причин "головняка" устраняются.

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

А какой смысл отлаживать чьё-то гумно, на которое даже смотреть противно? Пишите своё.

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

ps
особенно в таком контексте

Поймать баг несложно на самом деле. Надо сделать всего три вещи.
1. Повесить на шину питания отдельный осциллограф и направить на экран обычную Web камеру с компа. И писать всю неделю видео.
Как вариант взять четырехканальный и писать 4 канала. По видео точно найдете соответствие сбоя и питания.
Стоит это копейки по любому.

2. Повесить отдельный канал логов на RS232 скажем и выдавать в него лог входа выхода во все подпрограммы, плюс тестовую информацию.
Точно также писать неделю с временем входа, выхода в каждую подгрограмму. Сюда же загонять копию всех входных данных, которые
поступают на модуль. Ну это и так будет видно если загонять в лог входные параметры подпрограмм.

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

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

Я вижу тут народ потроллить собрался

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

Какой бы отшиб не был у завода, старенький ноут, недорогой USB осциллограф и запись с экрана ноутбука сделать реально. Положить его где нить в углу и
можно по Ethernet заходить удаленным рабочим столом и смотреть чего там и как.

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

А уж валить в ПО данные случайно сгенерированные максимальным потоком стандартная процедура вообще. Где тут троллинг?

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

1) С чего Вы вообще решили что у девайса автора есть экран?
2) Окей - записали Вы неделю 4 осциллограммы, потом ещё сели сами и за пару месяцев их всё просмотрели и.... ничего не нашли. Дальнейшие действия?
А за эти 2 месяца уже могли бы весь быдлокод переписать. И был бы гарантированный результат.

Ваша зарплата за 2 месяца сидения у экрана - это копейки? Хммм... может Вам лучше поискать другую работу?

3) Отдельный канал логов на RS-232 - это конечно отдельная песня!!!

Что именно писать? Для каждой п/п просто определённых два числа? Предположим, что для такого числа достаточно 16 бит (по общему кол-ву функций).
И предположим что среднее время выполнения всех функций == ~72 такта.
Итого имеем: 16*2*1МГц - т.е. необходим RS-232 с битрейтом 32Мб/сек. Не кажется Вам что это черезчур для RS-232-а?
Ну ладно - ок, допустим - нашёл ТС такой RS-232. Считаем далее:
2*2*1e+6*60*60*24*7 = ~ 2.4e+12 байт - итого через неделю работы получаем 2.4 Терабайта таких чисел.
Теперь осталось Вам просто сесть и разобраться в этом месиве из малоосмысленных чисел! И я думаю этой работы не только Вам до самой пенсии хватит, но и внукам и правнукам в наследство останется К тому времени уже сам девайс прахом пойдёт, а может и предпрятие - тоже, где сей глючный девайс эксплуатируется.
Это ещё даже не говоря о том, что проявление бага во время работы некоей функции совсем не говорит о том, что проблема именно в ней. А не в другой функции, за несколько тысяч тактов до неё порушившей память. Или функции в ISR или в другой задаче ОС или....
Т.е. - потребуется многократная фиксация бага. И кратное увеличение количества поколений ваших потомков для анализа нагенерённого добра.
В то время как один нанятый за нормальный деньги грамотный программист уже давным-давно переписал бы весь студенческий колхоз на вменяемый код.


А с чего оно вдруг обнулилось-то? С какого перепугу? У Вас в программах вот так просто память берёт и обнуляется???
Вероятность виноватости железа по описанию проблемы автором тут видится примерно на уровне ноль целых хрен десятых процента.


Исходя из вышеизложенного примем, что каждую секунду девайс совершает примерно 2e+6 входов-выходов в функции, которые надо писать.
А писать мы могем только 115200 бод. Т.е.: 32e+6/115200 = ~278 - это значит записываться будет только каждый 278-й вход или выход.
И соответственно остальные 277 останутся за бортом. Надеетесь, что автор - счастливчик, ему повезёт и баг случится именно в этом 278-м вызове, а не остальных 277 ?

Учащение сбоев при увеличении трафика почти однозначно говорит о ситуации называемой "race condition"
Если нет RTOS, то надо досконально перетрясти все прерывания на предмет использования глобальных переменных.
Проще всего автору взять и искусственно увеличить частоту прерываний относящихся к интерфейсам.
Особенно хорошо бывает когда частоты прерываний очень близки.
Либо близки частоты главного цикла и прерываний.
Тогда точки прерываний плавно проходят абсолютно по всему рабочему коду не оставляя белых пятен с возможными гонками.

"Знали-бы где упасть - соломку подстелили-бы..." (с)

Тут я полностью согласен. Быдлокодерство не подразумевает ни ведение грамотной документации, ни специальных программных вставок-решений для отладки. Слепили из "говна и палок" - заработало кое-как и ладно... А там хоть не рассветай...




Второе грамотное предложение.

Действительно, надо было сделать хотя-бы пару идентичных устройств, дабы в процессе тестирования и работы отсечь аппаратные неисправности, как-то битый МК, обвязка, комплектующие и пр. То есть чётко отделить железо от софта




Время - есть. Денег - нет....

И так далее по тексту, что сказать, тяжелая у вас жизнь

Я уже отвечал выше. "Это не моя война..." (с)

Меня интересуют методы. Данный девайс и его глюки приведены как пример.

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



Извините, но очень смешно...

По питанию проблем нет и быть не может. Автомобильный аккумулятор и два линейных регулятора на 5 и 3.3 Вольта. Никаких импульсников и пр.



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

Дело в том, что пакеты отправляемые "мастеру" фиксированной величины. Этим спокойно занимается DMA.
А вот пакеты поступающие от "мастера" разной величины, поэтому разработчик сделал прием на прерываниях.
Так как "мастеров" несколько, я также думаю что проблема в одновременном получении пакетов от нескольких "мастеров" сразу.

Арбитраж видимо был не предусмотрен...



Немножко об отладочной системе CoreSight...

Кто-то тут писал про Segger-овский ULINK 2, так вот, у STM32 урезаная версия CoreSight, которая не поддерживает ETM

Так что с трассировкой прерываний через крутой ULINK 2 пролёт...

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

Это как????
Один драйвер - много физики, одна физика с миксом на внешние каналы, или фулл эмуляция на железе не предназначенном для этих целей?

Не всё так однозначно.
Интерфейсы есть какие-нибудь, на них защитные диоды есть, высоковольтный импульс диоды замкнут на питание, стабилизатор не успел отработать - питание подпрыгнуло.
А например RS485, на КЗ в линии, может отдавать ток до 250 мА - при кратковременном КЗ можно получить кратковременную просадку питания.

Чтобы подпрыгнуло питание от высоковольтного импульса он должен по энергии превосходить все что упоминается в стандартах на ЭМИ.
Обычных конденсаторов хватает чтобы сгладить все реальные импульсы.
А от нереальных уже что-то должно было бы сгореть.
Да и быстрая просадка питания вызовет всего лишь сброс.
Если копать в питании, то надо искать медленную просадку, а потом ее причину.

В криво сделанных проектах обычно сидит по нескольку ошибок. Исходить надо из этого.
Автомобильный аккумулятор эт кстати отличная причина сбоев.
Потому что это хорошая толстая антенна для FTB импульсов.
Тут на форуме для некоторых разработчиков плат FTB настоящая мистика, которую они не могут постичь годами.
Так что не удивлюсь если после замены аккумулятора на обычный изолированный DC/DC проблемы пропадут (вернее снизится их вероятность).

Кстати а сама постановка вопроса в теме предполагает, что баг проявляется только на частоте 72МГц?
А на частоте, например 60 МГц, всё хорошо?
Может в этом направлении надо копать?

Я так понимаю, что сама постановка вопроса говорит о том, что для того чтобы код перевести на частоту 60МГц, его надо полностью переписать. Естественно тогда баги могут и пропасть.

Добрый день !

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

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


Дельные ответы изо всей "воды" здесь вылитой я всё-же получил:

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

2. Сразу-же вести записи и документацию. Эдакий "бортовой журнал". Всё записывать и документировать.

3. В процессе разработки сразу предусмотреть как минимум один порт и интерфейс (UART,SPI,I2C) для отладки. Если нет места и ног - брать
более функциональный чип из серии МК.

4. В процессе написания программы предусмотреть контрольные точки и индикацию происходящих в МК процессов, чтобы поиск неисправности
не превратился в заглядывание под капот мчащегося на скорости 200 км/ч автомобиля - "всё шумит, всё крутится, ничего не понятно..."

5. ......


Далее прошу продолжить участникам данной темы, если не лень конечно...

5. В каждом устройстве иметь светодиод мигающий раз в секунду если все ок.
3`. В каждом устройстве иметь отладочную консоль UART.

Как я уже писал: во все программы на Cortex-M обязательно добавлять обработку fault-ов. Это часто существенно сокращает время поиска багов в проблемах с указателями, разрушением памяти, стеков и т.п.
Также - в обязательном порядке использовать MPU по-максимуму. А на более жирных камнях - MMU. Для защиты памяти и выявления несанкционированных доступов к регионам.
И если устройства единичные и бюджет на отладочные средства ограничен, то использовать более жирные МК, например имеющие поддержку ETB. Когда из-за разрушения чего-либо выполнение программы улетело по недопустимому адресу, то с обычным J-Link найти точку в прошлом где "свернули не туда" поможет только ETB.

Всегда делаю отладочный вывод через свободный УАПП. В зависимости от #define включается более или менее подробный вывод (есть два класса debug и ndebug с одинаковыми интерфейсами):


Коллегам недавно понадобилось отлавливать редкий глюк в автомобильном устройстве, которое катается вместе с автомобилем и программиста-наблюдателя с ноутбуком держать круглосуточно в этом автомобиле оказалось невозможно. Сделали простейшее устройство, которое тупо весь поступаующий в его УАПП текст пишет на SD-карточку, предваряя каждую строку текста меткой времени (время считает встроенные в проц часы с батарейкой). Этот "накопитель" катается вместе с устройством, после возникновения ошибки из него извлекается SD-карточка и программист спокойно за чашечкой кофе анализирует все, что оно записало. Метки времени позволяют быстро отыскать нужное место в файле.

Не "если", а сразу брать, и не "более", а самый функциональный в семействе.
Вот так будет правильнее.

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

Систему контроля версий применять. Я пользуюсь TortoiseHg.

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

Так это контроль истории, а не версий.
Контроль истории есть во всех продвинутых редакторах.

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

Назовите такой продвинутый редактор, в котором можно посмотреть состояние проекта неделю назад?

RAD Studio, Android Studio, Sysmac Studio, IntelliJ IDEA....
Это только те с которыми я работаю прямо сейчас.

Да, в андроид студии такое есть...

Справедливости надо таки да сказать что Android Studio и Intellij IDEA это одна и та же среда

Если еще справедливей, то Android Studio идет со своими addon-ами для рефакторинга, а Intellij IDEA со своими.

>> Назовите такой продвинутый редактор, в котором можно посмотреть состояние проекта неделю назад?

RAD Studio . . . редактор, а особенно броузер .... "не-дай-бог". Тупило и глюкало. Структура и состав контекстного меню - тоже
"оригинально" сделана. Явно не для отладки и чтения чужого кода.
IMHO.
Контроль версий - Git+Tortoise (вполне комфортно работать и без Tortoise - из командной строки).
Недостаток - нет сплошной номерации ревизий, как в SVN. На мой взгляд - единственный.
(не столько недостаток, сколько "шаг назад", чтобы сделать несколько вперед).

Так ставьте расширения GExprets, AQtime, CodeSite... и будет счастье. Все равно под десктоп ничего лучшего нет.

. . . . а-а-а-а. В ЭТОМ смысле.
5. Для поиска очень редких сбоев, полуаппаратный метод. В том числе в среде RTOS.
Используете лог. анализатор (онлайновый, с возможностью просмотра движущейся "ленты". У меня - встроенный в осц-ф, 16 каналов).
В критические участки кода (вектора прерываний, планировщик RTOS, флаги ошибок) ставите "ногодрыг". Если необходимо поймать комбинацию флагов, можно линии "ногодрыга" подключить на внешние схемы "И".
Развертка ставится самая медленная. Если в осц-фе есть память - это также можно использовать (но это "не про меня").
Далее писать алгоритм "отлова" нет смысла, все очень индивидуально.
Эта метода поможет "засечь" состояние первого сбоя, который в любом случае придется ловить вручную или наполовину вручную.
При появлении сбоя - жмем на осциллографе "Stop/Freeze" и не спеша рассматриваем предисторию вылета.
Спасибо за инф. Посмотрим что за звери.