J'essaie de faire apparaître un PCB qui utilise un STM32F407 et un LAN8720A Ethernet PHY, et je n'arrive pas à recevoir de trames Ethernet - même si je n'ai aucun problème à transmettre des trames.

Configuration materielle

J'ai un cristal de 25 MHz sur le STM32F4, entraînant une broche de sortie d'horloge de 25 MHz dans le LAN8720A, qui est en mode REF_CLK_OUT - et ramène une horloge de 50 MHz au STM32F4 dans le cadre de l'interface RMII.

Le jack / magnétique est une pièce générique. Voici la fiche technique:

Logiciel

J'utilise la dernière mise à jour STM32CubeMX pour générer un projet System Workbench pour STM32 qui contient FreeRTOS, lwIP, ainsi que les pilotes de périphériques ETH. Je n'ai pas vraiment touché au code généré - donc la pile lwIP est initialisée dans une pile FreeRTOS.

Expériences

Avec le lwIP de ma carte configuré pour une adresse IP statique 10.0.0.2 et un dongle USB vers Ethernet sur mon ordinateur configuré pour une adresse IP statique 10.0.0.1, je connecte les deux appareils directement avec un câble Ethernet et ma carte tente de se connecter à un service sur le port 80 de l'ordinateur. Je capture l'interaction entre ma carte et l'ordinateur à l'aide de Wireshark (fonctionnant sur l'ordinateur et lié au convertisseur USB-Ethernet).

En raison du problème de trames non reçues, nous ne dépassons jamais ce truc ARP: Comme vous pouvez le voir, le Stmicroe (ma carte) peut envoyer des paquets ARP - entendus par mon ordinateur - mais il ne semble jamais entendre la réponse de mon ordinateur , car il continue d'exploser les paquets ARP.

Les deux appareils sont configurés avec un masque 255.255.255.0 et les deux sont configurés avec une adresse de passerelle 10.0.0.1 (l'ordinateur). J'ai entendu parler de tables ARP vissées et d'ordinateurs ignorant les paquets ARP, mais je ne peux pas imaginer que la carte ignorerait les paquets ARP qui lui sont spécifiquement adressés par mon ordinateur - en réponse aux demandes que la carte a faites en premier lieu.

Donc, je plonge dans le fichier ethernetif.c de lwIP et je remarque qu'il HAL_ETH_GetReceivedFrame_IT(&heth)retourne une erreur. Cette fonction renvoie une erreur car (heth->RxDesc->Status & ETH_DMARXDESC_OWN)== 0, au lieu de 1. J'interprète cela comme signifiant que les tampons DMA sont actuellement armés pour le périphérique MAC et n'ont encore rien reçu.

De plus, j'ai vérifié que le HAL_ETH_IRQHandler n'est jamais appelé.

Un problème avec le PHY?

À ce stade, je soupçonnais que ma PHY était à blâmer.

Pour enquêter plus avant, j'ai attaché mon Saleae Logic Pro 16 à tous les signaux pertinents et j'ai remarqué qu'il y avait beaucoup de trafic sur les lignes TX0 / TX1, ainsi que RX0 / RX1. Voici une capture du trafic RX avec l'horloge d'entrée de 25 MHz:

RX_ERR est faible tout le temps, sauf si j'essaie de capturer la sortie d'horloge à 50 MHz (ce qui est évidemment difficile avec un appareil comme le Saleae): dans ce cas, RX_ERR est occulté à haute fréquence pour quelques paquets (ce qui est en fait un bon signe - la broche semble fonctionner).

Prochaines étapes

J'ai essayé d'activer manuellement les interruptions ETH en appelant HAL_NVIC_EnableIRQ(ETH_IRQn);after tcpip_init()is called dans la MX_LWIP_Init()tâche, et cela ne semble pas résoudre le problème. Je ne suis pas tout à fait sûr que la routine d'interruption Ethernet soit même censée être appelée - c'est la chose difficile avec la mise en place d'un tout nouveau design; J'ai du mal à déterminer quel serait le bon comportement du système, je peux donc déterminer en quoi ma configuration diffère.

Bien que j'aie utilisé les trucs STM32 / STM32CubeMX / FreeRTOS auparavant, je n'ai jamais utilisé le périphérique Ethernet du STM32, et ma seule expérience avec ces trucs est sur des systèmes Linux embarqués personnalisés, qui semblaient toujours fonctionner simplement. C'est un nouveau territoire pour moi!

Je suis sûr qu'il y a une case stupide quelque part ou une Ethernet_EnableReceive()fonction magique que j'oublie d'appeler, mais je ne trouve pas vraiment de documentation suggérant la nécessité d'activer explicitement ce genre de choses, et les messages que je vois sur Internet sont tous dus à des liens non liés problèmes.

Si quelqu'un a des idées, j'aimerais de l'aide!

Addendum: se débarrasser de FreeRTOS

Juste pour éliminer des choses, j'ai supprimé le composant du projet FreeRTOS, revenant à un projet bare-metal. Dans ma boucle principale, j'appelle MX_LWIP_Process(). Cette méthode devrait éliminer le besoin d'interruptions, mais elle ne résout pas le problème; Je ne parviens toujours pas à recevoir de trames. Cela me fait penser qu'il y a quelque chose dans le code ETH HAL généré par STM32CubeMX.

Solution

Juste au cas où quelqu'un tomberait sur cette question à l'avenir, le problème s'est avéré être les broches RXD0 et RXD1 inversées. C'est pourquoi j'ai pu voir le trafic sur mon analyseur logique, mais il n'a pas été décodé par mon MCU.

Comme quelqu'un l'a souligné, les magnétiques que j'ai utilisés sont asymétriques et ne devraient pas être utilisés pour l'auto-MDI-X. Je n'ai eu aucun problème. Je prévois que deux choses se produisent: - les magnétiques ne fonctionnent pas réellement dans l'autre orientation, mais parce que tout ce que j'ai utilise auto-MDI-X, ma carte reste essentiellement fixe dans la configuration qui fonctionne, tandis que l'autre appareil allumé le câble oriente ses signaux pour qu'ils correspondent. - les magnétiques fournissent une intégrité de signal appropriée étant donné les courts trajets Ethernet, mais une analyse à long terme montrerait des taux plus élevés de perte de paquets ou de problèmes sur des trajets plus longs.

Honnêtement, je ne comprends pas pourquoi il importerait de quel côté du transformateur 1: 1 les filtres de ligne sont installés, donc en dehors des applications PoE, je ne sais pas pourquoi une conception symétrique vs asymétrique importerait.

Wirehark est installé sur le PC et, comme vous le dites, vous utilisez un adaptateur USB-LAN. Je ne sais pas à quel moment physique Wireshark capture les paquets dans votre configuration, et c'est donc une bonne question si les paquets sortants apparaissent réellement sur le réseau physique . Je vous recommande de connecter un autre PC avec une interface réseau et de voir si ces PC peuvent communiquer entre eux en comparant la sortie de Wiresharks sur eux.

Votre sortie Wireshark ne montre aucun problème, le PC annonce trois fois qu'il est sur le réseau local et qu'il a l'adresse IP 10.0.0.1 (s'il recevrait une réponse à l'une de ces 3 demandes ARP, le système d'exploitation apparaîtrait avec un conflit d'adresse IP).

Ensuite, votre conseil d'administration demande constamment qui a 10.0.0.1? Dites - 10.0.0.2 réponses et PC avec 10.0.0.1 est à ... . La question est de savoir pourquoi cela se produit en boucle:

1. la carte ne reçoit pas physiquement le paquet de réponse envoyé par le PC;
2. carte attend quelque chose d'autre, ou le paquet reçu est corrompu, et il rejette le paquet.

Ainsi, comme prochaine étape de dépannage, prenez un autre PC avec une interface Ethernet "normale", installez Wireshark dessus, configurez sa mise en réseau de la même manière que pour la carte, et essayez de telnet 10.0.0.1 80voir ce qui apparaît dans Wiresharks sur les deux machines. De cette façon, vous vous assureriez que le PC avec son adaptateur USB vers Ethernet fonctionne correctement.

Vos prochaines étapes dépendront de ce que vous verrez dans ces Wiresharks.

Mise à jour:

Je reçois des paquets, sinon les broches RXD0 / D1 ne montreraient aucune activité, n'est-ce pas?

Pas correcte. Vous voulez penser que votre carte reçoit des paquets. Vous voyez qu'il y a un certain changement dans le niveau des signaux d'entrée PHY, mais ils ne représentent pas nécessairement des paquets valides. Le fait que RX_ERR ne bascule pas ne me convainc pas immédiatement que PHY fonctionne correctement sur les événements entrants, ou que les informations arrivant constituent des paquets appropriés.

Quoi qu'il en soit, cela dépend de vous, ma théorie de dépannage est simple - vous devez vous assurer à un niveau supérieur où rencontrez-vous le problème, puis creuser dans la partie respective de la conception. Creuser dans toutes les parties et soupçonner tout est inutile. Ce serait une grande chance si vous trouvez un problème de diffusion de l'attention; vous essayez déjà de simplifier un logiciel, s'il ne réussit pas, vous commencerez très probablement à remplacer les puces.

Je ne pense pas que mon étape de dépannage soit si compliquée à faire pour garantir qu'un autre PC puisse communiquer avec le PC avec un dongle et me prouver que j'ai tort ou raison, et ainsi m'assurer que vous avez raison de creuser dans les profondeurs suspectant la PHY, le MAC et le logiciel du conseil travaillant sur leur.

Désolé de ressusciter ce sujet. Je ne pouvais pas passer sans mentionner mon expérience.

J'ai utilisé ce HR911105A (RJ45 avec aimant) avec l'un de mes projets.

HR911105A: En un coup d'œil, une chose a attiré mon attention sur la connexion entre LAN8720 et RJ45 selon votre schéma.

Puisque je vois que la connexion semble croisée. Bien que les systèmes connectés utilisent principalement MDI-X et détectent donc les paires de réception / transmission, il serait bon de lui donner une connexion moins confuse comme ça:

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

Pin #4 and Pin #5(donc les résistances de pull-up 49.9R) seraient bonnes si elles étaient connectées à 3V3_ANdans votre schéma tandis que l'autre côté devrait être couplé au GND via un condensateur (0.1uF ou 0.022uF).