STM32F407 + LAN8720A + lwIP + FreeRTOS = Нет полученных кадров Ethernet

Я пытаюсь вызвать печатную плату, которая использует 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 я не уверен, почему симметричная или асимметричная конструкция имеет значение.

stm32 freertos lan8720 lwip Джей Карлсон
источник

Где установлен Wireshark?

Аноним

Компьютер, к которому пытается подключиться плата. Я отредактирую вопрос, чтобы внести ясность в это.

Джей Карлсон

FWIW, я бы порекомендовал использовать стек FreeRTOS. (Я понимаю, что это не помогает вашему конкретному запросу.) Я ничего не могу сделать до этого вечера, но если это помогло, я почти уверен, что у меня есть проект для этого процессора, который я получил с помощью стека FreeRTOS. Я не знаю, какой PHY был на доске, я встал и бежал, хотя. В любом случае, дайте мне знать, если вы хотите проект, я могу разместить его на интерактивном сайте FreeRTOS.

DiBosco

Это было бы очень полезно. Я абсолютно не зависим от стека, который использую - мне просто нужно что-то, что я могу быстро запустить и запустить.

Джей Карлсон

Я пытался заменить магниты чем-то симметричным, и это не решило проблему. Однако! Я глянул на свою схему и понял, что менял местами RXD0 и RXD1. Doh! Вот почему я видел, как данные RX вылетали из PHY, но MAC ничего не получал. Я мог бы припаять мои старые магниты обратно на плату (просто чтобы у меня ничего не свисало со стола), и я чувствую, что протокол auto-MDI-X должен это выяснить, верно? Светодиод «link» должен гореть только тогда, когда установлена действительная RX / TX-связь, верно? Он всегда был освещен, даже со старым, асимметричным магнетизмом.

Джей Карлсон

Ответы:

На ПК установлена Wireshark, и, как вы говорите, вы используете адаптер USB-LAN. Я не уверен, в какой физической точке Wireshark перехватывает пакеты в вашей настройке, и поэтому хороший вопрос, действительно ли исходящие пакеты появляются в физической сети. Я рекомендую вам подключить другой компьютер с сетевым интерфейсом и посмотреть, могут ли эти компьютеры взаимодействовать друг с другом, сравнивая на них выходные данные Wiresharks.

Ваш вывод Wireshark не показывает никаких проблем, ПК трижды объявляет, что он находится в локальной сети и имеет IP-адрес 10.0.0.1 (если он получит ответ на любой из этих 3 запросов ARP, то ОС выскочит с конфликтом IP-адресов).

Затем ваша доска объявлений постоянно спрашивает, у кого есть 10.0.0.1? Скажите 10.0.0.2 и ПК ответы с 10.0.0.1 находится на ... . Вопрос в том, почему это происходит в цикле:

плата физически не принимает ответный пакет, отправленный ПК;
плата ожидает что-то еще, или полученный пакет поврежден, и он отбрасывает пакет.

Таким образом, в качестве следующего шага по устранению неполадок, возьмите другой ПК с «обычным» интерфейсом Ethernet, установите на нем Wireshark, настройте его сеть так же, как вы это делали для платы, и попробуйте telnet 10.0.0.1 80и убедитесь, что он появляется в Wiresharks на обеих машинах. Таким образом, вы убедитесь, что компьютер с адаптером USB-Ethernet работает правильно.

Ваши последующие шаги будут зависеть от того, что вы видите в этих Wiresharks.

Обновить:

Я получаю пакеты, в противном случае выводы RXD0 / D1 не будут показывать активность, правильно?

Неправильно. Вы хотите думать, что ваша доска получает пакеты. Вы видите, что есть некоторые изменения в уровне входных сигналов PHY, но они не обязательно представляют действительные пакеты. Тот факт, что RX_ERR не переключается, не сразу убеждает меня в том, что PHY правильно работает с входящими событиями или поступающая информация образует правильные пакеты.

