[Obam 38]

А может вообще - стек налетел на "кучу" и управляющая программа рандомно пошла вразнос и

остановила генераторы шин или периферии?

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

Изменено 24 апреля, 2018 пользователем Obam

[Fox_Sanchez 1]

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

[jcxz 242]

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

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

[k155la3 27]

Еслиб Вы поподробнее расписали что-есть-девайс, в смысле структуры периферии (внешней) и софта, могобыть и решение упростилось бы.

Если "слет" вызван мощной помехой - то при чем тут софт и железо ?

Это можно ловить долго и с туманной перспективой. Если есть возможность поставить "подменку" - это самый правильный ход.

Проверьте "окружение" девайса, питание, помехи на линиях связи итп.

По софту - извиняюсь, конечно, проверьте потенциально-вечные while(). Если таковые имеются (а вдруг, если не в своем коде, то в подулючаемом чужом), замените на

int MaxCount = 10000; 
while(. . . )
{
. . . .
MaxCount--;
if(MaxCount == 0)
{ 
     while(1) { ногодрыг на LED, вывод на терминал __LINE__, __FUNCTION__ итд}
}

}

ps

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

на Cube-HAL-е...

[twix 0]

Как поймать "Баг" на скорости 72 МГц ?

(тема для обсуждения и поиска решения)

Поймать баг несложно на самом деле. Надо сделать всего три вещи.

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

Как вариант взять четырехканальный и писать 4 канала. По видео точно найдете соответствие сбоя и питания.

Стоит это копейки по любому.

 

2. Повесить отдельный канал логов на RS232 скажем и выдавать в него лог входа выхода во все подпрограммы, плюс тестовую информацию.

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

поступают на модуль. Ну это и так будет видно если загонять в лог входные параметры подпрограмм.

 

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

 

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

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

[jcxz 242]

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

...

2. Повесить отдельный канал логов на RS232 скажем и выдавать в него лог входа выхода во все подпрограммы, плюс тестовую информацию.

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

[twix 0]

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

Да нет, мы реально вытаскивали 12 часовые логи с шины питания, осциллограф писали с экрана компа, ну вытащили экран по Ethernet на комп и писали экран.

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

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

 

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

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

 

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

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

 

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

 

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

Особенно если виновато железо, вот взяла вся память и обнулилась. И чего? Ваше ревью поможет?

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

Изменено 24 апреля, 2018 пользователем twix

[jcxz 242]

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

1) С чего Вы вообще решили что у девайса автора есть экран?

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

А за эти 2 месяца уже могли бы весь быдлокод переписать. И был бы гарантированный результат.

Стоит это копейки по любому.

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

 

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 Терабайта таких чисел.

Теперь осталось Вам просто сесть и разобраться в этом месиве из малоосмысленных чисел! И я думаю этой работы не только Вам до самой пенсии хватит, но и внукам и правнукам в наследство останется К тому времени уже сам девайс прахом пойдёт, а может и предпрятие - тоже, где сей глючный девайс эксплуатируется. :biggrin:

Это ещё даже не говоря о том, что проявление бага во время работы некоей функции совсем не говорит о том, что проблема именно в ней. А не в другой функции, за несколько тысяч тактов до неё порушившей память. Или функции в ISR или в другой задаче ОС или....

Т.е. - потребуется многократная фиксация бага. И кратное увеличение количества поколений ваших потомков для анализа нагенерённого добра. :laughing:

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

 

Особенно если виновато железо, вот взяла вся память и обнулилась.

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

Вероятность виноватости железа по описанию проблемы автором тут видится примерно на уровне ноль целых хрен десятых процента.

 

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

Исходя из вышеизложенного примем, что каждую секунду девайс совершает примерно 2e+6 входов-выходов в функции, которые надо писать.

А писать мы могем только 115200 бод. Т.е.: 32e+6/115200 = ~278 - это значит записываться будет только каждый 278-й вход или выход.

И соответственно остальные 277 останутся за бортом. Надеетесь, что автор - счастливчик, ему повезёт и баг случится именно в этом 278-м вызове, а не остальных 277 ? :laughing:

[AlexandrY 3]

Вероятность виноватости железа по описанию проблемы автором тут видится примерно на уровне ноль целых хрен десятых процента.

Учащение сбоев при увеличении трафика почти однозначно говорит о ситуации называемой "race condition"

Если нет RTOS, то надо досконально перетрясти все прерывания на предмет использования глобальных переменных.

Проще всего автору взять и искусственно увеличить частоту прерываний относящихся к интерфейсам.

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

Либо близки частоты главного цикла и прерываний.

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

 

[manul78 4]

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

 

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

 

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

 

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

 

 

Сделать 10 одинаковых устройств, функционал распределить между ними. Там где сломается - там проблема.

 

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

 

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

 

 

Если время=деньги, тогда надо брать крутой отладчик типа ULINKpro и через него писать лог в компьютер.

 

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

[twix 0]

1) С чего Вы вообще решили что у девайса автора есть экран...

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

[manul78 4]

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

 

 

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

 

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

 

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

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

 

Поймать баг несложно на самом деле. Надо сделать всего три вещи.

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

Как вариант взять четырехканальный и писать 4 канала. По видео точно найдете соответствие сбоя и питания.

Стоит это копейки по любому.

 

2. Повесить отдельный канал логов на RS232 скажем и выдавать в него лог входа выхода во все подпрограммы, плюс тестовую информацию.

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

поступают на модуль. Ну это и так будет видно если загонять в лог входные параметры подпрограмм.

 

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

 

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

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

 

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

 

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

 

Учащение сбоев при увеличении трафика почти однозначно говорит о ситуации называемой "race condition"

Если нет RTOS, то надо досконально перетрясти все прерывания на предмет использования глобальных переменных.

Проще всего автору взять и искусственно увеличить частоту прерываний относящихся к интерфейсам.

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

Либо близки частоты главного цикла и прерываний.

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

 

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

 

Дело в том, что пакеты отправляемые "мастеру" фиксированной величины. Этим спокойно занимается DMA.

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

Так как "мастеров" несколько, я также думаю что проблема в одновременном получении пакетов от нескольких "мастеров" сразу.

 

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

 

 

 

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

 

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

 

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

Изменено 24 апреля, 2018 пользователем manul78

[twix 0]

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

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

[AVI-crak 0]

Так как "мастеров" несколько, я также думаю что проблема в одновременном получении пакетов от нескольких "мастеров" сразу.

Это как????

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

[HardEgor 87]

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

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

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

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