Глюки контроллера. Ответ на загадку

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

Итак, девайс глючил. Причем глючил очень и очень характерно для срыва стека. Не зря первая половина поста была про поиск программной ошибки. Что такое срыв (он же переполнение) стека? Это когда стековая область памяти разрастается и начинает затирать область переменных. В результате может начаться полное веселье. Запороло переменные состояний автоматов? Получай наркоманскую логику. Запороло строковые данные — получи бред и кракозябры на экране (мой случай). Запороло видеопамять — здравствуй психоделичные картинки. Впрочем, тут и не в стеке может быть дело. Неправильно обращаясь с указателями можно навертеть такой же поебени. Суть одна — у нас каким то образом похерилась оперативная память. Не зря я полез первым делом проверять код. Но ничего не нашел.

Тут, конечно, можно до посинения отлавливать баги в программе, если бы не одно но — программа не глючила на столе. А глючила в поле. Отсюда первое соображение — виновато железо. Причем не в виде воздействия его на логику работы, ну там с протоколом ошибся или еще как налажал, опять же, в коде. А как то на электрическом уровне. Помехи, наводки и прочие пакости реального мира.

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

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

А вот что почти всегда разрушает логику контроллера изнутри, так это помехи на тактирование. Система тактирования, как нервная система, пронизывает весь контроллер, все его блоки. Она отвечает за все. Мега у нас довольно медленная, 16Мгц ее официальный предел. А теоретический? Что будет если на вход тактирования пролетят иголки, по своей частоте эквивалентные, скажем, тактовой частоте на 100мгц? Как на нее среагирует логика контроллера? Как то да среагирует. Где то триггеры успеют переключиться, где то нет, где то возникнет гонка сигналов, рассинхронизация и черт знает еще что. Это ненормированный режим. Никто не знает какие именно, но будут глюки, гарантированно. И глючить тут может вообще что угодно. У меня, в данном случае, портилась оперативка. Это из самых очевидных и явно наблюдаемых приколов. Еще слетала еепромка, но реже. Иногда просто зависала, до пинка собаки.

А раз так, значит смотрим на кварц и видим ту самую лажу. В результате передвижений дорожек, элементов, чтобы высвободить место под новые разъемы, у меня как-то перераспределилась земля, а я этого не заметил. И образовался хороший такой сквозняк для наводок в аккурат между ног кварца. Т.е. все дерьмо, генерируемое искрящими контактами реле давления, наводилось на подводящие питание провода (жирные такие пятаки слева вверху) красиво лилось сквозь кварц в нижнюю часть платы. Уходя там через провода 1-wire термометра.


Увеличить

А проц от этого тихо охреневал и давился. С веселыми последствиями. Проверяется эта идея очень легко и быстро. Берем и перешиваем проц на работу от внутреннего RC генератора. Раз и все работает, ну кроме того, что из-за плавающей частоты RC у нас глючит обмен данными по RS485 шине, т.к. она асинхронная. Кварц нужен. А значит надо вылечить плату. Решение было проще некуда. Берем и перерезаем путь этим помехам:

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

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

