[dontsov 0]

Уважаемые знатоки!
Есть счетчик импульсов на Attiny85 . Раз в 250мс проверяет вход. Раз в сутки будит ESP для передачи данных.
Прошивка отлажена и не менялась год.

Несколько экземпляров из новой партии устройств начали зависать (компоненты одинаковые, куплены в elitan). Устройство настраивают - нажимают кнопку (attiny пробуждает ESP), минут 5 ESP включена, потом ESP посылает данные по i2c на Attiny и та корректно засыпает, продолжая считать.  Через несколько часов Attiny перестает реагировать на нажатие кнопки. Помогает замыкание пина Reset на землю.

Вопрос:
1. Как убедиться в том, что Attiny85 корректно прошилась?

avrdude.exe -p t85 -c Usbasp -B 4 -P usb -U flash:w:"attiny85.hex":a

Программатор: Китайский перепрошитый usb стик USBASP

2. Нужно ли прошивать фьюзы, если они остаются стандартными?
Не записывали их обычно и в этот раз. 

3. Стоит ли поставить Atmel Studio и можно ли там воспроизвести подобное поведение? 
Я не моделировал там, т.к. прошивка работает у многих людей корректно.

4. Является ли использование watchdog для перезагрузки решением проблем с зависанием? (нужна помощь с кодом)
Код 

Буду рад любым советом, чтобы сделать устройство более надежным!

[heavyC1oud 0]

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

Если есть четкая повторяемость неисправности, то можно поставить Atmel Studio и под дебагом посмотреть что происходит при этом. 

Судя по тому что помогает reset, watchdog должен решить этот вопрос, но как по мне это плохое решение, пес скорее для непредвиденных случаев, в идеале найти проблему, решить и оставить watchdog

[Arlleex 131]

03.11.2020 в 22:28, dontsov сказал:

Прошивка отлажена и не менялась год.

Да хоть десять лет. Баги - штука долгоиграющая

03.11.2020 в 22:28, dontsov сказал:

Через несколько часов Attiny перестает реагировать на нажатие кнопки. Помогает замыкание пина Reset на землю.

Ну, "семь бед - один reset" - известное решение. Но кривое, естественно. По-хорошему надо разбираться.

03.11.2020 в 22:28, dontsov сказал:

1. Как убедиться в том, что Attiny85 корректно прошилась?

Ну программаторы разные бывают - посмотрите, как вашим можно вычитать всю память программ МК и сравните с тем, что должно быть.
Или, например, встраивать самый простейший загрузчик (хотя в данном случае корректнее будет назвать его валидатор прошивки).
Он стартанет первым и проверит целостность прошивки (например, по CRC). Если сходится - отдаст управление. Если нет - не отдаст.

03.11.2020 в 22:28, dontsov сказал:

2. Нужно ли прошивать фьюзы, если они остаются стандартными?

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

03.11.2020 в 22:28, dontsov сказал:

3. Стоит ли поставить Atmel Studio и можно ли там воспроизвести подобное поведение?
Я не моделировал там, т.к. прошивка работает у многих людей корректно.

Воспроизвести как? В железе? В симуляторе? Если есть конкретный баг - то в симуляторе, возможно, придется конкретно постараться.
Но я не люблю, допустим, симуляторы - толку от них как от козла молока. Идеально - отлаживаться в железе.
Но не думаю, что Tiny такое может. Хотя, как помню, там был какой-то однопроводной интерфейс отладки - копайте в эту сторону.

03.11.2020 в 22:28, dontsov сказал:

4. Является ли использование watchdog для перезагрузки решением проблем с зависанием?

Это Вас надо спросить. По-хорошему - нет. Собака сделана для перезагрузки по еще не обнаруженному багу.
А значит - заплатка и костыль. Оставлять такое - такое себе. Но смотрите сами - если Вас удовлетворяет сей костыль - ок.

А баг проявляется стабильно? На столе? В поле у заказчика? Прошивал один и тот же человек? Отладочный UART или что-то подобное есть?
Для примера дебага, можно завести внешнюю собаку на какой-нибудь пин (не на RST) МК, настроить прерывание по этому пину и ждать.
В AVR (вроде как?) внутренний WDT умеет не сбрасывать сразу контроллер, а выдавать прерывание, в котором можно сбросить МК.
Короче, в этом прерывании выплюнуть в отладочный UART содержимое фрейма стека и регистров. Хотя бы знать где зависает.

[haker_fox 60]

On 11/4/2020 at 3:28 AM, dontsov said:

Как убедиться в том, что Attiny85 корректно прошилась?

Давно бросил аврки, но посмотрите в доке на avrdude как заставить его верифицировать зашитое.

On 11/4/2020 at 3:28 AM, dontsov said:

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

Если вас устраивают стандартные, то не нужно.

On 11/4/2020 at 3:28 AM, dontsov said:

Стоит ли поставить Atmel Studio и можно ли там воспроизвести подобное поведение? 

А если проблема в железе?

On 11/4/2020 at 3:28 AM, dontsov said:

Буду рад любым советом, чтобы сделать устройство более надежным!

1. Трассировка печатки. Выкладывайте на форум трассировку.

2. Хорошие схемотехнические решения. Выкладывайте на форум схемы.

3. Подключайте отладчик, когда зависнет, смотрите, где висит. Хотя куда его там подлкючать, все ножки заняты. Ведь что есть зависание? Просто выполнение программы не предназначенной для выполнения, например, случайный бесконечный цикл. Аппаратные зависания тоже встречаются, когда схема микроконтроллера не может изменить своё состояние.

