Поиск бага

[bass1981]

Доброго дня...

Попался мне проект на STMF103... Писал не я, кода приличнинько....
Неизвестно при каких обстоятельствах бывают зависания программы...
Поставил вач... Но это же не выход из ситуации. Кто как осуществляет поиск таких багов ? Думаю поставить логирование программы через усб.

[mike-y-k]

bass1981, очень давно придумали такое для BIOS - POST code называется.
А уж куда его писать - зависит от свободных ресурсов. Например в тот же UART. Или на I2C повесить расширитель портов. Думаю, что 256 кодов будет достаточно для борьбы с жуками .

[bass1981]

А вы мне идейку подкинули, не подумал... Во флешь писать.... Сижу думаю о нюансах...

BIOS - POST code .... ??? Гугланул, мельком глянул это все таки не для МК...

[mike-y-k]

bass1981, и чем не для МК сей алгоритм?
Его суть в записи некоторого кода источника в порт. Если подвисло - известна последняя выполнявшаяся процедура и соответственно сужается зона поиска.
Не конкретная реализация, а сам алгоритм установки контрольных точек.
Писать во flash наверное не стоит, а вот установить расширитель портов I2C вполне нормально будет. Он будет работать как защёлка и хранить 8-ми битный код точки по аналогии с POST. Там уже надо просто подумать как совместить хранение и срабатывание wdt или просто убрать wdt для отладки…
Пользуюсь таким при невозможности прямой отладки зашитой программы - полет нормальный. Такое иногда даже в продакшн идёт как набор регистров состояния .
На том же интерфейсе можно и экран прикрутить уже с выводом массива данных в контрольных точках.
Отладочные средства - это совсем не данность свыше, а продукт нашей кочки зрения на проблему и ее решение.

PS Например PCF8574AT/3.512, Расширитель цифровых входов/выходов для шины I2C [SO-16] у чипа с диплом стоит 52 деревянных. Можно замутить отдельной платой с преобразователем уровня, отдельным питанием и светодиодами для индикации (типа сразу универсальный вариант).

[bass1981]

А по чему не во флешь ??
Конечно в стме геморойненько это делать постоянно нужно менять адрес записи...
Отключить ватч.... И сделать например ожидание считывания флешь после перезагрузки....
Выводы в порты более конечно актуально, но данное решение подходит когда проектируешь устройство и заранее продумываешь средство отладки...
А когда уже все по железу сделано... Нужно использоваться что есть... Есть USB...
У меня мысли : флешь или на время отладки рядом компустер. Или вообще под отладкой запустить , но что то мне кажется что она сама по себе отвалиться.....
Самое что удивительное сейчас пропишешь отладку и все при отладке будет работать.. )) (Маленькая пауза может извинить всю картину)... Вон у меня есть проект (перешел на V5 keil)..... В прерывании USART все пишется в буфер. В основном цикле проверяется буфер и отправляется в USB... Так после отправки слетание в exeption... Выручила пауза 5ms перед отправкой в USB ... Но данные могут отправляться не только по событию заполнения буфера и опять Exeption в момент приема по USART... Выставлял приоритеты прерываний, не чего не помогло... Думаю попробовать запретить отправку по USB после приема по USART... Или опять вернуться к 4ой версии кейла где все четко работало...
Ну ладно это другие бараны )))

[mike-y-k]

bass1981, с I2C как-то уже истоптано все - главное возможность его использовать должна таки остаться, а остальное уже мелочи.
Всего 2 провода к плате (4 с Vdd и Gnd) и нет проблем. А код при зависании видно невооружённым глазом .
Минимально - одна микросхема, платка, 8 сопротивлений и столько же светодиодов. Можно ещё подтягивающие на неё поставить +2 сопротивления.
Ну и в части софта все тоже относительно просто - запись байта в порт для нужного приёмника. Ну ещё инициализация в самом начале (при необходимости).
Давно и успешно пользую эти расширители - очень удобно управлять чем-то и считывать данные.
И для отладки прекрасно подходят, особенно редких и загадочных зависаний.
В одном проекте даже сделал вариант со вторым МК, который запоминал выставленный код и при появлении на порту 0x00 (при инициализации) высылал его через UART для регистрации. В таком варианте и WDT не пришлось отключать. Ошибка была успешно локализована .

[bass1981]

bass1981, с I2C как-то уже истоптано все - главное возможность его использовать должна таки остаться, а остальное уже мелочи.

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

[dgrishin]

А ведь можно скомпилировать программу с отладочной информацией и и запустить её под отладчиком.
Периодически делая start и stop можно поймать то место в коде где она зависает (по крайней мере в Keil так можно). Также там можно и выводить диагностические сообщения в отдельное окно.

[mike-y-k]

bass1981, занят под I2C или по другому назначению ноги заняты?
Если первое, так там можно целых 127 устройств иметь - главное с подтяжкой разобраться. Со вторым вариантом уже сложнее .

dgrishin, тут дьявол именно в мелочах. Все будет строго по закону Мэрфи - в отладчике без проблем, а без него виснет. И если ошибка происходит один раз за несколько суток работы - удовольствие от отладки ещё то получится .
В одном очень простом устройстве перезагрузка по WDT из-за ошибки происходило раз в 2-3 недели. И только такое решение позволил за несколько месяцев итераций с контрольными точками по программе вычислить место, найти и исправить ошибку.
Ну и частенько в месте установки это просто нереально сделать . А ошибка на столе никак не воспроизводится, только в рабочем варианте…

[bass1981]

Под I2C заняты.... Точно что там можно 127 устройств !!!
Предлагаете микросхему памяти повесить... ?

Да да в том то и дело что ошибка раз в двое суток происходит....

И зависать она может глубоко CMSIS и с какого места вызвана данная функция поди разберись... Это если например засунуть нулевой буфер и т.д ... А по всей программе вызовов данной функции штук 100....
Долго я один раз так ковырялся, нашел методом тыка такую ошибку...
Кстати !!!
В стеке должен оставаться адрес возврата как его в кейле найти можно ?