В любом случае, это зависит от вас, моя теория устранения неполадок проста - вы должны на более высоком уровне убедиться, где вы столкнулись с проблемой, а затем углубиться в соответствующую часть проекта. Копаться во всех частях и подозревать все бесполезно. Было бы очень хорошо, если бы вы обнаружили проблему, распространяющую фокус; вы уже пытаетесь упростить программное обеспечение, и если оно не удастся, вы, скорее всего, начнете заменять чипы.

Я не думаю, что мой шаг по устранению неполадок настолько сложен, чтобы сделать так, чтобы другой ПК мог обмениваться данными с ПК с помощью ключа и доказать, что я неправ или прав, и, таким образом, убедиться, что вы правы, копаясь в глубине, подозревая PHY, MAC и программное обеспечение платы, работающие на их.

анонимное
источник

Хотя я благодарен вам за то, что вы нашли время написать это, довольно ясно, что мой PHY получает пакеты от моего ПК, но они не принимаются моей платой. Иначе я бы не увидел данные Rx в строках RMII, верно? Я не думаю, что это простой сетевой вопрос высокого уровня.

Джей Карлсон

@JayCarlson Вы все еще должны доказать, что электрические сигналы на конце кабеля вашей платы представляют собой надлежащие пакеты, которые можно захватывать и не отбрасывать. Зачем углубляться в технологии, не доказывая такие простые вещи?

Аноним

Ваша теория, что мой компьютер на самом деле не отправляет пакеты, которые он должен отправлять (и что Wireshark говорит, что отправляет)? Какие пакеты получает моя плата? Плата подключена напрямую к моему компьютеру. Это не сложная настройка сети, и любой пакет, полученный PHY на моей плате, должен исходить от моего компьютера, верно? Я получаю пакеты, в противном случае выводы RXD0 / D1 не будут показывать активность, правильно? Ваша гипотеза состоит в том, что что-то отбрасывает пакеты, верно? Что такое? PHY? Бит RX_ERR никогда не устанавливается. MAC MCU? Прием ISR никогда не срабатывает.

Джей Карлсон

Я обновил ответ. Не будь сомнительным и предвзятым. Сложные вещи могут показаться проще, чем вы думаете. Просто действуй и собирай информацию.

Аноним

Хорошо, я подключил свой компьютер к другому с помощью того же кабеля и адаптера USB-Ethernet. Я запустил экземпляр Wireshark на обоих компьютерах, и они показывают идентичные данные - некоторую болтовню ARP, а затем - успешное соединение со службой netcat, работающей через порт 80. Я проверял оба способа. Я пытался подключиться к этому сервису со своей встроенной платы и, как я уже сказал, никогда не проходил мимо сообщений ARP. Если я пытаюсь подключиться к плате с моего компьютера, она не проходит этап ARP, поскольку плата никогда не отвечает на запросы ARP моего компьютера. Я действительно не думаю, что это слышит пакеты.

Джей Карлсон

Извините, что воскресил эту тему. Я не мог пройти без упоминания моего опыта.

Я использовал этот HR911105A (RJ45 с магнитом) с одним из моих проектов.

HR911105A: На мой взгляд, одна вещь привлекла мое внимание, это соединение между LAN8720 и RJ45 согласно вашей схеме.

Так как я вижу, что соединение выглядит кроссовером. Хотя подключенные системы в основном используют MDI-X и, следовательно, обнаруживают пары приема / передачи, было бы хорошо, чтобы это соединение было менее запутанным:

LAN -> RJ45
=====================
TXP -> TD+ (Pin #1)
TXN -> TD- (Pin #2)
RXP -> RD+ (Pin #3)
RXN -> RD- (Pin #6)

Pin #4 and Pin #5(так что подтягивающие резисторы 49.9R) было бы хорошо, если бы они были подключены к 3V3_ANвашей схеме, тогда как другая сторона должна быть подключена к GND через конденсатор (0.1uF или 0.022uF).

Шенер
источник