Estoy tratando de mostrar una PCB que usa un STM32F407 y LAN8720A Ethernet PHY, y parece que no puedo recibir ninguna trama de Ethernet, aunque no tengo problemas para transmitirlas.

Configuración de hardware

Tengo un cristal de 25 MHz en el STM32F4, impulsando un pin de salida de reloj de 25 MHz en el LAN8720A, que está en modo REF_CLK_OUT, y conduce un reloj de 50 MHz de regreso al STM32F4 como parte de la interfaz RMII.

El jack / magnetics son una parte genérica. Aquí está la hoja de datos:

Software

Estoy usando la última actualización de STM32CubeMX para generar un System Workbench para el proyecto STM32 que contiene FreeRTOS, lwIP, más los controladores periféricos ETH. Realmente no he tocado ninguno de los códigos generados, por lo que la pila lwIP se inicializa dentro de una pila FreeRTOS.

Los experimentos

Con el lwIP de mi placa configurado para una IP estática 10.0.0.2 y un dongle de USB a ethernet en mi computadora configurado para una IP estática 10.0.0.1, conecto los dos dispositivos directamente con un cable Ethernet, y mi placa intenta conectarse a un servicio en el puerto 80 de la computadora. Capturo la interacción entre mi placa y la computadora usando Wireshark (que se ejecuta en la computadora y enlazada al convertidor de USB a Ethernet).

Debido al problema de que no hay marcos recibidos, nunca superamos estas cosas ARP: Como puede ver, Stmicroe (mi placa) puede enviar paquetes ARP, escuchados por mi computadora, pero nunca parece escuchar la respuesta de mi computadora , ya que sigue lanzando paquetes ARP.

Ambos dispositivos están configurados con una máscara 255.255.255.0, y ambos están configurados con una dirección de puerta de enlace de 10.0.0.1 (la computadora). Escuché que las tablas ARP se arruinaron y que las computadoras ignoraron los paquetes ARP, pero no puedo imaginar que la placa ignore los paquetes ARP específicamente dirigidos a ella por mi computadora, en respuesta a las solicitudes que la placa hizo en primer lugar.

Entonces, me sumerjo en el archivo ethernetif.c de lwIP y noto que HAL_ETH_GetReceivedFrame_IT(&heth)está devolviendo un error. Esa función devuelve un error porque (heth->RxDesc->Status & ETH_DMARXDESC_OWN)== 0, en lugar de 1. Interpreto que significa que los búferes de DMA están actualmente armados para el periférico MAC y aún no han recibido nada.

Además, he verificado que nunca se llama al HAL_ETH_IRQHandler.

¿Un problema con el PHY?

En este punto, sospechaba que mi PHY tenía la culpa.

Para investigar más, conecté mi Saleae Logic Pro 16 a todas las señales relevantes y noté que hay mucho tráfico tanto en las líneas TX0 / TX1 como en las líneas RX0 / RX1. Aquí hay una captura de algo de tráfico RX con el reloj de entrada de 25 MHz:

RX_ERR está bajo todo el tiempo, a menos que intente capturar la salida de reloj de 50 MHz (lo que obviamente es un desafío con un dispositivo como el Saleae): en ese caso, RX_ERR se borra ocasionalmente para algunos paquetes (lo que en realidad es una buena señal - el pin parece estar funcionando).

Próximos pasos

He intentado habilitar manualmente las interrupciones ETH llamando HAL_NVIC_EnableIRQ(ETH_IRQn);después de que tcpip_init()se llama en la MX_LWIP_Init()tarea, y eso no parece solucionar el problema. No estoy completamente seguro de que se suponga que se llame a la rutina de interrupción de Ethernet ; eso es lo desafiante con la presentación de un nuevo diseño; Estoy luchando por determinar cuál sería el comportamiento adecuado del sistema, por lo que puedo determinar cómo difiere mi configuración.

Si bien he usado las cosas STM32 / STM32CubeMX / FreeRTOS antes, nunca he usado el periférico Ethernet de STM32, y mi única experiencia con estas cosas es en sistemas Linux embebidos personalizados, que siempre parecían funcionar de manera inmediata. ¡Este es un territorio nuevo para mí!

Estoy seguro de que hay una estúpida casilla de verificación en alguna parte o una Ethernet_EnableReceive()función mágica a la que me olvido de llamar, pero realmente no puedo encontrar ninguna documentación que sugiera la necesidad de habilitar explícitamente esas cosas, y las publicaciones que estoy viendo en Internet se deben a que no están relacionadas cuestiones.

Si alguien tiene alguna idea, ¡me encantaría recibir ayuda!

Anexo: Deshacerse de FreeRTOS

