Тесты чтения I2C WinRT (требуется EEPROM)

Статья
06/19/2023

Тесты I2C выполняют функциональное и нагрузочное тестирование контроллеров I2C, предоставляемых пользовательскому режиму через API WinRT Windows.Devices.I2c. Тесты разделены на две части : базовые функциональные и нагрузочные тесты, а также расширенные функциональные тесты. К область тестирования базовых функциональных тестов относятся:

Убедитесь, что контроллер I2C с указанным понятным именем доступен из пользовательского режима.
Проверка правильности записи данных в диапазоне частот и длине буфера до 8 байт (размер страницы EEPROM).
Проверка правильности считывания данных в диапазоне частот и длины буфера.
Убедитесь, что последовательности записи, перезапуска и чтения (WriteRead) выполняются правильно в диапазоне частот и длины буфера.
Убедитесь, что при попытке записи, чтения или записи на неподтверждаемый ведомый адрес драйвер возвращает STATUS_NO_SUCH_DEVICE. I2cDevice::Write/Read/WriteRead() сообщает как HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND) и I2cDevice::WritePartial/ReadPartial/WriteReadPartial() как I2cTransferStatus::SlaveAddressNotAcknowledged.
Проверка правильности работы API и драйверов в условиях стресса. Нагрузочные тесты записывают и считывают данные из двух EEPROM одновременно с отдельными дескрипторами устройств в течение длительного времени.

К область тестирования расширенных функциональных тестов относятся:

Проверка правильности записи данных для буфера длиной до 16384 байт.
Проверка того, что условие перезапуска I2C создано в ответ на последовательность WriteRead.
Убедитесь, что, когда в подчиненном устройстве NAK в то время как master по-прежнему записывает байты, драйвер завершает запрос с STATUS_SUCCESS и сообщает фактическое количество байтов, записанных с помощью сведений о запросе. Это называется частичной передачей и сообщается writePartial() и WriteReadPartial() как I2cTransferStatus::P artialTransfer.
Проверка того, что часы могут растянуться до 500 мс и не приводят к сбою передачи.
Убедитесь, что, когда подчиненное устройство удерживает линию часов в течение длительного времени (более 10 секунд), драйвер завершает передачу в течение не более 10 секунд с кодом сбоя. Код сбоя должен быть STATUS_IO_TIMEOUT, но он не проверяется из соображений совместимости.

Базовые функциональные тесты и стресс-тесты выполняются для двух внешних подключенных EEPROM. Расширенные функциональные тесты выполняются для mbed LPC1768 с пользовательским встроенным ПО. Mbed LPC1768 — это популярная платформа создания прототипов микроконтроллера, которую можно приобрести в различных интернет-магазинах, включая Sparkfun, Digikey и Adafruit. Обновление встроенного ПО mbed выполняется так же просто, как перетаскивание файла. Исходный код встроенного ПО доступен на сайте GitHub. Ниже приведены инструкции по подготовке mbed и выполнению тестов.

Сведения о тесте


Характеристики	Device.BusController.I2C.WinRT.Discretional
Платформы
Поддерживаемые выпуски	Windows 10 Windows 10 версии 1511 Windows 10, версия 1607 Windows 10 версии 1703 Windows 10 версии 1709 Windows 10 версии 1803 Windows 10, версия 1809 Windows 10 версии 1903 Следующее обновление до Windows 10
Ожидаемое время выполнения (в минутах)	5
Категория	Разработка
Время ожидания (в минутах)	10
Требуется перезагрузка	false
Требуется специальная конфигурация	Да
Тип	automatic

Дополнительная документация

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

Дополнительная документация по Device.BusController

Запуск теста

Выполнение базовых функциональных и нагрузочных тестов

Для выполнения тестов потребуется следующее оборудование:

Atmel AT24HC serial EEPROMs qt. 2
10k резистор qt. 2
монтажная плата;
Проводка

Подключите EEPROM, как показано на следующей схеме, и подключите SDA и SCL к тестируемму устройству.

Схема i2c eeprom

Теперь вы можете запланировать базовые функциональные и стресс-тесты от менеджера HLK.

Выполнение расширенных функциональных тестов