4. Любое промышленное устройство, да и не только промышленное, должно быть испытано в лаборатории на ЭМС и помехоэмиссию. Без этого гооворить о том, что создано устройство даже и не стоит.

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

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

03.11.2020 в 21:28, dontsov сказал:

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

Если они остаются теми, которыми были до программирования - не нужно. Но кто даст гарантию, что до программирования они находятся в состоянии "с завода"? Всегда есть вероятность, что вам продали микросхемы, снятые с нераспроданных плат в Китае и что их кто-то уже программировал до вас. Прошивка фузов - еще несколько ключей в командной строке дудки, неужели настолько лень потратить 15 минут, чтобы прочитать документацию, один раз сформировать правильные ключи и быть на 100% уверенным, что после программирования фузы будут  именно в том состоянии, которое нужно вам?

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

[dontsov 0]

11 hours ago, heavyC1oud said:

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

До этого не было проблемы. Наводки, погодные условия - нет: проверили остальную часть партии дома, есть зависшие образцы.
Перепрошили часть партии повторно, ждём, будет ли ошибка.

 

[haker_fox 60]

8 minutes ago, dontsov said:

Наводки, погодные условия - нет:

Ничего не понятно. Вы тестировали свои счётчики на ЭМС?

[dontsov 0]

2 hours ago, Arlleex said:

Да хоть десять лет. Баги - штука долгоиграющая

 

Аминь. Но почему у сотни людей этого бага не было? Там простая программа - цикл, выход из него при достижении счетчика 0 или при нажатии кнопки. 

2 hours ago, Arlleex said:

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

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

2 hours ago, Arlleex said:

встраивать самый простейший загрузчик

Ох, я так не умею еще.

2 hours ago, Arlleex said:

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

Теперь будут. Фьюзы по умолчанию работают.
В глючном устройстве фьюзы были корректные.

2 hours ago, Arlleex said:

Воспроизвести как? В железе? В симуляторе? Если есть конкретный баг - то в симуляторе, возможно, придется конкретно постараться.
Но я не люблю, допустим, симуляторы - толку от них как от козла молока. Идеально - отлаживаться в железе.
Но не думаю, что Tiny такое может. Хотя, как помню, там был какой-то однопроводной интерфейс отладки - копайте в эту сторону.

Понял. Да, есть однопроводный. Не изучал.

2 hours ago, Arlleex said:

Это Вас надо спросить. По-хорошему - нет. Собака сделана для перезагрузки по еще не обнаруженному багу.
А значит - заплатка и костыль. Оставлять такое - такое себе. Но смотрите сами - если Вас удовлетворяет сей костыль - ок.

Я согласен, что это костыль. Но надежность превыше всего. 

2 hours ago, Arlleex said:

А баг проявляется стабильно? На столе? В поле у заказчика? Прошивал один и тот же человек? Отладочный UART или что-то подобное есть?

Он впервые выявлен в этой партии. До этого было несколько сотен устройств + устройство собирали другие люди индивидуально. Баг и на столе и у клиента. Прошивал один и тот же человек глючные устройства. Нет, отладки нет - все пины заняты.

 

[haker_fox 60]

4 minutes ago, dontsov said:

Но почему у сотни людей этого бага не было?

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

6 minutes ago, dontsov said:

Он впервые выявлен в этой партии

Сравните аппаратное обеспечение, раз программное не менялось: от компонентов до трассировки и изготовления печатки.

[dontsov 0]

56 minutes ago, Сергей Борщ said:

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

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

[Arlleex 131]

А где тот самый критерий, по которому судите, что заглох именно МК а не ESP?
Не совсем понятна логика работы МК в связке с ESP. Кнопка подключена к МК?
Что происходит когда нажимается кнопка? МК должен что-то сделать? Лапку, как я понял, поднять?

[dontsov 0]

29 minutes ago, Arlleex said:

А где тот самый критерий, по которому судите, что заглох именно МК а не ESP?
Не совсем понятна логика работы МК в связке с ESP. Кнопка подключена к МК?
Что происходит когда нажимается кнопка? МК должен что-то сделать? Лапку, как я понял, поднять?

Заглох именно МК: Кнопка подключена к МК, по нажатию поднимает питание ESP. ESP пробовали менять - нет разницы. После замыкания Attiny пина Reset на GND, устройство оживает.

[Arlleex 131]

1 час назад, dontsov сказал:

Заглох именно МК: Кнопка подключена к МК, по нажатию поднимает питание ESP. ESP пробовали менять - нет разницы. После замыкания Attiny пина Reset на GND, устройство оживает.

Ну, короче... Отладчик подключайте и смотрите под ним.
Неужто в отладочный целях нельзя кратковременно взять один пин МК под светодиод?
Поставить в интересующие участки кода (ветки, которые якобы никогда не должны сработать) - хоть что-то.

[jcxz 184]

По старту ПО запрограммировать любой удобный пин МК как UART.TX и выплюнуть в него содержимое ОЗУ и пр. полезное. Можно использовать даже занятый пин - после выдачи дампа переключить его уже в рабочий режим и работать как обычно. А когда случится зависание: жмёте (и удерживаете) RESET, подключаете к данному выводу терминалку (ПК), отпускаете RESET, сохраняете и анализируете дамп.

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

[haker_fox 60]

1 minute ago, jcxz said:

ыплюнуть в него содержимое ОЗУ и пр. полезное

Только делать это надо до инициализации clib или что там у автора. А то глобальные переменные инициализируются нулём. Встречал кривые стартапы, которые вообще чистят всё ОЗУ.