Моя система тестирования и повышения качества GSM-шлюза. Часть вторая



    В первой части статьи я рассказал предысторию 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. Другие вещи, например определение эл. параметров каждого пина, также пришлось превратить в «магические цифры», добавив какое-то заключение по каждому пину. Меня производство до сих пор критикует, что есть немало непонятных значений, но это такой компромисс. Что-то осталось, просто потому что так криво было сделано, и переделывать уже поздно — люди к этому привыкли.

    Описание лога тестирования



    Включение и служебная информация

    При старте тестовой прошивки выдаются заголовок и даты компиляции всех файлов, входящих в проект. Далее выдаётся уникальный номер Chip ID в трёх форматах, два из которых защищены от ручной модификации 16-битным хешем, который считается двумя разными алгоритмами.

    Далее выводится серийный номер, и по нему определяется тип шлюза и выбирается профиль тестирования. На данный момент есть три типа шлюзов: с записью разговоров, без записи разговоров, малоразмерный и бюджетный без записи разговоров и без USB. Схемотехника всех трёх одинаковая, за исключением наличия USB и SD-карты.

    Далее проверяется флаг первого запуска и сбрасывается. Если запуск первый, то прогоняются все тесты. Если нет, то выдаётся меню c вариантами запуска.

    Проверка кварца тактовой частоты

    Проверяется следующее: запущен ли внешний кварц на 8 МГц, не сработала ли защита по нестабильности кварца, запущены ли оба PLL и работают стабильно, соответствует ли итоговая частота требуемой. Одно PLL для периферии и ядра умножает частоту до 160 МГц, а другое — делит частоту до 256 кГц для цифрового I2S звука в GSM-модуль.
    Только после проверки тактовой частоты имеет смысл проверять остальные параметры.

    Проверка часового кварца

    Запускается часовой кварц, выводится время, за которое он запустился. Далее измеряется одна секунда в тактах основной частоты, и подсчитывается отклонение в миллионных долях (ppm) относительно основной частоты в 160 МГц.

    Проверка основных напряжений

    В течение секунды делаются 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 — температура и её изменение после второго измерения после прогона всех тестов (шлюз не должен нагреваться).
    Эти измерения делаются дважды: в начале всех остальных тестов и после них. Это сделано для того, чтоб проверить, что после остальных тестов аппаратура вернулась в исходное состояние. Измерение температуры контролирует самонагрев или остывание платы, если её поставили на тестирование сразу после сборки и оплавки в печи.

    Проверка на КЗ ножек МК к земле или питанию

    Проверяются все ножки МК, даже не подключенные. Это сделано для контроля качества пайки.
    Проверяются записью «0» и проверкой, что «0» считывается. Далее записывается «1» и проверяется считывание «1». Так 100 раз, потому что к ряду ножек подключена разная периферия, которая может дать ложное срабатывание при однократном тесте.

    Проверка на КЗ соседних ножек МК между собой

    Аналогично предыдущей проверке, только запись производится на одну ножку МК, а чтение — из соседней. Также выполняется 100 попыток: 50 из них в одном направлении, 50 — в другом. Числа обозначают успешные попытки. Значения 25...50 получаются, потому что часть ножек подключено к работающей схеме, и в них подается фиксированное значение «0» или «1», поэтому часть тестов выявляют ложное срабатывание. Из-за этого порог выбран близко к 100.

    Проверка электрических параметров ножек МК

    А вот тут магия, которая работает так:
    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 — состояние ножки не зависит от действий на ней;
    • (пустая строка) — состояние определить не удалось (например на ножке, к которой подключен выход ОУ звука с линии).


    Проверка двухцветных светодиодов

    Каждый двухцветный светодиод представляет собой два встречно-включённых светодиода разных цветов. Суть проверки заключается в том, что на одну ножку светодиода подаётся 1 или 0 или подтяжка на землю или питание, либо высокий импеданс. А на другой ножке светодиода проверяется реакция электрического состояния на это воздействие. Далее они меняются местами и по результатам выносится решение.
    Например, на 62 выводе включаем подтяжку к питанию «VD1_MCU_62 pull up», замеряем состояние 61 вывода — оно стало так же с подтяжкой, но высокоомной «VD1_MCU_61 Pull_UP_M».

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

    В следующей части я расскажу, как проверяется телефонная линия (источник напряжения, выдача и приём звука), SD-карта, питания под нагрузкой и как вычисляются их параметры. А в конце статьи сделаю выводы и заключения по тестовой прошивке.
    Share post

    Similar posts

    Comments 6

      +4
      У меня наступил полный когнитивный диссонанс. Уже прошла неделя или нет с тех пор как отсюда выпилили все Hardware Хабы, объявив что они не имеют никакого отношения к разработке?
      Потом выпустили отдельную статью, в которой сообщили что возврата назад точно не будет. С тех пор точно не прошло недели, как появляется вот эта статья. Она теснейшим образом связанная с железом, не смотря на то, что автор всеми силами старался обойти Hardware часть. Кстати благодаря этому моменту достаточно сильно пострадало качество и информативнось статьи. Что он так мерит, как он там на самом деле мерит приведённые куски листингов мало о чём говорят. Насколько достоверны его измерения, например значение 11 592 mV? Зачем надо мерить со скоростью 100 000 измерений в секунду, ведь известно что без соответствующих входных фильтрах чрезмерно высокая частота измерения только лишние шумы порождает…
      В общем в таком «урезанном» виде статья получилась практически не о чём.
      Кстати, в первой части были схемы и очень много схем, в результате читалась она намного более интересно! Но вопрос, почему тогда её не выпили с Хабра до сих пор, ведь она неразрывно связана с железом? Я не понимаю по какому принципу были разделены даже мои статьи. Многие, в которых рассказывалось именно про схемотехнику и специально были написаны для хаба схемотехника были выдраны из этого хаба и оставлены почему то на хабре.
      Я больше вообще не понимаю куда и что писать о разработке, поэтому собственно перешёл до прояснения обстоятельств в GT на космическую тему. Снова всё пихать в унивесальный хаб разработка? Так зачем в таком случае надо было железные хабы выпиливать?
      Хотелось чтобы всё таки администрация прояснила свою позицию в вопросе публикации статей.
      Возможно она всё таки допускает что разработка в области Hardware тоже является разработкой, но пытается отделить её от тех кто занимается электроникой в виде хобби?
      В таком случае можно конечно и дальше «партизанить», публикуя подобные статьи на Хабре как я собственно и делал до появления хаба схемотехника но уже надоело просто писать статьи и не знать то ли на бан нарвёшься, то ли статью «выпилят» или всего лишь перенесут в другое место с личным предупреждением.
      Я пишу этот коммент не в плане критики администрации, мне просто хочется понять куда и какие статьи можно и следует писать, а то сейчас доходит уже до маразма — перед написанием статьи приходится консультироваться с администратором на тему куда её можно поместить!
      P.S. Кстати, что за термин такой «промышленное программирование» и чем он лучше программирования микроконтроллеров и не включает ли их в себя?
        +1
        Пожалуйста успокойтесь, и поглядите весь лог: описана 1/3, очень кратко и уже очень много всего. Я планирую выпустить статьи несколькими частями. Иначе будет сверхдлинная простыня текста. Описание тестового лога полностью готово, и следующую часть я выложу как только завершится обсуждение этой части.
        Если интересны исходники, осцилограммы и тех подробности, пожалуйста запрашивайте, отдельными статьями расскажу про что-то одно. Но только после того как закончу этот цикл.

        Насколько достоверны его измерения, например значение 11 592 mV? Зачем надо мерить со скоростью 100 000 измерений в секунду, ведь известно что без соответствующих входных фильтрах чрезмерно высокая частота измерения только лишние шумы порождает…

        Цель замерить постоянную составляющую и шумы. Они достоверны с точностью 1%. Про достоверность я приведу пример в последней части где будет дан пример разбора рабочей ситуации с производства. Пожалуйста, наберитесь терпения, не всё сразу. А насчёт входных фильтров и ёмкостей есть интересная статья.
          0
          Пожалуйста успокойтесь

          Я спокоен как никогда, чего и вам желаю
          0
          У меня наступил полный когнитивный диссонанс. Уже прошла неделя или нет с тех пор как отсюда выпилили все Hardware Хабы, объявив что они не имеют никакого отношения к разработке?


          Я может что пропусти, можно ссылку на это объявление.
        0
        Спасибо, жду третью часть.
        Мы используем похожие подходы, но для каждого устройства разрабатываем автоматизированный стенд. GSM модем раньше проверяли GSM-тестером, но потом поняли, что это избыточно — теперь только измеряем выходную мощность.

        Какова длительность цикла тестирования одного устройства (включая программирование основной прошивки после удачных тестов)?

        Only users with full accounts can post comments. Log in, please.