Я пытаюсь вызвать печатную плату, которая использует Ethernet PHY STM32F407 и LAN8720A, и я не могу получить какие-либо кадры Ethernet - даже если у меня нет проблем с передачей кадров.
Настройка оборудования
У меня есть кристалл 25 МГц на STM32F4, который выводит вывод с тактовой частотой 25 МГц в LAN8720A, который находится в режиме REF_CLK_OUT, и возвращает тактовую частоту 50 МГц обратно в STM32F4 как часть интерфейса RMII.
Домкрат / магнетизм являются общей частью. Вот таблица данных:
Програмное обеспечение
Я использую последнее обновление STM32CubeMX для создания System Workbench для проекта STM32, который содержит FreeRTOS, lwIP, а также драйверы периферийных устройств ETH. На самом деле я не касался ни одного сгенерированного кода - поэтому стек lwIP инициализируется внутри стека FreeRTOS.
Эксперименты
Когда на моей плате lwIP настроен на статический IP-адрес 10.0.0.2, а на компьютере настроен ключ USB-to-ethernet, настроенный на статический IP-адрес 10.0.0.1, я подключаю два устройства напрямую с помощью кабеля Ethernet, и моя плата пытается подключиться к сервису через порт 80 компьютера. Я фиксирую взаимодействие между моей платой и компьютером с помощью Wireshark (работающего на компьютере и связанного с преобразователем USB-Ethernet).
Из-за проблемы отсутствия полученных фреймов мы никогда не преодолеем эту вещь ARP: Как вы можете видеть, Stmicroe (моя плата) может отправлять пакеты ARP - слышно моим компьютером - но, кажется, никогда не слышит ответ от моего компьютера , так как он продолжает взрывать пакеты ARP.
Оба устройства настроены с маской 255.255.255.0, и оба настроены с адресом шлюза 10.0.0.1 (компьютер). Я слышал о том, что таблицы ARP испорчены, и компьютеры игнорируют пакеты ARP, но я не могу представить, чтобы плата игнорировала пакеты ARP, специально адресованные ей моим компьютером - в ответ на запросы, которые плата сначала сделала.
Итак, я погружаюсь в файл ethernetif.c lwIP и замечаю, что HAL_ETH_GetReceivedFrame_IT(&heth)
возвращается ошибка. Эта функция возвращает ошибку, потому что (heth->RxDesc->Status & ETH_DMARXDESC_OWN)
== 0, а не 1. Я понимаю, что это означает, что буферы DMA в данный момент активированы для периферийного устройства MAC и еще ничего не получили.
Кроме того, я убедился, что HAL_ETH_IRQHandler никогда не вызывается.
Проблема с PHY?
В этот момент я подозревал, что виновата сама моя PHY.
Для дальнейшего изучения я подключил свой Saleae Logic Pro 16 ко всем соответствующим сигналам и заметил, что на линиях TX0 / TX1, а также на линиях RX0 / RX1 достаточно трафика. Вот захват некоторого трафика RX с тактовой частотой 25 МГц:
RX_ERR низок все время, если только я не попытаюсь захватить выход тактовой частоты 50 МГц (что, очевидно, является проблемой для такого устройства, как Saleae): в этом случае RX_ERR иногда имеет высокий уровень для нескольких пакетов (что на самом деле является хорошим признаком - штифт, кажется, функционирует).
Следующие шаги
Я попытался вручную включить прерывания ETH путем вызова HAL_NVIC_EnableIRQ(ETH_IRQn);
после вызова tcpip_init()
в MX_LWIP_Init()
задаче, но это, похоже, не решает проблему. Я не совсем уверен, что подпрограмма прерывания Ethernet даже должна вызываться - это непростая задача при разработке совершенно нового дизайна; Я изо всех сил пытаюсь определить, каково будет правильное поведение системы, поэтому я могу определить, как отличаются мои настройки.
Несмотря на то, что раньше я использовал STM32 / STM32CubeMX / FreeRTOS, я никогда не использовал периферийное устройство Ethernet STM32, и мой единственный опыт работы с этим материалом связан с пользовательскими встроенными системами Linux, которые, казалось, всегда работали «из коробки». Это новая территория для меня!
Я уверен, что где-то есть глупый флажок или магическая Ethernet_EnableReceive()
функция, которую я забываю вызывать, но я не могу найти документацию, которая предлагает необходимость явного включения этого материала, и сообщения, которые я вижу в Интернете, все из-за не связанных вопросы.
Если у кого-то есть идеи, я бы хотел помочь!
Приложение: избавление от FreeRTOS
Я просто удалил компонент проекта FreeRTOS, вернувшись к голому проекту. В моем основном цикле я звоню MX_LWIP_Process()
. Этот метод должен устранить необходимость прерываний, но он не устраняет проблему; Я все еще не могу получить кадры. Это заставляет меня думать, что что-то есть в коде ETH HAL, сгенерированном STM32CubeMX.
Решение
На тот случай, если кто-то натолкнется на этот вопрос в будущем, проблема оказалась в том, что перевернуты контакты RXD0 и RXD1. Вот почему я мог видеть трафик на моем логическом анализаторе, но он не был декодирован моим MCU.
Как кто-то указал, магнетизм, который я использовал, асимметричен и не должен использоваться для auto-MDI-X. У меня не было никаких проблем. Я ожидаю, что происходит одна из двух вещей: - магнитики на самом деле не работают в другой ориентации, но поскольку все, что у меня есть, использует auto-MDI-X, моя плата по существу остается фиксированной в конфигурации, которая работает, в то время как другое устройство включено кабель ориентирует свои сигналы на соответствие. - магнетизм обеспечивает подходящую целостность сигнала, учитывая короткие пробеги Ethernet, но долгосрочный анализ показал бы более высокие скорости отбрасывания пакетов или проблемы при более длительных пробегах.
Честно говоря, мне непонятно, почему будет иметь значение, на какой стороне трансформатора 1: 1 установлены линейные фильтры, поэтому вне приложений PoE я не уверен, почему симметричная или асимметричная конструкция имеет значение.