STM32F407 + LAN8720A + lwIP + FreeRTOS = Aucune trame Ethernet reçue

9

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

Schéma de l'Ethernet PHY 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: entrez la description de l'image ici

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 Capture de Wireshark 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:

Capture du paquet reçu

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.

Jay Carlson
la source
Où Wireshark est installé?
Anonyme
L'ordinateur auquel la carte tentait de se connecter. Je vais modifier la question pour plus de clarté.
Jay Carlson du
FWIW, je recommanderais d'utiliser la pile FreeRTOS. (Je réalise que cela ne répond pas à votre requête spécifique.) Je ne peux rien faire avant ce soir, mais si cela a aidé, je suis à peu près sûr que j'ai un projet pour ce processeur que j'ai reçu des pings avec la pile FreeRTOS. Je ne sais pas quel PHY faisait partie du conseil d'administration. Quoi qu'il en soit, faites-moi savoir si vous voulez le projet, je peux le mettre sur le site interactif FreeRTOS.
DiBosco du
Ce serait super utile. Je suis totalement agnostique envers la pile que j'utilise --- J'ai juste besoin de quelque chose que je peux mettre en service rapidement.
Jay Carlson du
1
J'ai essayé d'échanger des magnétiques avec quelque chose de symétrique, et cela n'a pas résolu le problème. Toutefois! J'étais en train de regarder mon schéma et j'ai réalisé que j'avais RXD0 et RXD1 échangés. Ah! C'est pourquoi j'ai vu des données RX sortir du PHY, mais rien n'a été reçu par le MAC. Je pourrais ressouder mes anciens magnétiques sur la carte (juste pour que je n'aie pas quelque chose qui pende), et je pense que le protocole auto-MDI-X devrait le comprendre, non? La LED "link" ne doit s'allumer que lorsqu'une liaison RX / TX valide est établie, non? Il était toujours illuminé, même avec les anciens magnétiques asymétriques.
Jay Carlson

Réponses:

0

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.

Anonyme
la source
Bien que j'apprécie que vous ayez pris le temps d'écrire ceci, il est assez clair que mon PHY reçoit des paquets de mon PC, mais ils ne sont pas reçus par ma carte. Sinon, je ne verrais pas les données Rx sur les lignes RMII, non? Je ne pense pas que ce soit une simple question de réseautage de haut niveau.
Jay Carlson
@JayCarlson Vous devez encore prouver que les signaux électriques à l'extrémité du câble de votre carte représentent des paquets appropriés qui peuvent être capturés et non jetés. Pourquoi entrer dans les profondeurs de la technologie sans prouver des choses aussi simples?
Anonyme le
Votre théorie est-elle que mon ordinateur n'envoie pas réellement les paquets qu'il devrait envoyer (et que Wireshark dit qu'il envoie)? Quels sont les paquets que ma carte reçoit alors? La carte est connectée directement à mon ordinateur. Ce n'est pas une configuration réseau compliquée, et tout paquet reçu par le PHY sur ma carte doit provenir de mon ordinateur, non? Je reçois des paquets, sinon les broches RXD0 / D1 ne montreraient aucune activité, n'est-ce pas? Votre hypothèse est que quelque chose rejette les paquets, non? Quel est? Le PHY? Le bit RX_ERR ne se met jamais. Le MAC du MCU? l'ISR de réception ne se déclenche jamais.
Jay Carlson
J'ai mis à jour la réponse. Ne soyez pas douteux et préconçu. Les choses complexes peuvent sembler plus simples que vous ne le pensez. Il suffit d'agir et de collecter des informations.
Anonyme
1
D'accord, j'ai connecté mon ordinateur à un autre en utilisant le même câble et l'adaptateur USB vers Ethernet. J'ai exécuté une instance de Wireshark sur les deux ordinateurs, et ils affichent des données identiques --- certains bavardages ARP, puis une connexion réussie à un service netcat exécuté sur le port 80. J'ai testé cela dans les deux sens. J'ai essayé de me connecter à ce service à partir de ma carte intégrée et, comme je l'ai dit, ne jamais dépasser les messages ARP. Si j'essaie de me connecter à la carte à partir de mon ordinateur, cela ne dépasse pas l'étape ARP, car la carte ne répond jamais aux demandes ARP de mon ordinateur. Je ne pense vraiment pas qu'il entende des paquets.
Jay Carlson
0

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: entrez la description de l'image ici 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).

Sener
la source