![](https://habrastorage.org/files/6b3/e9a/d14/6b3e9ad148694fcdaaba870fb1df3684.png)
В первой части статьи я рассказал предысторию FXS GSM-шлюза с записью разговора, объяснил, какие были допущены ошибки в первой версии, как были исправлены во второй версии. Сердцем шлюза стал микроконтроллер, который управляет всем: питанием, звуком (цифровым и аналоговым), телефонной линией.
В схему была внедрена функция самодиагностики. Для этого в шлюз были добавлены измерительные цепи, цепи управления питанием и подъёма телефонной трубки, цепи для нагрузочной проверки питания и критичных узлов. Для связи с ПК и перепрошивки установлен мост USB-USART, который может работать как программатор.
В этой и следующей статье я расскажу о тестовой прошивке: как она тестирует всю периферию, какие идеи были заложены в неё и как они были реализованы на примере разбора тестового лога.
Тестовая прошивка проверяет:
- Тактовые частоты, с точностью до ppm.
- Все ветки питания.
- Все ножки процессора.
- Светодиоды.
- Источник телефонной линии.
- Выдачу и приём звука с телефонной линии. АЧХ, КНИ, уровень шума.
- GSM-модуль.
- SD-карту.
Тестовый лог целиком
Я не нашёл ни одной статьи на хабре про программу производственного тестирования реально существующего изделия. Поэтому, надеюсь, я первый. Если нет, то с удовольствием почитал бы статьи других.
Элементы системы диагностики
Тестовая прошивка для первоначальной диагностики и разбраковки после сборки. Исполняется в устройстве. Делает всю диагностику без помощи ПК. Выдаёт результаты в производственную программу на ПК. При первом запуске прогоняет все тесты. При последующих запрашивает, что делать: либо прогнать все тесты, либо одну группу тестов на выбор, либо ручной режим управления.
Основная прошивка для клиентов. Исполняется в устройстве. Прошивается автоматически производственной программой после успешных тестов без единой ошибки.
Производственная программа для ПК — это комплекс из нескольких программ, который прошивает шлюз тестовой или основной прошивкой для клиента. Подключается к устройству и логирует данные с него. Посылает нажатые кнопки F1… F9, ESC в работающую прошивку. Ведёт архив логов. Ведёт логи IMEI, серийников, версий прошивок и логи действий пользователя. Подсчитывает статистику, количество ошибок. Выполняет синхронизацию между рабочими местами сборщиков, разработчика и метролога. Позволяет делать срез логов по заданному параметру и т.д. Об этом в третьей части статьи.
Тестовый эхо-шлюз — это шлюз с особой прошивкой, которая в режиме эха выдаёт в GSM-сеть принятый звук. Используется в тестовой прошивке для пробного исходящего звонка, для тестирования звука по GSM-каналу и проверки стабильности GSM-модуля.
Простая программа прошивки — упрощённая версия производственной программы, позволяет только прошить и получить лог с устройства без возможности управления прошивкой и ведения остальных логов с подсчётом статистики. Она предоставляется клиентам для диагностики. Также она позволяет обновить прошивку через наш загрузчик с шифрованием прошивки.
Веб-сервер используется для синхронизации данных, архивирования и бэкапа логов и отчётов, для выдачи прошивки GPRS-загрузчику.
Идеи, реализованные в тестовой программе
Лог, удобный для производства. В этом логе все однотипные данные должны быть выравнены в таблицы, значения подписаны понятными величинами, пределы допусков указаны. Показываются все действия, включая dummy-сообщения, которые помогают понять, зависла программа или нет.
Лог, удобный для разработчика. Выводятся промежуточные показатели, на основе которых вычисляются финальные показатели, по которым делаются заключения. В логе должна быть служебная информация: даты исходников, уникальный ID из МК.
Лог, удобный для метролога. Все измерения должны быть избыточно точными (например, милливольты, миллидецибеллы и т.д.). Это позволяет видеть, насколько близко к границе диапазона подошло значение или насколько сильно превысило границу. Если данных много и лимиты не указаны для всей строки, то выводится рейтинг показателя, который отклонился больше всех. Благодаря этому удобно глазами пробежаться по цифрам рейтинга и увидеть, что какой-то показатель подошёл близко к границе диапазона. Рейтинг — это в конце строки последняя цифра от -9 до +9, где 0 — середина разрешённого диапазона.
Индикация сбоев канала связи. Лог выводит символы только в 7-битном ASCII-режиме, только латиницей на моём кривом аглицком. Последовательный порт настроен на 8 бит с проверкой чётности. В производственной программе, которая выводит лог, все строки с символами, у которых код меньше 32 или больше 127, подсчитываются как ошибки и выводятся ярко-красным цветом.
Удобная обработка сторонними программами. Для этого все измеренные значения и таблицы значений обрамляются табуляторами. Такой формат удобно использовать в БД или Excell. Производственная программа должна уметь подсвечивать норму одним цветом, а ошибку — другим цветом. Для этого норма подписывается словом «OK», а ошибка — «ERROR». Ведётся подсчёт норм и ошибок, их статистика и индексация.
Возможность ведения статистики. Каждый параметр должен иметь своё уникальное имя. По этому имени в производственной программе можно сделать срез по всем логам, увидеть, как менялся выбранный параметр, построить график.
Самодостаточность. Тесты должны проверять множество параметров много раз и разными способами. Они должны быть избыточными. Как можно больше показателей должны дублироваться другими прямыми и косвенными измерениями, сделанными другими алгоритмами и методами. Иначе будет непонятно, что сбоит: схема, плата, сам алгоритм тестирования или неправильные действия. Да и при анализе существенно проще видеть по совокупности, чем сделать себе «замочную скважину» в одно единственное измерение.
Лог не должен быть огромным. Часть параметров пришлось сделать без подписей пределов, т.к. их очень много, а лог не должен превышать десяти страниц.
Самое сложное было совместить эти все требования. Из-за ограничения размера пришлось пожертвовать удобством для производства и сделать костыль с рейтингом -9… +9. Другие вещи, например определение эл. параметров каждого пина, также пришлось превратить в «магические цифры», добавив какое-то заключение по каждому пину. Меня производство до сих пор критикует, что есть немало непонятных значений, но это такой компромисс. Что-то осталось, просто потому что так криво было сделано, и переделывать уже поздно — люди к этому привыкли.
Описание лога тестирования
Включение и служебная информация
![](https://habrastorage.org/files/de0/77f/780/de077f7800bd4289b50b81d05ff4fb5d.png)
При старте тестовой прошивки выдаются заголовок и даты компиляции всех файлов, входящих в проект. Далее выдаётся уникальный номер Chip ID в трёх форматах, два из которых защищены от ручной модификации 16-битным хешем, который считается двумя разными алгоритмами.Далее выводится серийный номер, и по нему определяется тип шлюза и выбирается профиль тестирования. На данный момент есть три типа шлюзов: с записью разговоров, без записи разговоров, малоразмерный и бюджетный без записи разговоров и без USB. Схемотехника всех трёх одинаковая, за исключением наличия USB и SD-карты.
Далее проверяется флаг первого запуска и сбрасывается. Если запуск первый, то прогоняются все тесты. Если нет, то выдаётся меню c вариантами запуска.
Проверка кварца тактовой частоты
![](https://habrastorage.org/files/86a/131/5c9/86a1315c9689421fb5a14676d4c03a50.png)
Проверяется следующее: запущен ли внешний кварц на 8 МГц, не сработала ли защита по нестабильности кварца, запущены ли оба PLL и работают стабильно, соответствует ли итоговая частота требуемой. Одно PLL для периферии и ядра умножает частоту до 160 МГц, а другое — делит частоту до 256 кГц для цифрового I2S звука в GSM-модуль.Только после проверки тактовой частоты имеет смысл проверять остальные параметры.
Проверка часового кварца
![](https://habrastorage.org/files/91a/ebc/9ad/91aebc9ad6b84481b797cf336b88c64c.png)
Запускается часовой кварц, выводится время, за которое он запустился. Далее измеряется одна секунда в тактах основной частоты, и подсчитывается отклонение в миллионных долях (ppm) относительно основной частоты в 160 МГц.Проверка основных напряжений
![](https://habrastorage.org/files/1ee/31f/f41/1ee31ff41fba43c387f659b3281db9bc.png)
В течение секунды делаются 100 тысяч выборок по определённому каналу АЦПи вычисляются следующие показатели (слева направо):
- постоянная составляющая (в милливольтах с учётом делителей на резисторах);
- низкочастотная составляющая (если она существенно больше высокочастотной, то это наводки из сети);
- высокочастотная составляющая (если она существенно больше низкочастотной, то это треск или нестабильное АЦП);
- максимальный размах в выборках АЦП;
- рейтинг наихудшего показателя от -9 до +9.
Этот тест используется далее во многих других тестах.
Измеряемые величины:
- DIAG_SENS — датчик питания GSM-модуля (в исходном состоянии выключено и ничего не должно «пропускать» и шуметь);
- SLIC_LINEU — напряжение в телефонной линии (в исходном состоянии линия должна быть выключена и не шуметь);
- FXS_ADC — звук с телефонной линии (не выдается во время теста — значит должна быть тишина и половина питания);
- DVCC — цифровое питание МК (не должно быть шума);
- SD_VCC — цифровое питание SD-карты (должно быть выключено);
- 12V_PWR — общее питание 12 В;
- DVCC-Vbat — цифровое питание часового модуля от литиевой батарейки-таблетки;
- VrefInt — внутреннее опорное напряжение 1.2 В (им проверяется аналоговое питание и опора АЦП);
- Temp in C — температура и её изменение после второго измерения после прогона всех тестов (шлюз не должен нагреваться).
Проверка на КЗ ножек МК к земле или питанию
![](https://habrastorage.org/files/d61/6e3/812/d616e38121ef4dc4b07755aa708409de.png)
Проверяются все ножки МК, даже не подключенные. Это сделано для контроля качества пайки.Проверяются записью «0» и проверкой, что «0» считывается. Далее записывается «1» и проверяется считывание «1». Так 100 раз, потому что к ряду ножек подключена разная периферия, которая может дать ложное срабатывание при однократном тесте.
Проверка на КЗ соседних ножек МК между собой
![](https://habrastorage.org/files/846/784/5eb/8467845eb2d648da936874451fc2fae5.png)
Аналогично предыдущей проверке, только запись производится на одну ножку МК, а чтение — из соседней. Также выполняется 100 попыток: 50 из них в одном направлении, 50 — в другом. Числа обозначают успешные попытки. Значения 25...50 получаются, потому что часть ножек подключено к работающей схеме, и в них подается фиксированное значение «0» или «1», поэтому часть тестов выявляют ложное срабатывание. Из-за этого порог выбран близко к 100.Проверка электрических параметров ножек МК
![](https://habrastorage.org/files/3a1/27c/3d8/3a127c3d882e43f7b743aa2b228cf910.png)
А вот тут магия, которая работает так:1. Ножка настраивается на вывод «1», потом переводится в режим входа и измеряется время, за которое перейдёт в «0».
2. Ножка настраивается на вывод «0», потом переводится в режим входа и измеряется время, за которое перейдёт в «1».
3. и 4. Аналогично п. 1 и п. 2, но переводится в режим с подтяжкой к земле или питанию — это помогаем быстрее перейти в «0» или «1».
Этими действиями можно измерить ёмкость на ножке и наличие подтяжки, даже высокоомной. Но измерение очень грубое, потому что задержки зависят от величины подтяжки внутри МК, а она может изменится в 10 раз. Еще присутствует зависимость от температуры, которая может изменяться в широких пределах.
Значения времени представлены в логарифмической шкале. По результатам выполнения пунктов 1..4 эти значения записаны в первых четырёх числах в каждой строке.
Проверяются все ножки, включая UART. При этом по UART идут сбойные символы.
Виды параметров в этом тесте:
- hi_Z — высокоимпедансное состояние с очень малой ёмкостью, меньше 10 пф;
- hi_Z + C_pF — высокоимпедансное состояние с ёмкостью 10… 1000 пф;
- hi_Z + C_nF — высокоимпедансное состояние с ёмкостью 1… 1000 нф;
- hi_Z + C_uF — высокоимпедансное состояние с ёмкостью 1мкф и выше;
- Pull_Down — низкоомная подтяжка к земле;
- Pull_Down_M — высокоомная подтяжка к земле;
- Pull_Up — низкоомная подтяжка к питанию;
- Pull_Up_M — высокоомная подтяжка к питанию;
- FIXED — состояние ножки не зависит от действий на ней;
- (пустая строка) — состояние определить не удалось (например на ножке, к которой подключен выход ОУ звука с линии).
Проверка двухцветных светодиодов
![](https://habrastorage.org/files/80d/1f8/0a1/80d1f80a18a54192bd3979726f54f2ab.png)
Каждый двухцветный светодиод представляет собой два встречно-включённых светодиода разных цветов. Суть проверки заключается в том, что на одну ножку светодиода подаётся 1 или 0 или подтяжка на землю или питание, либо высокий импеданс. А на другой ножке светодиода проверяется реакция электрического состояния на это воздействие. Далее они меняются местами и по результатам выносится решение.Например, на 62 выводе включаем подтяжку к питанию «VD1_MCU_62 pull up», замеряем состояние 61 вывода — оно стало так же с подтяжкой, но высокоомной «VD1_MCU_61 Pull_UP_M».
Не все светодиоды включены одинаково, на некоторых есть подтяжки или другие функции. Это учитывается в логе тестирования светодиодов. Например, такое поведение можно заметить по результатам тестов, если взглянуть на полный лог и сверить его схемой МК из первой статьи.
В следующей части я расскажу, как проверяется телефонная линия (источник напряжения, выдача и приём звука), SD-карта, питания под нагрузкой и как вычисляются их параметры. А в конце статьи сделаю выводы и заключения по тестовой прошивке.
Комментарии (6)
alexpic
07.09.2015 16:12Спасибо, жду третью часть.
Мы используем похожие подходы, но для каждого устройства разрабатываем автоматизированный стенд. GSM модем раньше проверяли GSM-тестером, но потом поняли, что это избыточно — теперь только измеряем выходную мощность.
Какова длительность цикла тестирования одного устройства (включая программирование основной прошивки после удачных тестов)?
progchip666
У меня наступил полный когнитивный диссонанс. Уже прошла неделя или нет с тех пор как отсюда выпилили все Hardware Хабы, объявив что они не имеют никакого отношения к разработке?
Потом выпустили отдельную статью, в которой сообщили что возврата назад точно не будет. С тех пор точно не прошло недели, как появляется вот эта статья. Она теснейшим образом связанная с железом, не смотря на то, что автор всеми силами старался обойти Hardware часть. Кстати благодаря этому моменту достаточно сильно пострадало качество и информативнось статьи. Что он так мерит, как он там на самом деле мерит приведённые куски листингов мало о чём говорят. Насколько достоверны его измерения, например значение 11 592 mV? Зачем надо мерить со скоростью 100 000 измерений в секунду, ведь известно что без соответствующих входных фильтрах чрезмерно высокая частота измерения только лишние шумы порождает…
В общем в таком «урезанном» виде статья получилась практически не о чём.
Кстати, в первой части были схемы и очень много схем, в результате читалась она намного более интересно! Но вопрос, почему тогда её не выпили с Хабра до сих пор, ведь она неразрывно связана с железом? Я не понимаю по какому принципу были разделены даже мои статьи. Многие, в которых рассказывалось именно про схемотехнику и специально были написаны для хаба схемотехника были выдраны из этого хаба и оставлены почему то на хабре.
Я больше вообще не понимаю куда и что писать о разработке,
поэтому собственно перешёл до прояснения обстоятельств в GT на космическую тему. Снова всё пихать в унивесальный хаб разработка? Так зачем в таком случае надо было железные хабы выпиливать?Хотелось чтобы всё таки администрация прояснила свою позицию в вопросе публикации статей.
Возможно она всё таки допускает что разработка в области Hardware тоже является разработкой, но пытается отделить её от тех кто занимается электроникой в виде хобби?
В таком случае можно конечно и дальше «партизанить», публикуя подобные статьи на Хабре как я собственно и делал до появления хаба схемотехника но уже надоело просто писать статьи и не знать то ли на бан нарвёшься, то ли статью «выпилят» или всего лишь перенесут в другое место с личным предупреждением.
Я пишу этот коммент не в плане критики администрации, мне просто хочется понять куда и какие статьи можно и следует писать, а то сейчас доходит уже до маразма — перед написанием статьи приходится консультироваться с администратором на тему куда её можно поместить!
P.S. Кстати, что за термин такой «промышленное программирование» и чем он лучше программирования микроконтроллеров и не включает ли их в себя?
Mirn
Пожалуйста успокойтесь, и поглядите весь лог: описана 1/3, очень кратко и уже очень много всего. Я планирую выпустить статьи несколькими частями. Иначе будет сверхдлинная простыня текста. Описание тестового лога полностью готово, и следующую часть я выложу как только завершится обсуждение этой части.
Если интересны исходники, осцилограммы и тех подробности, пожалуйста запрашивайте, отдельными статьями расскажу про что-то одно. Но только после того как закончу этот цикл.
Цель замерить постоянную составляющую и шумы. Они достоверны с точностью 1%. Про достоверность я приведу пример в последней части где будет дан пример разбора рабочей ситуации с производства. Пожалуйста, наберитесь терпения, не всё сразу. А насчёт входных фильтров и ёмкостей есть интересная статья.
progchip666
Я спокоен как никогда, чего и вам желаю
insekt
Я может что пропусти, можно ссылку на это объявление.
progchip666
Похоже, много что пропустили
habrahabr.ru/company/tm/blog/139898
habrahabr.ru/company/tm/blog/139901