Discussion :

[electroremy]

Bonjour,

En théorie, avec le Shield Ethernet, quand on utilise pas la carte SD, on peut utiliser la pin n°4 pour autre chose

(la pin n°4 sert de CS pour la communication SPI de la carte SD)

En pratique, ça perturbe le fonctionnement du chip Ethernet.

Je l'ai testé, l'utilisation de la pin 4 fait brutalement interrompre la communication SPI et ça plante logiquement l'envoi et la reception des packets (le W5500 ne plante pas, mais les données envoyées ou reçues sont incorrectes)

Hypothèses :
- problème matériel (ou firmware) sur le shield Ethernet
- problème logiciel dans la bibliothèque Ethernet

Qu'en pensez vous ?

Avez vous été confronté à ça ?

A bientôt

[Delias]

Bonsoir Remy

Le problème dépend de la version du shied. Je te laisse tirer les conclusions.

La documentation Schéma PDF de l'Ethernet Shield 2 sur le site Arduino ne permet pas d'expliquer le problème, mais il est aussi indiqué dans la discussion en anglais qu'il y a des docs qui se contredisent. Il faudrait avoir le vrai schéma de ton shied pour comprendre. A mon avis il y a une partie active sur la ligne de retour et qui s'active avec le CS... Il n'y a plus qu'a virer le composant en question, et c'est très probablement irrémédiable.

C'est de la pure spéculation, vu le manque d'information et/ou de motivation pour la trouver.

Delias

[Vincent PETIT]

Salut
De ce que je vois du schéma de ce shield https://www.gotronic.fr/art-ethernet...024-23299.htm# si on insert la carte SD le broche 4 du Arduino n'est plus utilisable même si on ne s'en sert pas.

C'est un problème, ou plutôt des problèmes, sur le hardware. Le résumé juste en dessous





Voici les détails :

Cette partie là est ok !
En jaune on voit le signal IO10*/SS (slave select) issu du Arduino qui vient piloter la broche /CS (chip select) du W5500. La condition de démarrage, quand le Arduino démarre et que toutes ses broches sont en entrées, est assurée par la résistance de pull-up, entourée en bleu, qui force le W5500 à rester inactif et sa sortie MISO passe en haute impédance.

Le problème principal est ici :
En jaune on voit le signal D4/SD_SC issu du Arduino est qui arrive dans un buffer inutile, il en sort renommé SEN3 et qui va à la carte SD. On remarque aussi que le MISO de la carte SD est le même MISO que le W5500 donc si D4/SD_SC passe à l'état bas et que la carte SD est connectée, on se retrouve avec une collision entre les MISO si le module Ethernet est entrain de causer.

[electroremy]

Bonjour,

Alors merci pour vos réponses bien argumentée
...et créatives sur le plan graphique

Cela prouve le bon niveau de notre forum

Le problème que je rencontre se produit alors que non seulement je n'utilise pas le lecteur SD mais qu'en plus le support de carte SD est vide

C'est incompréhensible...

Seule explication : le schéma n'est pas à jour ou incomplet, un composant supplémentaire agit sur le W5500 quand on change l'état de la broche 4
Ou alors, une fonction cachée dans la bibliothèque explique ce comportement (ça ne serait pas étonnant qu'une "sécurité" logicielle soit mise quelque part)

A bientôt

[Delias]

Bonjour Rémy

Tu nous remercies pour les réponses mais tu n'as pas compris la mienne.

Sur certains Shield cela fonctionne, sur d'autres cela ne fonctionne pas. Le problème n'est donc pas logiciel.
D4 n'a aucune raison d'être reliée à la puce Ethernet, ce n'est pas là.

Sur le schéma il est indiqué que 3 puces SN74LVC1G125 sont utilisées dans le sens Arduino -> Carte SD. Elles servent d'abaisseurs de tension 5V -> 3V3.
Il suffit qu'ils en aient mis une dans le sens Carte SD -> Arduino pour provoquer ton problème.
Selon les cartes SD, alimentées en 3V3, le 1 logique peut être un peu trop bas pour être correctement lu par l'entrée 5V de l'Arduino. La solution c'est de mettre une telle porte dont le trois état est commandé par D4 pour améliorer le signal de la carte SD. Sauf que cela met également le bazar sur la ligne MISO en cas d'utilisations autres de D4 et empêchant alors le retour d'information de la puce W5500. C'est d'ailleurs ce qui est décrit dans le sujet en lien, la puce continue à fonctionner (côté Ethernet) c'est juste l'Arduino qui ne récupère plus aucune information.

Delias

[Vincent PETIT]

Sur certains Shield cela fonctionne, sur d'autres cela ne fonctionne pas. Le problème n'est donc pas logiciel.
D4 n'a aucune raison d'être reliée à la puce Ethernet, ce n'est pas là.

Sur le schéma il est indiqué que 3 puces SN74LVC1G125 sont utilisées dans le sens Arduino -> Carte SD. Elles servent d'abaisseurs de tension 5V -> 3V3.
Il suffit qu'ils en aient mis une dans le sens Carte SD -> Arduino pour provoquer ton problème.
Selon les cartes SD, alimentées en 3V3, le 1 logique peut être un peu trop bas pour être correctement lu par l'entrée 5V de l'Arduino. La solution c'est de mettre une telle porte dont le trois état est commandé par D4 pour améliorer le signal de la carte SD. Sauf que cela met également le bazar sur la ligne MISO en cas d'utilisations autres de D4 et empêchant alors le retour d'information de la puce W5500. C'est d'ailleurs ce qui est décrit dans le sujet en lien, la puce continue à fonctionner (côté Ethernet) c'est juste l'Arduino qui ne récupère plus aucune information.

Tout à fait, ça peut également être ça et oui peut être que je n'ai pas lu le bon schéma.

[Delias]

@Vincent

Tu as lu le bon schéma, celui du site Arduino. Mais dans la discussion en anglais ils disent avoir vu des schémas et layouts de PCB différents. (Les fichiers Eagle ???)
Après je n'ai pas été cherché plus loin, je n'ai pas Eagle.

On voit bien que deux ingénieurs en matériel ont des suppositions différentes simplement par manque d'information...

Delias

[Vincent PETIT]

Ou alors, une fonction cachée dans la bibliothèque explique ce comportement (ça ne serait pas étonnant qu'une "sécurité" logicielle soit mise quelque part)

En effet, il est tout à fait possible que ce problème hard ait été identifié depuis le début => risque de collision (ou plutôt court circuit à dire vrai) dès que la carte SD est insérée et que les développeurs de la bibliothèque aient prévu une sécurité logicielle.

A mon avis ce problème hardware a été corrigé en soft.