20.12.2022 18:09
Indemsys 0 522 Источник

В прошлой статье было начато тестирование чипов семейства i.MX RT. Здесь продолжаем тестировать.

Активизация работы сигнала SWO (Serial Wire Output)

Если хотим использовать все удобства отладки ARM, то нужен сигнал SWO. Но на плате MIMXRT1170-EVK с ним есть сложности и их нужно преодолеть.

Сигнал SWO является однонаправленным выходом. Этот сигнал предоставляет функции трассировки и используется для следующих целей:

  • Отсылки строковых отладочных сообщений в среду отладки

  • Записи моментов входы и выхода из прерываний

  • Записи моментов входа и выхода из функций

  • Периодическое семплирование регистра счётчика команд

  • Уведомления о событиях

  • Регистрации изменения содержимого переменных или ячеек памяти

В штатном отладчике OpenSDA, находящемся на плате, не реализовано подключение к сигналу SWO. Для работы с SWO используем внешний JTAG/SWD адаптер Segger JLink Ultra+. Этот адаптер способен принимать сигнал SWO на частоте до 50 МГц. Но чтобы его использовать надо проделать несколько манипуляций с платой и демонстрационными примерами.

Необходимые изменения на плате. Снять перемычки J5-J8. Этим мы отключаем сигналы OpenSDA внутреннего адаптера от микроконтроллера, чтобы они не конфликтовали с сигналами внешнего адаптера. Отпаиваем резистор R767. Через него к сигналу SWO подключён выход цифрового микрофона. Это такой способ мультиплексирования функций на плате, но он может мешать.

Изменения демонстрационных примеров в среде MCUXpresso IDE.

Нужно задать тактирование модулю трассировки которому принадлежит сигнал SWO (В Cortex-M7 частота трассировщика отделена от частоты ядра). Это делается обычно в функции BOARD_BootClockRUN

    /* Configure CSTRACE using SYS_PLL2_CLK */
    rootCfg.mux = kCLOCK_CSTRACE_ClockRoot_MuxSysPll2Out;
    rootCfg.div = 11; // Обычно в примерах SYS_PLL2_CLK = 528 МГц
                      // Тогда деление на 11 даст частоту трассировщика 48 МГц
                      // Частота SWO после согласования с адаптером будет 47.76 МГц 
    CLOCK_SetRootClock(kCLOCK_Root_Cstrace, &rootCfg);

И нужно активизировать непосредственно пин SWO. Это лучше делать в функции BOARD_InitPins 

	IOMUXC_SetPinMux(
	IOMUXC_GPIO_LPSR_11_ARM_TRACE_SWO, /* GPIO_LPSR_11 is configured as JTAG_MUX_TDO */
	0U); /* Software Input On Field: Input Path is determined by functionality */

	IOMUXC_SetPinConfig(
	IOMUXC_GPIO_LPSR_11_ARM_TRACE_SWO, /* GPIO_DISP_B2_07 PAD functional properties : */
	0x06U);

Важно помнить, что сразу после старта SWO не работает. Нужно запустить отладку программы и сделать точку останова после выполнения указанных выше инициализаций. После останова программы следует дать команду адаптеру на инициализацию своего канала приёма сигнала SWO. В среде MCUXpresso IDE это делается в окне SWO Trace Config кнопкой Change:

Попытка запустить работу через SWO в среде IAR Embedded Workbench for ARM

К сожалению здесь ничего не получилось. В IAR применяются свои командные макросы при старте отладки, которые самостоятельно пытаются настроить работу сигнала SWO в чипе. Но макросы эти не документированы и в версии IAR 9.30 они некорректно работают с MIMXRT1176. Уделять слишком много времени на решение проблемы не было в планах, поэтому вопрос отложен.

Тест iperf со стеком LwIP на голой платформе

Для тестирования используем утилиту на PC jperf-2.0.0 и непосредственно исполняемый файл теста IPerf 2.0.5b for Windows. Файлы IPerf надо перезаписать на место тех что идут с утилитой jperf. Проект находится в SDK в ветке boards\evkmimxrt1170\lwip_examples\lwip_iperf\bm\cm7\iar

Первый тест будет на производительность платы в режиме сервера. Плата принимает данные по протоколу TCP от PC. Тест выполняется 30 сек. Результат следующий:

Результат iperf в режиме работы платы в качестве сервера по TCP
Результат iperf в режиме работы платы в качестве сервера по TCP

Средняя скорость передачи около 350 Мбит/с

Второй тест будет на производительность платы в режиме клиента. Плата посылает данные по протоколу TCP в PC. Тест выполняется 30 сек. Результат следующий:

Результат iperf в режиме работы платы в качестве клиента по TCP
Результат iperf в режиме работы платы в качестве клиента по TCP

Средняя скорость передачи около 330 Мбит/с

Третий тест будет на производительность платы в режиме сервера. Плата принимает данные по протоколу UDP от PC. Тест выполняется 30 сек. Результат следующий:

Результат iperf в режиме работы платы в качестве сервера по UDP
Результат iperf в режиме работы платы в качестве сервера по UDP

Средняя скорость передачи около 476 Мбит/с. При этом около 10% пакетов было потеряно поскольку PC выдавал пакеты быстрее чем могла принять плата

Четвёртый тест будет на производительность платы в режиме клиента. Плата посылает данные по протоколу UDP в PC. Тест выполняется 30 сек. Результат следующий:

Средняя скорость передачи около 718 Мбит/с. При этом не менее 43 пакетов было потеряно.

Результаты не столь впечатляющие как показал тест iperf в паре со стеком NetX Duo Azure RTOS. И скорее всего что-то в тесте NetX Duo было неправильным.

Парадокс оптимизации

Интересный момент был обнаружен в результатах тестов при разных уровнях оптимизации в настройках компилятора. Максимальный уровень оптимизации по скорости ухудшает результаты iperf оценочно на 10% по сравнение с уровнем Medium. Это с среде IAR Embedded Workbench 9.30.1. Эффект довольно странный.

Комментарии (0)