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

Сообщение отредактировал Obam - Apr 24 2018, 14:30

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

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

Еслиб Вы поподробнее расписали что-есть-девайс, в смысле структуры периферии (внешней) и софта, могобыть и решение упростилось бы.
Если "слет" вызван мощной помехой - то при чем тут софт и железо ?
Это можно ловить долго и с туманной перспективой. Если есть возможность поставить "подменку" - это самый правильный ход.
Проверьте "окружение" девайса, питание, помехи на линиях связи итп.
По софту - извиняюсь, конечно, проверьте потенциально-вечные while(). Если таковые имеются (а вдруг, если не в своем коде, то в подулючаемом чужом), замените на

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

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

2. Повесить отдельный канал логов на RS232 скажем и выдавать в него лог входа выхода во все подпрограммы, плюс тестовую информацию.
Точно также писать неделю с временем входа, выхода в каждую подгрограмму. Сюда же загонять копию всех входных данных, которые
поступают на модуль. Ну это и так будет видно если загонять в лог входные параметры подпрограмм.

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

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

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

Да нет, мы реально вытаскивали 12 часовые логи с шины питания, осциллограф писали с экрана компа, ну вытащили экран по Ethernet на комп и писали экран.
А вебкамерой писали само устройство, дело было в лаборатрии, и некие загадочные глюки были похожи на вмешательство людей. Вот чтобы отсечь смежников
писали вебкамерой провода подключенные к устройству.

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

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

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

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

Сообщение отредактировал twix - Apr 24 2018, 16:44

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

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

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 Терабайта таких чисел.
Теперь осталось Вам просто сесть и разобраться в этом месиве из малоосмысленных чисел! И я думаю этой работы не только Вам до самой пенсии хватит, но и внукам и правнукам в наследство останется К тому времени уже сам девайс прахом пойдёт, а может и предпрятие - тоже, где сей глючный девайс эксплуатируется.
Это ещё даже не говоря о том, что проявление бага во время работы некоей функции совсем не говорит о том, что проблема именно в ней. А не в другой функции, за несколько тысяч тактов до неё порушившей память. Или функции в ISR или в другой задаче ОС или....
Т.е. - потребуется многократная фиксация бага. И кратное увеличение количества поколений ваших потомков для анализа нагенерённого добра.
В то время как один нанятый за нормальный деньги грамотный программист уже давным-давно переписал бы весь студенческий колхоз на вменяемый код.


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


Исходя из вышеизложенного примем, что каждую секунду девайс совершает примерно 2e+6 входов-выходов в функции, которые надо писать.
А писать мы могем только 115200 бод. Т.е.: 32e+6/115200 = ~278 - это значит записываться будет только каждый 278-й вход или выход.
И соответственно остальные 277 останутся за бортом. Надеетесь, что автор - счастливчик, ему повезёт и баг случится именно в этом 278-м вызове, а не остальных 277 ?

Учащение сбоев при увеличении трафика почти однозначно говорит о ситуации называемой "race condition"
Если нет RTOS, то надо досконально перетрясти все прерывания на предмет использования глобальных переменных.
Проще всего автору взять и искусственно увеличить частоту прерываний относящихся к интерфейсам.
Особенно хорошо бывает когда частоты прерываний очень близки.
Либо близки частоты главного цикла и прерываний.
Тогда точки прерываний плавно проходят абсолютно по всему рабочему коду не оставляя белых пятен с возможными гонками.

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

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




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

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




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

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

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

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

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



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

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



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

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

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



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

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

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

Сообщение отредактировал manul78 - Apr 24 2018, 20:56

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

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

Не всё так однозначно.
Интерфейсы есть какие-нибудь, на них защитные диоды есть, высоковольтный импульс диоды замкнут на питание, стабилизатор не успел отработать - питание подпрыгнуло.
А например RS485, на КЗ в линии, может отдавать ток до 250 мА - при кратковременном КЗ можно получить кратковременную просадку питания.