Solo para eliminar cosas, eliminé el componente del proyecto FreeRTOS, volviendo a un proyecto básico. En mi bucle principal, llamo MX_LWIP_Process(). Este método debería eliminar la necesidad de interrupciones, pero no soluciona el problema; Todavía no puedo recibir marcos. Esto me hace pensar que hay algo en el código ETH HAL generado por STM32CubeMX.

Solución

En caso de que alguien se tope con esta pregunta en el futuro, el problema resultó ser voltear los pines RXD0 y RXD1. Es por eso que pude ver el tráfico en mi analizador lógico, pero mi MCU no lo decodificó.

Como alguien señaló, los imanes que utilicé son asimétricos y no deben usarse para auto-MDI-X. No he tenido ningún problema. Anticipo que está sucediendo una de dos cosas: - los imanes no funcionan realmente en la otra orientación, pero debido a que todo lo que tengo usa auto-MDI-X, mi placa esencialmente permanece fija en la configuración que funciona, mientras que el otro dispositivo está encendido el cable orienta sus señales para que coincidan. - el magnetismo proporciona una integridad de señal adecuada debido a las cortas ejecuciones de Ethernet, pero un análisis a largo plazo mostraría tasas más altas de caída de paquetes o problemas durante las ejecuciones más largas.

Honestamente, no está claro para mí por qué importaría en qué lado del transformador 1: 1 están instalados los filtros de línea, por lo que, fuera de las aplicaciones PoE, no estoy seguro de por qué sería importante un diseño simétrico frente a asimétrico.

Usted tiene wireshark instalado en la PC y, como usted dice, usa un adaptador USB a LAN. No estoy seguro de en qué punto físico Wireshark captura los paquetes en su configuración y, por lo tanto, es una buena pregunta si los paquetes salientes aparecen realmente en la red física . Le recomiendo que conecte otra PC con interfaz de red y vea si estas PC pueden comunicarse entre sí comparando la salida de Wiresharks en ellas.

Su salida de Wirehark no muestra ningún problema, la PC anuncia tres veces que está en la red local y que tiene la dirección IP 10.0.0.1 (si recibiera respuesta a cualquiera de estas 3 solicitudes ARP, el sistema operativo aparecería con un conflicto de dirección IP).

Entonces, su tablero pregunta constantemente ¿Quién tiene 10.0.0.1? Dile a 10.0.0.2 y PC con respuestas 10.0.0.1 está en ... . La pregunta es por qué sucede en bucle:

1. la placa no recibe físicamente el paquete de respuesta enviado por la PC;
2. la placa espera algo más, o el paquete recibido está dañado y descarta el paquete.

Por lo tanto, como siguiente paso de solución de problemas, tome otra PC con interfaz Ethernet "normal", instale Wireshark en ella, configure su red de la misma manera que lo hizo con la placa e intente telnet 10.0.0.1 80ver que aparece en Wiresharks en ambas máquinas. De esta manera, se aseguraría de que la PC con su adaptador USB a Ethernet funcione correctamente.

Sus próximos pasos dependerán de las cosas que vea en estos Wiresharks.

Actualizar:

Estoy recibiendo paquetes, de lo contrario, los pines RXD0 / D1 no mostrarían actividad, ¿correcto?

Incorrecto. Desea pensar que su placa recibe paquetes. Verá que hay algún cambio en el nivel de las señales de entrada PHY, pero no necesariamente representan paquetes válidos. El hecho de que RX_ERR no se active no me convence de inmediato de que PHY funciona correctamente en los eventos entrantes, o que la información que llega forma los paquetes adecuados.

De todos modos, depende de ti, mi teoría de resolución de problemas es simple: debe asegurarse en un nivel superior dónde encuentra el problema y luego profundizar en la parte respectiva del diseño. Excavar en todas las partes y sospechar que todo es inútil. Sería una gran suerte si encuentra problemas para difundir el enfoque; ya está intentando simplificar el software, si no tiene éxito probablemente comenzará a reemplazar los chips.

No creo que mi paso de solución de problemas sea tan complicado como para garantizar que otra PC pueda comunicarse con la PC con un dongle y demostrar que estoy equivocado o correcto, y así asegurarme de que estás investigando correctamente PHY, MAC y software de la placa sospechosa trabajando en ellos.

Lamento resucitar este tema. No podría pasar sin mencionar mi experiencia.

He usado este HR911105A (RJ45 con imán) con uno de mis proyectos.

HR911105A: De un vistazo, una cosa me llamó la atención, que era la conexión entre LAN8720 y RJ45 según su esquema.

Desde que veo que la conexión parece cruzada. Aunque los sistemas conectados utilizan principalmente MDI-X y, por lo tanto, detectan pares de recepción / transmisión, sería bueno darle una conexión menos confusa como esta:

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

Pin #4 and Pin #5(por lo tanto, las resistencias pull-up 49.9R) serían buenas si se conectan 3V3_ANen su esquema mientras que el otro lado debe estar acoplado al GND a través de un condensador (0.1uF o 0.022uF).