В первой части статьи я рассказал предысторию 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-карта, питания под нагрузкой и как вычисляются их параметры. А в конце статьи сделаю выводы и заключения по тестовой прошивке.
ссылка на оригинал статьи http://habrahabr.ru/post/264045/
Добавить комментарий