Как можно отловить случайную багу в embadded проекте?
Добрый день! Проект в Keil, контроллер stm32f4, использую в качестве OS: freertos, пишу на С++/С.
Уже третью неделю борюсь с багой -- что-то в бизнес логике ломает память. Это выражается "случайным" появлением значения 0xFF (1 байта) в области кольцевого буфера на приём от UART (на данный момент зафиксировал такое поведение только в этой области). Сначала думал, что это DMA как то случайно ломает память, и протестировал просто работу приёма в кольцевой буфер. В результате кольцевой буфер работает точно, и сам по себе механизм приёма данных через DMA никак не "ломает" память. Но, как только включаю задачу с бизнес логикой, в случайные моменты времени в кольцевом буфере UARTa на приём, в случайном индексе появляется байт 0xff. Т.е. точно ломает память буфера бизнес логика. Она написана на c++, и кода там довольно много. Но к чему хоть придраться, непонятно.
Я пробовал отыскать ошибку множеством подходов, но каждый раз, когда появлялась зацепка, я терпел фиаско и начинал сначала.
Если есть вопросы по дополнительной информации, задавайте, я отвечу. На данный момент я понятия не имею как можно отловить эту багу. Рад новым предложениям:)
x67: Это устройство, которое взаимодействует с другими устройствами. Под бизнес логикой я понимаю не платформозависимую обработку данных, для достижения неких бизнес задач.
1. Возможно это блокировки шины памяти.
Они бывают если что-то занимает озу или флешь надолго или уарт очень быстрый, 500кБод и выше.
Классика жанра - прошивка параметров в флеш или самого флеша. Или работа другого канала ДМА на макс скорости.
2. Возможно ошибки приёма уарта, советую глянуть осцилографом стабильность уровней напряжения и временную стабильность фронтов.
3. Баг в коде и порча ОЗУ - советую поменять раскладку памяти, если использовать LD файлы то это прощее, в других более закоренелых системах типа кейла непонятно как. Но метод такой - если перенести буфер уарта на другое место в ОЗУ и всё исправилось то это оно и есть. Можно размер стека изменить, поиграться с размером прочих буферов, массивов и тд.
4. Попытаться покускам поотключать бизнес код.
5. Не использовать RTOS - да фантастика, но очень часто причина в нём. Он не идеален, да даже если он был бы идеален, можно накосячить с его использованием.
6. Неправильно настроенная прочая аппаратура - поотключать левое.
7. Подумать когда возникла ошибка и об обстоятельстве её возникновения, нередко бывает например когда ошибка в ячейке c смещением 0х13 и тут вспоминаешь что была добавлена стркутура и третий байт массива в этой структуре как раз с смещением 0х13 после вызова уарта меняется ... опа!
pixik в дополнение к 7: если известна рабочая версия кода, то проходим по истории между рабочей версией и сломанной бинарным поиском. В git для этого есть bisect. В других CVS есть аналоги.
>>1. Возможно это блокировки шины памяти.
Они бывают если что-то занимает озу или флешь надолго или уарт очень быстрый, 500кБод и выше.
Классика жанра - прошивка параметров в флеш или самого флеша. Или работа другого канала ДМА на макс скорости
<< Uart работает на 115200, про остальное, сложно сказать.
>> 2. Возможно ошибки приёма уарта, советую глянуть осцилографом стабильность уровней напряжения и временную стабильность фронтов.
<< Я проверял просто uart, данные передаются без проблем. Прогонял 45 минут данные и поломанных не было.
<< 3. в Keil есть "Scatter file", с помощью которого можно линкеру указать что куда писать. Попробую этот вариант.
>> 4. Попытаться по кускам поотключать бизнес код.
<< В очередной раз сделаю это.
<< 5. это очень дорогой вариант) все завязано на средства RTOS
<< 6. Попробую
<< 7. понимаю о чем вы, было и такое. Но в данном случае никаких ассоциаций не возникает.
Спасибо за предложенные варианты! Отпишу более подробно по результатам.
fshp: Да, в таком случае баг бы решился еще несколько недель назад) К сожалению, этот баг появился сразу. Не все работают в git как нужно, и из за этого приходится работать с коммитами, в которых появляется куча файлов и тонной кода. Что откуда появилось уже не отследить.
pixik: "Не все работают в git как нужно"
Оффтоп, но это легко решается запретом пушей в мастер. Не прошёл ревью - твои проблемы, делай ребейз, оформляй всё правильно.
Без такого простого правила такие проекты, как linux, git, python да и куча других открытых проектов, давно бы уже загнулись.
pixik: как вариант пункта 5 - использовать разные RTOS или их сборки.
как продолжение и развитие мысли варианта пункта 5 - я использую так же разные версии gcc компилятора из последних, и разные уровни оптимизации -O1..-O3 переключиться между ними секундное дело, а если поведение бага меняется или он пропадает, то это более вероятно UB или просто какой то ляп чем вина оборудования или RTOS
