| |
|
  |
 Как поимать "баг" в STM32 на скорости 72 MHz?, методы поиска и устранения спонтанных и редких сбоев в работе МК |
|
|
|
|
 Apr 25 2018, 05:47
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(HardEgor @ Apr 25 2018, 08:14)  Не всё так однозначно.
Интерфейсы есть какие-нибудь, на них защитные диоды есть, высоковольтный импульс диоды замкнут на питание, стабилизатор не успел отработать - питание подпрыгнуло.
А например RS485, на КЗ в линии, может отдавать ток до 250 мА - при кратковременном КЗ можно получить кратковременную просадку питания. Чтобы подпрыгнуло питание от высоковольтного импульса он должен по энергии превосходить все что упоминается в стандартах на ЭМИ. Обычных конденсаторов хватает чтобы сгладить все реальные импульсы. А от нереальных уже что-то должно было бы сгореть.  Да и быстрая просадка питания вызовет всего лишь сброс. Если копать в питании, то надо искать медленную просадку, а потом ее причину. В криво сделанных проектах обычно сидит по нескольку ошибок. Исходить надо из этого. Автомобильный аккумулятор эт кстати отличная причина сбоев. Потому что это хорошая толстая антенна для FTB импульсов. Тут на форуме для некоторых разработчиков плат FTB настоящая мистика, которую они не могут постичь годами. Так что не удивлюсь если после замены аккумулятора на обычный изолированный DC/DC проблемы пропадут (вернее снизится их вероятность).
|
|
|
|
|
|
|
|
Apr 25 2018, 08:35
|
Местный
Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719
|
Добрый день !
Спасибо всем за ответы, шутки, стёб, серьёзные советы. Но тему честно говоря я поднимал ради совсем других вещей.
И пример с устройством приведён просто как пример, а не тема для обсуждения.
А вопрос-то изначально был простой, но со сложными ответами. Попытка собрать в один список алгоритм действий для разработчика,
у которого нет дикого бюджета, из аппаратуры только пара хороших компов, ноутбук, ST-Link, J-Link, цифровой осциллограф и простой
недорогой логический анализатор. Устройство которое он делает не серийное, их может быть от силы пару штук, и оно заточено под
конкретные цели - штучный товар.
Дельные ответы изо всей "воды" здесь вылитой я всё-же получил:
1. Делать как минимум два экземпляра, дабы исключить глюки с железом из-за некачественной пайки, компонентов и пр. Также это пригодиться
в процессе отладки, когда один экземпляр работает "в поле" а с другим можно заниматься в лаборатории на столе.
2. Сразу-же вести записи и документацию. Эдакий "бортовой журнал". Всё записывать и документировать.
3. В процессе разработки сразу предусмотреть как минимум один порт и интерфейс (UART,SPI,I2C) для отладки. Если нет места и ног - брать
более функциональный чип из серии МК.
4. В процессе написания программы предусмотреть контрольные точки и индикацию происходящих в МК процессов, чтобы поиск неисправности
не превратился в заглядывание под капот мчащегося на скорости 200 км/ч автомобиля - "всё шумит, всё крутится, ничего не понятно..."
5. ......
Далее прошу продолжить участникам данной темы, если не лень конечно...
--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
|
|
|
|
|
|
|
|
Apr 25 2018, 08:49
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(manul78 @ Apr 25 2018, 11:35) 5. ...... Как я уже писал: во все программы на Cortex-M обязательно добавлять обработку fault-ов. Это часто существенно сокращает время поиска багов в проблемах с указателями, разрушением памяти, стеков и т.п. Также - в обязательном порядке использовать MPU по-максимуму. А на более жирных камнях - MMU. Для защиты памяти и выявления несанкционированных доступов к регионам. И если устройства единичные и бюджет на отладочные средства ограничен, то использовать более жирные МК, например имеющие поддержку ETB. Когда из-за разрушения чего-либо выполнение программы улетело по недопустимому адресу, то с обычным J-Link найти точку в прошлом где "свернули не туда" поможет только ETB.
|
|
|
|
|
|
|
|
Apr 25 2018, 09:13
|
Гуру
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095
|
Всегда делаю отладочный вывод через свободный УАПП. В зависимости от #define включается более или менее подробный вывод (есть два класса debug и ndebug с одинаковыми интерфейсами): CODE #ifndef DEBUG_H__
#define DEBUG_H__
#include <ndebug.h>
#ifndef NDEBUG
#include <console.h>
extern console & Debug_console;
#define Debug_on Debug_console
#else
#define Debug_on Debug_off
#endif
#define Debug_CID Debug_on
#define Debug_panel Debug_on
#define Debug_panel_stream Debug_off
#define Debug_tcp Debug_off
#define Debug_lwip Debug_off
#define Debug_usb_irq Debug_off
#define Debug_usb Debug_off
#endif // DEBUG_H__
......
for(;;)
{
Debug_panel.timestamp();
Debug_panel.printf("%s panel selected\r\n", name(Panel_type));
switch(Panel_type)
{
default:
pPanel = new(&Memory_pool.Disabled) disabled_panel<input::SAMPLE_PERIOD>;
break;
Коллегам недавно понадобилось отлавливать редкий глюк в автомобильном устройстве, которое катается вместе с автомобилем и программиста-наблюдателя с ноутбуком держать круглосуточно в этом автомобиле оказалось невозможно. Сделали простейшее устройство, которое тупо весь поступаующий в его УАПП текст пишет на SD-карточку, предваряя каждую строку текста меткой времени (время считает встроенные в проц часы с батарейкой). Этот "накопитель" катается вместе с устройством, после возникновения ошибки из него извлекается SD-карточка и программист спокойно за чашечкой кофе анализирует все, что оно записало. Метки времени позволяют быстро отыскать нужное место в файле.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
|
|
|
Apr 25 2018, 09:43
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(manul78 @ Apr 25 2018, 11:35) 3. ... Если нет места и ног - брать более функциональный чип из серии МК. Не "если", а сразу брать, и не "более", а самый функциональный в семействе. Вот так будет правильнее. Отладочный вывод в UART плохой вариант, получив два образа, один отладочный, а другой релизный только добавите себе работы по поиску отличий если ошибка будет появляться только в одном из них. Вывод лучше делать в RTT. Тогда он может оставаться в релизном варианте и не надо будет множить образы.
|
|
|
|
|
|
|
|
Apr 25 2018, 10:46
|
Частый гость
Группа: Свой
Сообщений: 123
Регистрация: 15-10-07
Из: Санкт-Петербург
Пользователь №: 31 370
|
Цитата(ViKo @ Apr 25 2018, 13:25) Систему контроля версий применять. Я пользуюсь TortoiseHg. Кстати да, тоже ей пользуюсь. Очень удобно бывает откатиться назад и проверить с какого момента начал возникать тот или иной баг. Частенько пишешь один модуль и по ходу его отладки находишь глюк совсем в другом месте, которое писано несколько дней назад и вроде как не глючило.
--------------------
Ниндзя - круче всех. Они умеют ходить по воде, делить на ноль и угадывать шаффл в АйПоде.
|
|
|
|
|
|
|
|
Apr 25 2018, 16:55
|
Частый гость
Группа: Участник
Сообщений: 182
Регистрация: 16-10-15
Пользователь №: 88 894
|
Цитата(AlexandrY @ Apr 25 2018, 16:48) Так это контроль истории, а не версий.
Контроль истории есть во всех продвинутых редакторах. Назовите такой продвинутый редактор, в котором можно посмотреть состояние проекта неделю назад?
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
