Автоматизированное тестирование аудио интерфейсов для встроенных SBC

Аудио интерфейсы теперь стали основным элементом на промышленных одноплатных компьютерах (SBC) для Интернета вещей (IIoT), охватывая как аналоговые, так и цифровые варианты. Каждый тип интерфейса приносит уникальные вызовы проектирования и тестирования, которые должны решаться на протяжении сборки и производства. Цель — проверить всю цепочку сигнала — от фронтенд IC до цифрового аудио входа процессора.

Рисунок 1 иллюстрирует типичный производственный тестовый поток для встроенного аудио фронтенда. Диаграмма подчеркивает ключевые компоненты, такие как приемник IC (аналогово-цифровой преобразователь или цифровой аудио приемник), последовательный интерфейс (например, I²S) и путь PCM данных, идущий к блоку обработки.

Рисунок 1: Тестовая установка и аудио фронтенд для встроенной платформы (Источник: Автор)

Путь данных включает несколько критических блоков. Приемник IC может быть аналоговым фронтендом, таким как ADC, или цифровым аудио приемником, и его выход может передаваться в любом последовательном формате, чаще всего I²S. Этот интерфейс несет сырые PCM аудио данные.

Производственное тестирование должно валидировать всю аудио цепочку и обнаруживать проблемы, такие как:

• Отказ фронтенд приемника IC.
• Дефекты сборки на линиях I²S (например, застревание на высоком, низком уровне или короткое замыкание пар сигналов).

Эти тесты интегрированы в комплексную систему, проверяющую все интерфейсы на встроенной плате.

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

Техника 1 — Субъективное тестирование

Субъективное тестирование захватывает несколько секунд аудио данных и полагается на человеческий осмотр для сравнения с исходным воспроизведением. Хотя подход прост, он требует ручного прослушивания, затратен по времени и плохо масштабируется для многоканальных конфигураций.

Техника 2 — Автоматизированное тестирование

Автоматизированное тестирование использует фундаментальные концепции I²S для быстрого и надежного обнаружения дефектов.

I²S работает с тремя сигналами: BCLK (битовый такт), WCLK (слово такт) и DATA. Если BCLK или WCLK застревают, процессор сообщит об ошибке такта. Даже если такты верны, застревание DATA на высоком или низком уровне заполнит аудио буфер 0xFFFF или 0x0000 для каждого 16-битного сэмпла. Генерируя MD5 контрольную сумму захваченного буфера, мы можем отличить эти случаи:

• MD5(FFFF) указывает на застревание DATA на высоком уровне.
• MD5(0000) указывает на застревание DATA на низком уровне.
• Любая другая контрольная сумма подразумевает правильный поток данных.

Рабочий процесс теста следующий:

1. Воспроизвести известное аудио через плату (убедиться, что не на mute).
2. Захватить примерно 100 сэмплов.
3. Вычислить MD5 контрольную сумму захваченного буфера.
4. Сравнить контрольную сумму с двумя эталонными значениями для обнаружения застревающих линий.

Для многолинейных I²S шин мы можем проверить каждую линию DATA независимо. Например, с четырехлинейной шиной (DATA0–DATA3) мы воспроизводим аудио только на одной линии за раз, держа остальные на низком уровне. Контрольная сумма MD5 для активной линии будет случайной, тогда как неактивные линии совпадут с MD5(0000). Таблица 1 демонстрирует этот итеративный подход.

нажмите для увеличения

Таблица 1: Итерация аудио тестирования (Источник: Автор)

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

Заключение

Эти автоматизированные техники были проверены на множестве аппаратных платформ Ittiam, последовательно сокращая время тестирования и снижая производственные затраты.

Аюсман Моханти — архитектор продукта, фокусирующийся на железе для видео и аудио вещания и систем наблюдения. Связаться в LinkedIn.