26 thoughts on “Глюки контроллера. Ответ на загадку”

  1. Сплошной полигон тоже штука забавная. Как экран да, хорошо. Но если его использовать как «землю»в разных его точках, то возможны интересные явления… Давеча делал аудио ЦАП, и звуковую часть накрыл таким сплошным полигоном, заодно земли компонентов фильтра и земли стабов питания попали на этот полигон в разных местах. Как оно фонило! Жуть! Решил проблему просто — разделив (разрезав) этот полигон на отдельные участки, отходящие от одной точки земли питания до потребителей. Профит!

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

  2. > Я не помню ни одного случая в своей практике, чтобы шум в питании портил оперативку в контроллере. Вот ни разу. Если у кого такое было, поделитесь.

    Я как-то столкнулся с тем, что шум в питании приводил к ложным срабатываниям прерываний на STM32 (банальное считывание кнопок). Думаю, возможна косвенная порча — в SPI единичка на нолик поменяется к примеру, и это запишется в память.

    1. Нет, скорей это прыжки уровня земель. Т.е. срабатывания кнопок были валидные, но вызыванные не нажатиями на кнопку, а изменением уровня из-за прыжка земли. Помехи на интерфейсы это тоже не про то.

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

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

    1. У меня нет, но есть одна очень хорошая статья. В прошлом посте ссылку на нее Михаил разместил, погляди в комментах там.

  4. Хм. Я думал что причиной была наводка на петлю земли: пад_под_процем -> конденсаторы_кварца -> между_ногами_D4 -> GND_2 -> GND_1 -> GND_3 -> С13 -> правый_верхний_угол_проца -> пад_под_процем.

    1. Нет, значительную роль играли провода земли, подходящие со стороны 1-wire и источника. Если на них надеть ферритовые кольца, то даже не разрезая дорожки, можно было снизить количество сбоев в десятки раз.

  5. для этого есть хорошая практика подключать нагрузочные конденсаторы отдельной дорожкой и окружать их вместе с кварцем polygon cutout зоной. + не просто так в корпусах где много ног около кварца стоит пин gnd без пина vcc.

  6. > Я не помню ни одного случая в своей практике, чтобы шум в питании портил оперативку в контроллере. Вот ни разу. Если у кого такое было, поделитесь.

    У меня был случай году в 2012, когда от помех по питанию стирался Flash у Atmega64. Я тогда только начинал разбираться в электронике, а сам девайс (GPS-трекер) был не моей разработки, я их только серийно устанавливал в автобусы и спецтехнику. И на одном из автобусов первая страница Flash у контроллера слетала регулярно и девайс зависал. Было перепробовано около 6 разных экземпляров, результат один и тот же — в течение недели первая страница забивалась мусором и девайс отваливался. Сам девайс находился в нише, полностью окруженной металлом кузова автобуса, две антенны были выведены на крышу, подключено только питание. В чем было дело выяснить так и не удалось, уволился я от туда.

      1. Так в том и дело, что флеш не записывался во время работы. Там для хранения данных стояла карта MicroSD по SPI подключенная.И вообще, на сколько я помню, в AVR нельзя просто так взять и записать флеш, нужно запускаться в загрузчике, поставив предварительно какие-то фьюзы, забыл уже что и как там. А тут иногда за пол-дня вышибало девайс. Изредка это проявлялось на всех автобусах, но на одном конкретном регулярно. Я мог утром поставить, а вечером уже не работало. Обращался к разработчикам, ответ был «Не может быть такого! Присылайте неисправный, будем смотреть». Что это было они так и не ответили, но, учась на чужих ошибках, я всегда стараюсь всё питание по максимуму утыкивать керамикой разного номинала и делать земляной полигон на всю плату с максимальной связностью, чтобы никакая дрянь не пролезла.

  7. Тут по ходу достаточно обеспечить соединение соединение общей точки конденсаторов, которые к кварцу, и ножки контроллера отдельной дорожкой. Т. е. чтобы никакие другие токи, кроме тактовой частоты, через этот участок не могли протечь. И в непосредственной близости от выводов питания и GND контроллера должны быть блокировочные конденсаторы, хотя-бы 0,1 мкФ. Причём их блокировочный эффект будет заметно портить индуктивность проводников, которыми блокировочные конденсаторы будут подключаться к микросхеме. Поэтому лучше сделать так, чтобы питание приходило на блокировочный конденсатор, а уж потом с выводов блокировочного конденсатора дорожки подходили к выводам микросхемы. Кстати, если посмотреть на ту же ATmega64, да и вообще другие контроллеры, там рядом возле каждого из выводов питания есть своя GND. Это не просто так, а чтоб именно блокировочный конденсатор удобно туда можно было бы правильно влепить.

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

  9. Когда только начинал один из проектов на mege128 столкнулся с такими же проблемами). Опыта было мало и спросить не у кого. Очень помогла статья на сахаре http://caxapa.ru/lib/emc_immunity.html В принципе если вчитаться и уяснить основные моменты, то можно избежать 90% проблем. Ну и RC цепь на контакторе может спасти даже при очень бестолковой разводке платы.

  10. Бывали разные случаи:
    1) У кварцевых генераторов, залитых снизу компаундом, на ярком свете (даже через 1мм fr4) уходила частота;
    2) Вторая малина зависала от искрения на контактах реле. Реле были на мезонине, полностью гальванически развязаны. Так и не понял, от наводок, или тоже от света. Даже фотовспышкой проверял))) В итоге просто переделал.

  11. Я вот тут подумал… А если бы все полигоны были пронизаны большим количеством переходных отверстий, по сути, соединяясь между собой во множестве точек, то глюк бы не проявился? Ведь тогда бы не было таких «путей», всё было бы максимально «стянуто» между собой.

Добавить комментарий

Ваш e-mail не будет опубликован.

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.