Расширенные функциональные тесты проверяют поведение NACKing, состояние зависания шины, растягивание часов и повторяющиеся запуски. Тесты требуют подключения mbed LPC1768 с пользовательским встроенным ПО к тестируемму устройству. Перед выполнением тестов необходимо загрузить встроенное ПО HLK на mbed LPC1768. Ниже описано, как обновить встроенное ПО.

Подключите mbed LPC1768 через USB к компьютеру. Он будет отображаться в виде извлекаемого диска на компьютере.
Откройте диск в проводнике
Скопируйте c:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Tests\x86\iot\busses-tester-mbed_LPC1768.bin в mbed
Нажмите кнопку на mbed, чтобы сбросить микроконтроллер.

Затем подключите mbed к тестируемму устройству. Подключите mbed через USB к тестируемму устройству. Затем установите подключения I2C (закрепление mbed),

Подключение pin 9 mbed (P0.0/SDA) к контакту SDA на тестируемом устройстве
Подключение pin 10 mbed (P0.1/SCL) к контакту SCL на тестируемом устройстве
Подключение mbed GND к контакту GND на тестируемом устройстве

Mbed имеет внутренние подтягивающие резисторы, включенные на линиях SDA и SCL, и не требует внешних резисторов подтягивания.

Теперь вы можете запланировать расширенные функциональные тесты от диспетчера HLK.

Устранение неполадок

Общие сведения об устранении неполадок при тестировании HLK см. в статье Устранение неполадок тестов HLK в Windows.

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

Скопируйте %programfiles(x86)%\Windows Kits\10\Testing\Runtimes\TAEF\<arch>\MinTe в c:\data\minte
Скопируйте Windows.Devices.LowLevel.UnitTests.dll из %programfiles(x86)%\Windows Kits\10\Hardware Lab Kit\Tests\<arch>\iot в папку c:\data на устройстве.
Подключение telnet или ssh к устройству
Измените каталоги на c:\data

Запустите тесты.

minte\te windows.devices.lowlevel.unittests.dll /name:I2c*

Использование тестов командной строки:

minte\te windows.devices.lowlevel.unittests.dll [/name:test_name] [/select:select_clause] [/p:I2cFriendlyName=friendly_name] [/p:Duration=duration]

test_name — имя запускаемого теста, которое может содержать подстановочные знаки. Примеры: /name:I2c*, /name:I2cEepromWriteTests#metadataSet0::VerifyWrite#metadataSet0
select_clause — предложение выбора TAEF. Пример: /select:"@name='I2c*' and not(@name='I2cTestsEx*')"
friendly_name — понятное имя тестируемого контроллера I2C. Если этот параметр опущен, используется первый перечислимый контроллер. Примеры: /p:I2cFriendlyName=I2C0
длительность — как долго следует выполнять стресс-тесты. Примеры: /p:Duration=10s (10 секунд), /p:Duration=1m (1 минута), /p:Duration=2h (2 часа), /p:Duration=1d (1 день)

Примеры:

Чтобы выполнить базовые функциональные тесты, выполните следующие действия.

minte\te windows.devices.lowlevel.unittests.dll /select:"@name='I2c*' and not(@name='I2cTestsEx*')"

Чтобы выполнить расширенные функциональные тесты, выполните следующие действия.

minte\te windows.devices.lowlevel.unittests.dll /name:I2cTestsEx::*

Чтобы выполнить тесты для конкретного экземпляра контроллера I2C, передайте понятное имя в параметр теста I2cFriendlyName.

minte\te windows.devices.lowlevel.unittests.dll /name:I2c* /p:I2cFriendlyName=I2C0

Чтобы выполнить определенный тест, передайте полное имя теста в параметр /name:

minte\te windows.devices.lowlevel.unittests.dll /name:I2cNonexistentSlaveAddressTests::TestWriteRead

Чтобы выполнить нагрузочные тесты в течение рекомендуемой продолжительности 8 часов, выполните команду

minte\te windows.devices.lowlevel.unittests.dll /name:I2cStressTests::StressIoConcurrent /p:Duration=8h

Средство, которое может помочь в устранении неполадок вручную, — I2cTestTool. I2cTestTool — это простая служебная программа для взаимодействия с I2C из командной строки.

Дополнительные сведения

Параметры

Имя параметра	Описание параметра
I2cFriendlyName	Понятное имя тестируемого контроллера I2C (например, I2C0).

Поделиться через