[AlexandrY 2]

Не всё так однозначно.

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

А например RS485, на КЗ в линии, может отдавать ток до 250 мА - при кратковременном КЗ можно получить кратковременную просадку питания.

Чтобы подпрыгнуло питание от высоковольтного импульса он должен по энергии превосходить все что упоминается в стандартах на ЭМИ.

Обычных конденсаторов хватает чтобы сгладить все реальные импульсы.

А от нереальных уже что-то должно было бы сгореть.

Да и быстрая просадка питания вызовет всего лишь сброс.

Если копать в питании, то надо искать медленную просадку, а потом ее причину.

 

В криво сделанных проектах обычно сидит по нескольку ошибок. Исходить надо из этого.

Автомобильный аккумулятор эт кстати отличная причина сбоев.

Потому что это хорошая толстая антенна для FTB импульсов.

Тут на форуме для некоторых разработчиков плат FTB настоящая мистика, которую они не могут постичь годами.

Так что не удивлюсь если после замены аккумулятора на обычный изолированный DC/DC проблемы пропадут (вернее снизится их вероятность).

[amiller 2]

Кстати а сама постановка вопроса в теме предполагает, что баг проявляется только на частоте 72МГц?

А на частоте, например 60 МГц, всё хорошо?

Может в этом направлении надо копать?

[jcxz 184]

Кстати а сама постановка вопроса в теме предполагает, что баг проявляется только на частоте 72МГц?

А на частоте, например 60 МГц, всё хорошо?

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

[manul78 4]

 

Добрый день !

 

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

И пример с устройством приведён просто как пример, а не тема для обсуждения.

 

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

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

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

конкретные цели - штучный товар.

 

 

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

 

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

в процессе отладки, когда один экземпляр работает "в поле" а с другим можно заниматься в лаборатории на столе.

 

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

 

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

более функциональный чип из серии МК.

 

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

не превратился в заглядывание под капот мчащегося на скорости 200 км/ч автомобиля - "всё шумит, всё крутится, ничего не понятно..."

 

5. ......

 

 

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

 

[adnega 10]

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

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

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

[jcxz 184]

5. ......

Как я уже писал: во все программы на Cortex-M обязательно добавлять обработку fault-ов. Это часто существенно сокращает время поиска багов в проблемах с указателями, разрушением памяти, стеков и т.п.

Также - в обязательном порядке использовать MPU по-максимуму. А на более жирных камнях - MMU. Для защиты памяти и выявления несанкционированных доступов к регионам.

И если устройства единичные и бюджет на отладочные средства ограничен, то использовать более жирные МК, например имеющие поддержку ETB. Когда из-за разрушения чего-либо выполнение программы улетело по недопустимому адресу, то с обычным J-Link найти точку в прошлом где "свернули не туда" поможет только ETB.

[Сергей Борщ 119]

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

#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-карточка и программист спокойно за чашечкой кофе анализирует все, что оно записало. Метки времени позволяют быстро отыскать нужное место в файле.

[AlexandrY 2]

3. ... Если нет места и ног - брать более функциональный чип из серии МК.

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

Вот так будет правильнее.

 

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

Вывод лучше делать в RTT. Тогда он может оставаться в релизном варианте и не надо будет множить образы.

[ViKo 1]

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

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

[Fox_Sanchez 1]

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

 

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

[AlexandrY 2]

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

Так это контроль истории, а не версий.

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

 

[HardEgor 63]

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

[AVI-crak 0]

Так это контроль истории, а не версий.

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

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

[AlexandrY 2]

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

RAD Studio, Android Studio, Sysmac Studio, IntelliJ IDEA....

Это только те с которыми я работаю прямо сейчас.

[Kabdim 0]

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