Обычно внутренние подтягивающие резисторы выходят из строя? или что заставило бы их стать прерывистыми?

У меня есть плата на базе ASIC ARM Cortex-M3, которая после нескольких месяцев работы неожиданно начала сообщать о ложных нажатиях кнопок. ASIC - это не наш дизайн, а уважаемая компания.

Схема кнопок приведена ниже. Контакт настроен как вход с включенным подтягивающим резистором. Значение резистора составляет около 30 кОм.

Когда я измеряю сторону выводов с помощью цифрового мультиметра, я вижу, что значение плавает вокруг. Иногда оно составляет 3,2 В (= VCC, диапазон микросхем: от 2,1 до 3,6 В), а в другое время колеблется между 0,6 В и 1,0 В.

Нет проблем влажности / конденсации (9% относительной влажности), нет пыли или других объектов на следах. И это ЕДИНСТВЕННАЯ доска, которая страдает этим. Другие изготовленные клоны этой платы работают без проблем (так или иначе).

Единственное, о чем я могу думать, это то, что что-то заставляет внутреннее мерцание подтягиваться. Обычно внутренние подтягивания уступают? Что еще может быть причиной этого?

R9, R12 - 2,2 кОм, а C10, C11 - 33 нФ.

Похоже, что вы приложили некоторые усилия, чтобы изолировать свои входные контакты от коммутаторов, но, тем не менее, чрезмерное событие ESD могло повредить некоторую часть схемы драйвера / приемника контактов на чипе (и не обязательно, в частности, отладочного устройства) ,

Если вы хотите сделать это более надежным, вы можете рассмотреть возможность добавления внешних зажимных диодов, ферритовых шариков или даже транзисторного буфера между коммутатором и выводом.

Статистика твой друг. Я понял, у вас вышло из строя устройство, вам интересно, это моя вина? безопасно грузить в объеме? что произойдет, если это действительно проблема, и мы отправим 10000 единиц в поле? Все признаки того, что вы дерьмо и что вы, вероятно, добросовестный дизайнер / инженер.

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

Это ОУР. Могу ли я доказать, что это ОУР? - Может быть, а может и нет - если вы отправите мне часть, а я потрачу большие $$, чтобы отделить ее и провести через различные тесты, такие как SEM и SEM с улучшением контрастности поверхности, может быть. У меня было много случаев, когда я сознательно отключал устройство в рамках квалификации ESD, устройство выходило из строя, и все же потребовались добрые 30 часов, чтобы найти точку отказа. Было важно понять механизмы отказа и энергию активации, поэтому охота была необходима (если она явно расточительна), но половину времени мы не могли увидеть точку отказа. И это было после анализа FMEA и проектируемого устранения местоположения.

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

Фактически во время тестов ESD мы используем уравнение Аррениуса для прогнозирования отказа. Мы запариваем устройства на разных уровнях и разных моделях (исходных импедансах), а затем готовим маленькие часы в течение нескольких часов и отслеживаем их с течением времени, чтобы иметь возможность подобрать режим отказа и таким образом предсказать будущую производительность. Вы можете легко иметь тысячи чипов на платах, которые месяцами работают в камерах окружающей среды. Это все часть «квалификации» - то есть квалификации.

Ключевым эффектом, который мы всегда ищем для режимов _some_failure, является EOS (Электрическое перенапряжение). Это может быть вызвано ОУР или другими ситуациями. В современных процессах допустимая погрешность EOS на уровне затвора внутри микросхемы может составлять максимум 15%. (Вот почему запуск чипа на предназначенной для него рейке MAX Vss так важен). EOS может проявиться через несколько месяцев. Тепло от работы было бы похоже на мини-ускоренное испытание на срок службы (вы просто не применяете уравнение Аррениуса и оно не контролируется).

Если вы хотите лучшего понимания, посмотрите стандарты JEDEC ESD22, которые описывают MM (модель машины) и HMB (модель человеческого тела), которая описывает тестовые зонды и зарядку.

Вот фрагмент модели из JEDEC JESD22-A114C.01 (март 2005).

Вы как-то заметили, как это похоже на вашу схему? и значения даже довольно близки, и это используется с правильными уровнями напряжения, чтобы выбросить дерьмо из структур ESD.

Итак, что вам нужно сделать, это:

-scrap that board
- track it's provenance, lot number and who handled it
- keep this info in a database (or spreadsheet)
- note in dB that you suspect ESD
- track all failures
- check the data over time.
- institute manufacturing controls so you can track.
- relax - you're doing fine.

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

WIDGET_PIN_PORT->PULLUPS |= WIDGET_PIN_PULLUP_MASK;

и прерывание делает что-то вроде:

GADGET_PIN_PORT->PULLUPS |= GADGET_PIN_PULLUP_MASK;

где WIDGET_PIN и GADGET_PIN - это разные биты на одном и том же порту ввода / вывода. Основной код будет переводиться как-то вроде

ldr r0,= [[address of port pullup register]]
ldr r1,[r0] ; ***1
orr r1,#WIDGET_PIN_PULLUP_MASK
str r1,[r0] ; ***2

Если прерывание происходит после, ***1но до этого ***2, тогда подтягивание GADGET_PIN включается прерыванием, но затем ошибочно отключается кодом основной линии. Есть два способа избежать этой проблемы:

1. Используйте аппаратное обеспечение, которое может позволить установить бит подтягивающего регистра, используя одну инструкцию, а не последовательность чтения-изменения-записи. Я полагаю, что все контроллеры на основе Cortex-M3 предоставляют функцию «битовой синхронизации», которую можно использовать для этой цели, хотя мне еще не удалось найти какой-либо хороший способ использовать ее из кода, написанного на C, кроме ручного определения бит адреса. Некоторые другие процессоры могут иметь специальные средства ввода-вывода для выполнения аналогичной задачи.

2. Отключить прерывания во время последовательности чтения-изменения-записи порта. Например, замените приведенный выше код C на вызов метода

   void set32 (uint32_t volatile * dest, значение uint32_t) {uint32_t old_int = __get_PRIMASK (); __disable_irq (); * dest = * dest | ценность; __set_PRIMASK (old_int); }

Этот код приведет к очень кратковременному отключению прерываний (вероятно, около 5 инструкций); это достаточно кратко, чтобы не вызывать проблем даже с относительно критичными по времени прерываниями. Обратите внимание, что компиляция вышеуказанного метода как встроенного может сократить время, необходимое для его вызова, но может увеличить время, в течение которого прерывания отключены [например, если оптимизатор переставляет код, чтобы инструкция, загружающая адрес, destне выполнялась происходит до тех пор, пока после __disable_irq ()].

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

Некоторые из предыдущих ответов упускают из виду наиболее очевидные: проверьте паяные соединения на наличие кнопок, резисторов, конденсаторов и uC. Под микроскопом вы можете увидеть трещины паяного соединения.

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