Forum: Mikrocontroller und Digitale Elektronik Arduino DUE Hardware mit W5500: Seltsame Absturzprobleme


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Liebe Mitforisten,

ich habe ein mehr als seltsames Verhalten meiner neuen 
Heizungssteuerung. Sie basiert auf einer Arduino DUE Hardware und hat 
die Möglichkeit, jede Menge Sensoren anzuschließen. U.a. ist ein W5500 
Modul (TENSTAR ROBOT, China) verbaut, über das die Kommunukation mit 
einem PC laufen soll. Die SPI Signale sind, mit Ausnahme des 
Select-Signales, gepuffert. Als Stromversorgung dient ein externes 12V 
Stecker-Schaltnetzteil. Im System ist ein weiterer Schaltregler, der die 
benötigten 5V für das System erzeugt. (Auf der Arduino-Platine werden 
schließlich die 3,3 V für den SAM erzeugt, die auch der Versorgung des 
W5500 dienen)  Weiterhin ist das Gerät bzw. die „Masse“ geerdet. 
Programmiersprache ist „C“.

Bei mir im Arbeitszimmer funktioniert alles einwandfrei. Da hängt sich 
nichts auf, ich kann über mehrere Tage minütlich über das Netzwerk die 
Daten aus dem System abfragen.

Nur jetzt ist das gute Stück zum test im Keller, und ziemlich 
reproduzierbar resettet das System alle 10...20 Sekunden an zufälliger 
(?) Stelle, wenn das Ethernet Kabel eingesteckt ist. Weitere Peripherie 
ist aktuell noch nicht angeschlossen.

Das Netwerk sieht so aus, daß im Keller der (Glasfaserhausanschluß) 
Router mit 4 Ethernet Buchsen installiert ist. An einem dieser 
Anschlüsse ist mein System (20 m Patchkabel) eingesteckt. Über einen 
weiteren Anschluß ist die Fritzbox 7490 in meinem Arbeitszimmer 
angeschlossen, an dieser ist ein Switch, über den schließlich mein 
System im Arbeitszimmer angeschlossen war.

Ich stehe nun völlig auf dem Schlauch und brauche Tips zur Suche des 
Fehlers. Das softwaremäßige Abschalten der W5500 Kommunikationssoftware 
im System und der Socketinitialisierung - es bleibt nur  die 
Grundinitialisierung mit IP, Port, Mac - ändert nichts am Abschmieren. 
Ziehe ich das CAT5 Kabel ab, dann läuft das absturzfrei weiter.

Ach ja, ich verwende kein DHCP

Hat jemand hier im Forum einen ähnlichen Effekt erlebt? Oder irgendeine 
Idee, was ich wie und wo suchen kann? Wäre toll.

PS: Mein System gibt über eine COM-Schnittstelle nach dem RESET einen 
Startstring aus, der aber bei diesen Neustarts hier 
unverständlicherweise ausbleibt.. Dies ist äußerst seltsam. Denn die 
weitere Initialisierung wird durchlaufen wie bei einem Kaltstart, auch 
die SAM-interne RTC verliert alle Daten..

Danke, Yogy

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Nur jetzt ist das gute Stück zum test im Keller, und ziemlich
> reproduzierbar resettet das System alle 10...20 Sekunden ...
Wie hast du denn den Watchdog konfiguriert?
Warum der allerdings arbeitzimmer-/kellerabhängig sein kann - hmmh
Müsste dann am Netzwerkverkehr liegen.

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
An den Watchdog dachte ich auch, aber Watchdog- und SW resets werden 
gezählt, und ich kann diese afragen. Zudem tritt der "Absturz" auch bei 
angeschaltetem Watchdog auf.

Ich habe soeben einen Workaround versucht, indem ich direkt vor dem 
System einen weiteren Hub zwischengeschaltet habe, um eventuelle 
kabellängenprobleme auszuschließen. Das System schmiert trotzdem ab....

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Ergänzung: Auch wenn ich ledglich den Hub mit meinem System verbinde, 
alo keine Netzwerkverbindung besteht, gibt es die Resets.

Ich denke, da liegt vielleicht ein Störungssignal über die 3,3 V 
Versorgung, ich werde gleich mal meinen Oszi anklemmen.

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Ich möchte das Thema zurückstellen. Ich habe das W5500 Modul 
provisorisch ausgetauscht, und nun gibt aktuell es keine Abstürze mehr.. 
Ich will das beobachten, denn das Verhalten "Funktioniert im 
Arbeitszimmer, im Keller aber nicht" ist schon sehr seltsam.

Morgen werde ich mir das auf dem Laboprtisch genauer ansehen.

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
UPDATE
Der gestrige Einbau einen anderen W5500 Moduls hat keine Lösung 
gebracht, nach rund 30 min gab es den ersten Reset, danach alle 10..30 
Sekunden.

Dieses verhalten läßt eigentlich auf ein thermisches Problem schließen, 
aber ich konnte/kann keine Wärmequelle finden.

Nachdem ich mir nichmnals die Schaltung angesehen habe, stieß ich auf 
die dubiose Reset-Schaltung der Arduino-DUE Schaltung. Spikes  u/o 
Powerdips auf der 3V3 Leitung könnten einen reset erzeugen. Ich habe 
daraufhin als ersten Workaround testweise die Stromversorgung des W5500 
von der DUE-Leiterkarte getrennt und zudem mit einem "dicken" Elko 
versehen.

Seit 3 Stunden gabe es nun keinen Reset mehr.

Seltsam ist nur, daß das Resetproblem bislang nur im Keller 
auftritt/auftrat..

Ich werde weiter berichten.

von Reiner O. (elux)


Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Seltsam ist nur, daß das Resetproblem bislang nur im Keller
> auftritt/auftrat..

Ist das im Keller ein GBit Netzwerk?

> Morgen werde ich mir das auf dem Laboprtisch genauer ansehen.

Kommt das Netzwerk am "Laboprtisch" vom selben Switch?

MfG

Elux011

von Jürgen S. (avus)


Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Ich werde weiter berichten.
Es hört sich so an, als das Netzteil von Deinem Due gerade mal noch 
alles oben wegfiltern konnte, unten im Keller aber nicht mehr.

Vielleicht ist mehr Müll auf der Netz- oder LAN-Leitung durch einen 
Verbraucher dort unten. Die thermischen Effekte haben dann zwar einen 
minimalen Einfluß, aber der reicht, um nach 30 min über das Störlimit 
des W5500 bzw. des Gesamtsystems zu gehen.

Aus meiner Sicht hast Du schon nachgewiesen, daß es an der 
Stromversorgung des Due liegt. Mit einem Batterie-Oszi an den 5V oder 
3.3V sollte man einen Unterschied erkennen können, wenn das W5500 wieder 
mit dranhängt (und die 30 min Durchwärmphase um sind).


Prinzipiell kann es natürlich auch ein Erdschleifenproblem im Keller 
sein, was die Störungen ans Limit bringt, und dann nach 30 min das 
Störlimit überschreitet. Ich habe gerade mal an meinem W5500-Modul 
nachgemessen, der Schirm der Ethernet-Buchse ist direkt mit GND des 
Netzteils verbunden. Eine seltsame Erdung des LAN-Kabels könnte also 
direkt galvanisch auf die Schaltung durchschlagen, wenn es bei Deinem 
auch so ist.

: Bearbeitet durch User
von svensson (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

hatte ein ähnliches Problem mit genau diesem Modul, vgl. hier:

Beitrag "Problem WIZnet W5500 auf Tenstar"

Der Aufruf von Ethernet.Softreset() hat alle Probleme beseitigt. 
Funktioniert auch noch nach Hunderten von Anfragen. Alle 24h mache ich 
zusätzlich noch einen Hardwarereset, der aber wesentlich länger dauert 
als der Softreset.

Ich vermute daher nach wie vor, daß da ein internes Problem vorliegen 
könnte, weshalb er dann nicht mehr auf Pakete reagiert.

von Spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi
>Ich vermute daher nach wie vor, daß da ein internes Problem vorliegen
>könnte, weshalb er dann nicht mehr auf Pakete reagiert.

Vieleicht sollte man einfach nur die Orignal Module von WIZNET benutzen. 
Die funktionieren. Aber Geiz ist ja bekanntlich Geil.

MfG Spess

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Antworten.

Es ist nicht so, daß sich der W5500 aufhängt oder bockt, es gibt (gab) 
System-RESETs des DUE und damit des Gesamtsystems.

Eine Erdschleife lag/liegt nicht vor

Alle Switches sind Gbit-Typen. Im Arbeitszimmer und im Keller sind nicht 
die selben und auch nicht die baugleichen Switches.

Den anderen Thread "Problem WIZnet W5500 auf Tenstar" kenne  ich, ich 
werde vorsichtshalber ebenfalls einen zyklischen RESET des WIZNET 
einbauen. Leider hat mein System einen Designfehler, der Hardware-RESET 
für den W5500 ist mit dem des TFT-Displays verbunden, so daß ein 
zyklischer Reset nur des nachts nicht auffallen würde. Leider kann ich 
die existierende Schaltung nicht ohne größeter Umbauten ändern.

Stromversorgung:  Ich denke, daß der WIZNET im Keller vielleicht stärker 
arbeiten muß und damit größerer Spikes auf der Versorgungsleitung 
erzeugt, die aufgrund der dubiosen RESET-Schaltung  des DUE auf diesen 
durchschlägt. Der W5500 nimmt laut Datenblatt beim Senden bis zu 128 mA 
auf. Da die 3,3 V auf dem Due im Gegensatz zu dem Arduino MEGA mittels 
Schaltregler erzeugt werden, ist die Ausregelung so eine Sache. Mit dem 
Oszi habe ich mir das noch nicht angesehen, werde ich aber prüfen. Als 
Workaround habe ich einen 1-Ohm Widerstand in die VCC Leitung zum W5500 
und einen 1000 uF Siebelko eingelötet. Damit funktioniert das (ca 5 
Stunden getestet). Weitere Langzeittests sind natürlich vorgesehen.

Yogy

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Ist dies ein Original DUE ? Das W5500 Modul zieht wie schon erkannt sehr 
viel Strom.  Ich hatte schon mal das Problem das die Spannungsversorgung 
bei den Nachbauten zu dünn bemessen war. Thermisch wurde dies so heiß 
das die PTC Sicherung auslöste. Der Querschnitt der Speicherspule und 
die Fläche des Reglers waren viel zu klein. Wenn noch ein TFT etc. dran 
hängt könnte die Versorgung überfordert sein.

Auch beim Original war es besser die externe Stromversorgung zu 
verwenden als die USB Port mit dem W5500 Modul drauf.

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Ist dies ein Original DUE ? Das W5500 Modul zieht wie schon erkannt sehr
> viel Strom.  Ich hatte schon mal das Problem das die Spannungsversorgung
> bei den Nachbauten zu dünn bemessen war. Thermisch wurde dies so heiß
> das die PTC Sicherung auslöste. Der Querschnitt der Speicherspule und
> die Fläche des Reglers waren viel zu klein. Wenn noch ein TFT etc. dran
> hängt könnte die Versorgung überfordert sein.
>
> Auch beim Original war es besser die externe Stromversorgung zu
> verwenden als die USB Port mit dem W5500 Modul drauf.

"Mein" Due ist Chinaware. Auch viele der in D angebotenen DUEs stammen 
aus China, zum Beipsiel fehlt auch bei den meisten in D angebotenen DUEs 
der Uhrenquarz.

Mein System ist so ausgelegt, daß der 3,3 V Regler (Ist übrigens ein 
Linearregler, der 5 V Vorregler ist ein Schaltregler, sorry) auf der DUE 
PCB für den DUE selber und den W5500 sowie ein paar eher sparsame Module 
zuständig ist. Das 7'' große Touch-TFT sowie ein weiteres LCD mit 
Hintergrundbeleuctung werden von einem getrennten 5 V Schaltregler 
versorgt. Die DUE Regler werden höchsten handwarm.
Aber danke für den Hinweis, ich werde das beobachten und ggf. einen 
externen 3,3 V Regler dazubauen.

von Reiner O. (elux)


Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Alle Switches sind Gbit-Typen. Im Arbeitszimmer und im Keller sind nicht
> die selben und auch nicht die baugleichen Switches.

Zuerst einmal: ich kann lesen und weiß auch, dass es hier um einen W5500 
an einem Arduino DUE geht.

Hallo Hanns-Jürgen,

ich hatte mal ein ähnlich gelagertes Problem mit den ENC28J60 Chips am 
Arduino mini pro, das sich nicht ergründen liess, dafür aber 
rekapitulierbar auftrat.
In meinem Arbeitsraum habe ich ein 100 MBit Netzwerk mit einem NoName 
Switch. An diesem liefen mehrere (!) Geräte, die u.a. der hier im 
Forum als Michael_U bekannte User und ich gebaut hatten völlig 
einwandfrei.
Sobald die Geräte aber an ihrem vorgesehenen Einsatzort (an meinem 
GBit-Netzw.) verbaut waren, rammten sie sich nach etwa 7 min 
rekapitulierbar im Netzwerktreiber fest.
Was soll das sein? Hardware und Software scheiden aus -> in Michael_Us 
GiB-Netzwerk liefen sie völlig ohne Probleme und am reinen 100MB 
Netzwerk bei mir liefen sie auch problemlos lange Zeit. Die Software war 
ein unaufregender Arduino Sketch mit einer ENC Bibliothek, die x Leute 
verwenden  und keiner hat ein Problem damit. Jedenfalls ist mir da 
nichts Diesbezügliches bekannt.
Die Stromversorgungen blieben in allen Fällen die gleichen Wandwarzen.
Es muss wohl an meinem GB Switch liegen(der GB Switch ist hier irgend 
ein TP-LINK); entweder das der beim Umschalten auf 100 MBit Mist macht 
oder die ENCs irgendwas nicht verstehen. Als die entwickelt wurden gab 
es noch kein GB-NW denke ich.
Weitere Hardware kann ich auch ausschliessen; ich habe ein Gerät mit 
einem funkelnagelneuen Patchkabel direkt an den Switch angeschlossen -> 
das selbe Verhalten.


Ich hatte seinerzeit noch ein bißchen rumtrainiert ohne greifbare 
Erfolge und habe dann beschlossen, das Problem zu ignorieren -> für 5€ 
mehr gibt es in China etwas, das läuft auch(OrangePi Zero unter OpenWRT) 
und macht nicht solche Zicken. Irgendwie ist es aber schon ziemlich 
dekadent, ein ganzes Linux hochzufahren nur um einen Sensor per SPI 
abzufragen und ein paar Relais zu schalten, aber ich hatte es halt 
eilig...

Diese Aktion ist mir beim Lesen Deines Threads wieder eingefallen. 
Möglicherweise geht es ja auch bei Dir auch in diese Richtung.

Gruss aus Bestensee

Elux

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Das Problem bei der China Ware ist eben das man nur schwer abschätzen 
kann wie die Hardware gebaut wurde. Gerade was das Design der PHY angeht 
etc. Man kann auch viel falsch machen mit dem W5500...

Das die Switch die Ursache sein könnte ist völlig abwegig, er das die 
Hardware schlecht gebaut wurde! Wie schon angesprochen muss man bei der 
Kopie der Kopie damit rechnen. Hier werden gerne mal kosten optimierte 
Modifikationen vorgenommen.

Wie erwähnt ist beim Original DUE mit dem Shield die Versorgung 
grenzwertig. Ich kann mich wage erinnern das Peaks von 300mA keine 
Seltenheit waren. Sehr robust ist der W5500 diesbezüglich der 
Spannungsversorgung nicht...

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Spikes  u/o
> Powerdips auf der 3V3 Leitung könnten einen reset erzeugen. Ich habe
> daraufhin als ersten Workaround testweise die Stromversorgung des W5500
> von der DUE-Leiterkarte getrennt und zudem mit einem "dicken" Elko
> versehen.

Das hatte ich erwartet, wollte es nur nicht schon wieder schreiben, weil 
einige von meinen ständigen Wiederholungen dieses Themas schon genervt 
sind.

Bei Netzwerk Schnittstellen ist stabile Stromversorgung wirklich wichtig 
und oft der Knackpunkt. Leute unterschätzen die Auswirkungen der stark 
schwankenden Stromaufnahme dieser Schnittstellen.

von Mitlesa (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Das hatte ich erwartet, wollte es nur nicht schon wieder schreiben, weil
> einige von meinen ständigen Wiederholungen dieses Themas schon genervt
> sind.

Ich kann dich in deiner Warnung nur unterstützen. Von den W5100
Chips (ich weiss dass es hier um W5500 geht) weiss ich dass sie
glühend heiss werden, und zwar nicht nach dem Einschalten sondern
nach dem Benutzen / Aktivieren. Wenn man das nicht genügend
respektiert geht da sehr schnell etwas in die Hose. Die Strom-
versorgungen der diversen Module (Arduino & Konsorten) sind
sowieso nur auf das Nötigste beschränkt.

Ich stelle mir schon wieder in Gedanken vor wie hemdsärmelig
in Stromversorgung und Aufbau so manche Verwirklichung eines
Projekts daherkommt .... da kann man oft nur die Hände über
dem Kopf zusammenschlagen.

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Nochmals ddanke für die erneuten Hinweise, insb. durch elux.

Bei mir ging/geht es MICHT um ein A"Aufjängen" des W5500, sondern um 
einen RESET (vwrmutlich Power-Up Masterreset) des SAM3x( des DUE.

Ursache ist offenbar die Stromversorgung, ich werde das Konzept nun 
grundsätzlich ändern, damit die 3,3 V des DUE nicht noch anderweitig 
"verbraucht" werden.

So, heute ist Sonntag, da gehe ich in den sonnigen Garten...

Viele Grüße, Yogy

von Tobi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe exakt das selbe Problem, nur mit einem Arduino Mega und bei mir 
ist es nicht der Keller, sondern der Dachboden... Benutze aber auch ein 
W5500.

Insgesamt bekomme ich über den Tag verteilt so 20 Abstürze mit Neustart 
des Arduino.

Ich habe an dem Arduino so ein Relaismodul mit 24 Relais drauf. Ich 
dachte auch erst, es wär ein Problem des Netzteils - ich konnte den 
Spannungsabfall sehr gut beobachten, wenn ich alle Relais nacheinander 
eingeschaltet hatte und dachte vllt dass es zu viel wird und das 
Netzteil abschaltet. Das ist aber nicht so. Zumal das Abstürzen 
unabhängig davon passiert, ob ich die Relais ansteuere oder nicht. Die 
meiste Zeit sind sie halt auch aus. Hab dann zusätzlich zum Netzteil an 
der Hohlbuchse ein USB Netzteil angesteckt. Das hat die Abstände 
zwischen den Abstürzen verlängert - das könnte aber auch ein 
Placeboeffekt sein...

Wenn ich das ganze in mein Arbeitszimmer anschließe, habe ich allerdings 
auch merkbar weniger Abstürze. Ich habe mehrere Netzteile ausprobiert 
darunter auch sehr teure von Siemens. Ich konnte keine Hitzeprobleme 
feststellen. Hatte das auch mit Wärmekameras überprüft und diese sogar 
24 h lang aufzeichnen lassen um so einen Absturz beobachten zu können. 
Ich konnte allerdings auch nur den W5500 Shield filmen und nicht den 
kompletten Arduino Mega. Ich habe dann gedacht, dass es vllt an der 
Länge des Netzwerkkabels lag (im Arbeitszimmer wars ein 1 m Stück, aufm 
Dachboden ein 10 m Kabel). Habe dann das ganze aufm Dachboden mit 
demselben 1 m Kabel an dem Switch verbunden, auch das hat nix gebracht. 
Ich verwende übrigens auf dem Dachboden wie im Arbeitszimmer denselben 
Switch. Ein 1 Gbit/s Modell.

Ich hab's bis heute jedenfalls nicht wirklich lösen können. Hab dann die 
Zustände auf dem EEPROM gespeichert, damit er sich nach dem Neustart 
wieder seinen Zustand recovern kann. Wenn der EEPROM dann irgendwann 
kaputt ist, werde ich wohl auf einen Raspberry Pi umsteigen.

Wenn ich das zusätzliche USB Netzteil abziehe, finden auch andere 
"Abstürze" statt. Dann kommt es nämlich hin und wieder (vllt. 2-3x die 
Woche) zum Aufhängen des W5500. Der will dann einfach keine IP beziehen 
und ich muss dann immer hoch und den Arduino + W5500 neustarten. Mit dem 
zusätzlichen USB Netzteil passierte das bisher noch nie.

Sehr nervig das ganze.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Tobi schrieb:
> Ich hab's bis heute jedenfalls nicht wirklich lösen können.

Falls es Dir doch irgendwann mal gelingt, wäre ich sehr an einem Bericht 
interessiert.

von svensson (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also in meinem Fall lag es weder am Modul selbst (mehrere Module 
verwendet) noch an der Stromversorgung (mehr als 1000µF in der Zuleitung 
bzw. komplett getrenntes Netzteil). Eine Häufung schien hingegen bei 
einem stark belasteten Netzwerk aufzutreten.

In meinem Fall wurde auch nicht der Arduiuno resetet, sondern nur das 
Modul reagierte einfach nicht mehr.

> Vieleicht sollte man einfach nur die Orignal Module von WIZNET benutzen.
> Die funktionieren. Aber Geiz ist ja bekanntlich Geil.
Hätte ich ja sogar gemacht, wenn ich einen Distributor gefunden hätte.

von Spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

>Hätte ich ja sogar gemacht, wenn ich einen Distributor gefunden hätte.

WIZnet hat eigene Shops.

MfG Spess

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Tobi schrieb:
> Ich habe exakt das selbe Problem, nur mit einem Arduino Mega und bei mir
> ist es nicht der Keller, sondern der Dachboden... Benutze aber auch ein
> W5500.
>
>

Hmm, die RESET-Schaltung des MEGA ist anders (besser) als beim DUE, 
daher wäre IMHO hier zunächst ein Watchdogproblem auszuschließen. Also 
Watchdogfunktion abschalten und dann testen bzw. die RESETS der Ursache 
nach zaehlen (und abfragen können)

Bei mir baue ich zur Zeit eine getrennte 3,3 V Versorgung für den W5500 
ein...

Yogy

von svensson (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Spess53 schrieb:
> WIZnet hat eigene Shops.

Ich kann (dienstlich) leider nicht so ohne weiteres überall bestellen. 
Irgendein Problem gab es damals, die hatten es nicht da oder wollten 
nicht gegen offene Rechnung liefern.

Daher bin ich dann bei dem Tenstar-Modul gelandet.

von Spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
H

>Ich kann (dienstlich) leider nicht so ohne weiteres überall bestellen.

Mein Chef hat vor eniger Zeit probemlos von dort Module bekommen.

MfG Spess

von Spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
H

>Ich kann (dienstlich) leider nicht so ohne weiteres überall bestellen.

Mein Chef hat vor einiger Zeit probemlos von dort Module bekommen.

Und das nächste Mal sagst du, das du Tenstar Robot meist. Es gibt 
nämlich auch seriöse Firmen dieses Namens.

MfG Spess

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Zwischenstand, nicht positiv...

Nach einem Übernachttest im Keller mit neuer Stromnversorgung mußte ich 
dennoch einige wenige RESETS feststellen. Diese korrelierten mit dem 
(lastfreien) schalten eines Relais (12 V Typ, Relaistreiber ist ein ULN) 
,  sodaß die Geschichte offenbar NICHTS mit dem W5500 zu zun hat, 
sondern mit einem EMV Problem. Ob das über die Stromversorgung 
einkoppelt oder über die RESET Geschichte, werden neue Tests zeigen, so 
hoffe ich...

von svensson (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie Tenstar und Tenstar Robot sind zwei verschiedene Firmen?

Ich habe die Module bei einem deutschen Zwischenhändler gekauft.

Kann mir irgendwie nicht vorstellen, daß die Probleme von einem 
fehlerhaften Hardwaredesign der Module stammen könnten, denn so viel 
Technik ist da ja gar nicht drauf. Und die Probleme gibt es auch mit 10 
Mbit.

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Zwischenstand, nicht positiv...
>sodaß die Geschichte offenbar NICHTS mit dem W5500 zu zun hat,
> sondern mit einem EMV Problem

Haha..

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Hanns-Jürgen M. schrieb:
>> Zwischenstand, nicht positiv...
>>sodaß die Geschichte offenbar NICHTS mit dem W5500 zu zun hat,
>> sondern mit einem EMV Problem
>
> Haha..

Ich freue mich immer wieder, wenn ich zur Erheiterung beitragen kann. 
Ährlich.

Gerade jetzt in der Coronita-Krise sollte man haklt nicht alles so eng 
sehen, und auch einmal lachen... Caramba, Caracho, Corona....

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Status:

Seit nunmehr über 50 Stunden läuft das System im Keller absturzfrei. Das 
Problem dürfte damit gelöst sein, es ist/ wsr die dubiose RESET 
Schaltung des SAM3X8 Prozessors.

Die ist auf der Arduino-DUE Platine gemäß der Vorgaben im Datenblatt 
ausgebaut: Intern ist der RESERT Pin NRSTB über einen 10..15 kOhm 
Widerstand mit VCC (VDDIO) verbunden, Extern hängt ein 10nF Kondensator 
am RESET Eingang, der dann ebenfalls mit VCC verbunden ist. Unglaublich. 
Was sol das? Ein Fehler im Datenblatt? (Punkt 6.5 NRSTB-Pin).

Spikes auf der Versorgungsleitung werden also direkt zum RESET-Pin 
weitergeleitet. Was für eine diletantisch entworfende Schaltung!

Als Workaaround habe ich nun den NRSTB-Pin über einen 120 OHM Widerstand 
mit VCC verbunden. Das behindert nicht den Start-Up. Aber es brachte die 
Lösung.

Beim ohnehin eingeplanten Redesign "meiner" Leiterkarte ("Motherboard") 
werde ich eine eigene Resetschaltung mit Hardware-Watchdog vorsehen.

Tja, das arme China-W5500-Modul war es dann wohl doch nicht...

Have a nice Mayday, Yogy

von Mitlesa (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Was für eine diletantisch entworfende Schaltung!

Da bedarf es wohl einer kleinen Zurechtrückung deiner Ansichten.

Nicht die ArduinoDue-Designer oder Atmel hat einen Fehler gemacht
sondern du.

Du hast dafür zu sorgen dass kein Spike an die Reset-Leitung
gerät. Denn wie sollen denn die Arduino-Designer voraussehen
in welcher rauhen Umgebung das Teil laufen soll. Die Versorgungs-
Spannung wird auf dem Board stabilisiert, das ist alles. Sie
kann nicht unter allen Umständen für eine Entstörung sorgen
damit bloss kein Störfünkchen in die Schaltung gerät. Wie
sollte das denn praktikabel sein?

von Marco H. (damarco)


Bewertung
-1 lesenswert
nicht lesenswert
So ein Blödsinn! Der Reset ist LOW aktiv. Wenn der WDT auslöst dann weil 
seine Versorungspannung einbricht. Ob ein Hardware oder Software Reset 
ausgelöst wurde lässt sich anhand eines Registers feststellen.

Dein 120Ohm Widerstand bringt rein gar nichts, denn die 10-15K sind 
nicht ohne Grund dort angeben ! Bau doch einen Default Handler und lese 
das Register aus, setzte einen PIN mit LED ! Mit einen SWD Interface 
kann man sogar schauen was als letztes Aufgerufen wurde. So lange dein 
Default Handler keinen Softreset ausführt.

: Bearbeitet durch User
von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Mitlesa schrieb:
> Hanns-Jürgen M. schrieb:
>> Was für eine diletantisch entworfende Schaltung!
>
> Da bedarf es wohl einer kleinen Zurechtrückung deiner Ansichten.
>
> Nicht die ArduinoDue-Designer oder Atmel hat einen Fehler gemacht
> sondern du.


Es gibt bei mir keine Reset Leitung. Der Reset-Pin auf der DUE 
Leiterkarte st nirgendwo angeschlossen. Zudem erfolgt die besagte 
Ansteuerung eines 12V-Relais, das aktuell keine Last steuert, mit einem 
ULN2003, der die Suppression-Dioden enthält. Die verwendete 
Relaisplatine mit SPI-Schnittstelle habe ich vor knapp 20 Jahren 
entwicklelt und läuft in verschiedenen Projekten. Sie enthält auch 
Ablockkondensatoren auf der 12 V und der 5V Versorgungsleitung; die 5V 
kommen übrigens nicht von dem Arduino-Regler.

>
> Du hast dafür zu sorgen dass kein Spike an die Reset-Leitung
> gerät. Denn wie sollen denn die Arduino-Designer voraussehen
> in welcher rauhen Umgebung das Teil laufen soll. Die Versorgungs-
> Spannung wird auf dem Board stabilisiert, das ist alles. Sie
> kann nicht unter allen Umständen für eine Entstörung sorgen
> damit bloss kein Störfünkchen in die Schaltung gerät. Wie
> sollte das denn praktikabel sein?

Praktikabel für einen harte Industrieumgebung ist das natürlich nicht, 
das ist auch nicht die Anforderung an eine Arduino-Platine. Aber ich 
erwarte eine funktionierende Reset-Schaltung unter Haushaltsbedingungen. 
Alle meine anderen Prozessorplatinen (Eigenentwicklungen insb. mit/für 
AVRs, PIC16F64, Motorola 6809, Motorola 68HC11) hatten und haben keine 
Reset-Probleme.

von Marco H. (damarco)


Bewertung
-1 lesenswert
nicht lesenswert
"The NRST pin is bidirectional. It is handled by the on-chip reset 
controller and can be driven low to provide a resetsignal to the 
external components, or asserted low externally to reset the 
microcontroller. It will reset the Core andthe peripherals except the 
Backup region (RTC, RTT and Supply Controller). There is no constraint 
on the lengthof the reset pulse, and the reset controller can guarantee 
a minimum pulse length. The NRST pin integrates a permanent pull-up 
resistor to VDDIO of about 100 kΩ"

mal nachgeschaut.. Lässt sich auch als Ausgang setzen ! Somit kann die 
Wirkung dieses PINs konfiguriert werden. Ich vermute das die Arduino IDE 
so setzt das dieser keine Wirkung besitzt.

Dein 120Ohm Widerstand hätte jedenfalls eine Enorme Wirkung...

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Lässt sich auch als Ausgang setzen !

Nein, der Pin ist immer gleichzeitig Eingang und Ausgang. Die Richtung 
kann man nicht konfigurieren. Er wird im Open-Drain Modus mit (internem) 
Pull-Up Widerstand betrieben.

Allerdings kann man den Chip so konfigurieren, dass ein Signal an diesem 
Pin die CPU nicht neu startet.

: Bearbeitet durch User
von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Das meinte ich ja, es ist auch ein Ausgang mit 120Ohm dran... Ich 
vermute auch das zumindest im Framework der Pin keine Funktion als 
Eingang besitzt. Müsste man einmal nachschauen... Er kann ja mal den Pin 
mit den internen pull-up gegen GND ziehen und schauen was passiert.

Das ganze funktioniert bidirectional, externe Hardware ist in der Lage 
einen Reset auszuführen und die externe Hardware macht einen Reset wenn 
der SAM einen ausführt. Dafür gibt es auf einen Arduino Board natürlich 
kaum eine Verwendung.

: Bearbeitet durch User
von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> "The NRST pin is bidirectional. It is handled by the on-chip reset
> controller and can be driven low to provide a resetsignal to the
> external components, or asserted low externally to reset the
> microcontroller. It will reset the Core andthe peripherals except the
> Backup region (RTC, RTT and Supply Controller). There is no constraint
> on the lengthof the reset pulse, and the reset controller can guarantee
> a minimum pulse length. The NRST pin integrates a permanent pull-up
> resistor to VDDIO of about 100 kΩ"
>
> mal nachgeschaut.. Lässt sich auch als Ausgang setzen ! Somit kann die
> Wirkung dieses PINs konfiguriert werden. Ich vermute das die Arduino IDE
> so setzt das dieser keine Wirkung besitzt.
>
> Dein 120Ohm Widerstand hätte jedenfalls eine Enorme Wirkung...

Schon richtig, was Du schreibt. Der NRST Pin ist bidirektional.

Nur ist auf der Arduino-DUE Platine der NRST Pin "not ocnnected". Als 
Reset Eingang wird der NRSTB-Pin benutzt, und der ist grundsätzlich und 
immer ein Eingangspin.

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Nein er ist grundsätzlich immer ein Ausgang! Siehe den Ausschnitt den 
Stefan angehängt hat.  Die Wirkung als Eingang lässt sich beeinflussen 
und wie er schon angedeutet hat auch abschalten. Siehe Seite 223....#

Sobald der SAM einen Reset macht zieht er den Pin nach Low und das über 
deinen 120Ohm pull-up... Autsch... Als Hinweis der Port macht maximal 
2mA!

: Bearbeitet durch User
von Hanns-Jürgen M. (yogy)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, aber der NRSTB Pin ist grundsätzlich und immer ein Input.

(NRST ist nicht NRSTB)

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Wir haben es so verstanden das der nicht benutze NRST Pin das Problem 
ist.

Diesbezügliche Probleme sind immer auf die Versorgungsspannung 
zurückzuführen. Der SAM hat einen eigenen Supply Controller...

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte nirgends den NRST Pin erwähnt. Der ist übrigens beim DUE nicht 
verdrahtet/herausgeführt, also ohne Leiterbahn (vom Lötpad mal 
abgesehen).

Die Einstreung kam offenbar über den NRSTB Pin dank dessen idiotischer 
Verschaltung. Und auch nicht unbedingt via Stromversorgung, sonst müßte 
er jetzt auch noch resetten.

In Verdacht hatte ich auch den Borwn-Out Detektor des SAM Controllers, 
aber der ist offenbar zu langsam.

Tja, ein völlige Eigenentwicklung hat durchaus Vorteile.. Aber leider 
habe ich als "alter weis(s)er Hase" nur einen Lötkolben und keine Reflow 
Anlage...

Frohes Schaffen, Yogy

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Nö... Dein Schaltungsaufbau hat ein Problem. Wie ich schon angedeutet 
hatte, DEFAULT Handler benutzen um festzustellen woher der Reset kommt 
und was davor aufgerufen wurde.

Schaltung überarbeiten, damit meine ich nicht den viel zu kleinen 
pull-up am Master Reset.
Wenn du genau überlegst kommt dein Problem aus einer anderen Baustelle.

Grundsätzlich arbeitest du mit "experimentier boards", solch ein 
fliegender Aufbau ist immer problematisch. Um so sorgfältiger muss man 
beim Aufbau eben vorgehen.

Borwn-Out Detektor ist nicht zu langsam, wenn man die Sampling Rate 
korrekt zur Anwendung einstellt.

: Bearbeitet durch User
von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Natürlich hat mein Schaltungsdaufbau ein Problem. Wäre er nicht da, gäbe 
es auch kein Problem.

DEFAULT Handler ist nicht, ich nutze keine ARDUINO SW-Umgebung. Alles 
hardcore bare metal, oder wie das heißt. Und die RESET-Quelle wird bei 
mir sowieso unterschieden.

Wie erwähnt werde ich das "Mainboard" mit den Zusatzschaltungen, auf dem 
der DUE aufgesteckt ist, ohnehin überarbeiten und dabei eine "richtige" 
Resetschaltung realisieren.

Das oben beschriebene Problem ist ursächlich in der untauglichen 
Resetschaltung, wenn man so etwas überhaupt als Schaltung bezeichnen 
kann, begründet, die halt für Entstreuungen Tür und Tor offen hält. Beim 
Schalten eines Relais (ohne angeschlossene Last) traten diese Resets 
auf. Das (Hutschienen-) Modul mit den Relais ist sauber designed, sie 
arbeitet in vielen Anwendungen zusammen mit anderen meiner 
Prozessormodule seit Jahren störungsfrei. Schnittstelle  zur 
Prozessorplatine ist seriell (SPI), Flachbandkabel. Nix fliegender 
Aufbau!

Mein Fehler ist/war, auf eine Arduino Bastlerlösung zurückgegriffen zu 
haben.  Eine besere DUE Version wäre z.B. diese hier gewesen: 
https://www.elechouse.com/elechouse/images/product/Taijiuino/

von Marco H. (damarco)


Bewertung
-1 lesenswert
nicht lesenswert
Viel Ahnung vom ARM hast du nicht wenn du nicht einmal weißt was der 
DEFAULT Handler ist... Das ist eine Funktion die als letztes Aufgerufen 
wird wenn etwas abnormales passiert.. Diese Funktion kann dir helfen 
Register zu sichern und die Ursache des Problems zu finden.

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Viel Ahnung vom ARM hast du nicht wenn du nicht einmal weißt was der
> DEFAULT Handler ist... Das ist eine Funktion die als letztes Aufgerufen
> wird wenn etwas abnormales passiert.. Diese Funktion kann dir helfen
> Register zu sichern und die Ursache des Problems zu finden.

Nein, viel Ahnung von ARM habe ich tatsächlich nicht. Genauer gasgt: Ich 
habe nur sehr wenig Ahnung von diesem Kern.

Daher danke für den Tip, ich mache mich schlau

Yogy

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Das ist eine völlig andere Architektur entgegen einem AVR...

Schau dir das Speicher und ISR Konzept eines ARMs an.  Wenn du aufgrund 
unsauberer Programmierung hier beim zugriff Fehler machst, fällt dir das 
auf die Füße. Ein AVR macht einfach weiter... Die IO-Lib des w5500 ist 
voll solcher Probleme....

Ich kenne ja dein Framwork nicht, Atmel Studio? Da dürfte der Standard 
Handler ein Softwarereset auslösen.

Schau ins Startup file... Von Joseph Yiu gibt sehr gute Bücher hierzu ! 
z.Bsp "The Definitive Guide to the ARM Cortex-M3"

: Bearbeitet durch User
von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Ja, ich nutze Atmel Studio 7.

Wie gesagt, ich vermute hier kein SW-Problem, sondern ein Hardware 
Problem über den unsauber verschalteten NRSTB Pin.

Ich habe gestern abend noch ein wenig im Datenblatt (na, eher Buch mit 
über 1000 Seiten). Meintest Du anstelle von "DEFAULT Handler" einen 
"FAULT Handler"? Darüber habe ich etwas gefunden (muß mich aber noch 
schlau machen)

DEFAULT Handler ist eigentlich ein Handler, der angesprungen wird, wenn 
kein "richtiger" Handler implementiert ist. Habe ich das richtig 
verstanden?

Kann der Prozessor überhaupt noch etwas ausführen, wenn der NRSTB Pin 
auf Low gezogen wurde? Kann ich überhaupt beim SAM3X8 no-init Variablen 
definieren/deklarieren, die nach einem NRSTB Reset nicht zerstoert 
werden?
(noinit-Variablen habe ich funktionierend deklariert, z.B. für 
Zählervariablen, die den Watchdog-Reset oder den SoftReset überleben)

Ach ja: ARM vs AVR: Mir ist bekannt und bewußt, daß der ARM Kern, der 
von versch. Prozessorschmieden verwendet wird, etwas völlig anderes ist, 
als AVR, Motorola 68xx oder auch als der gute alte 68000. Deswegen 
versuche ich auch nicht, den SAM (oder einen anderen ARM Kern) in 
Assembler zu programmieren.. Ich habe einfach keine Ahnung davon.

Viele Grüße, Yogy

(In der Restwoche muß ich mich leider um andere Dinge kümmern..)

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Wie gesagt, ich vermute hier kein SW-Problem, sondern ein Hardware
> Problem über den unsauber verschalteten NRSTB Pin.

Nach 50 Beiträgen sollte man genug gelernt haben, dass Vermuten und 
Raten nicht zur Ziel führen.

Wenn schon, musst du deine Vermutung auch überprüfen. Ansonsten bleibt 
sie für immer unbestätigt im Raum und wirst kein bisschen schlauer. Also 
überlege Dir, wie du diese Vermutung bestätigen oder das Gegenteil 
beweisen kannst.

Laut Schaltplan ist der NRSTB Pin am JTAG Anschluss herausgeführt und 
mit einem schwachen 100kΩ Pull-Up Widerstand versehen. Da kannst du zur 
Probe einfach mal ein Dupont Kabel nach 3,3V dran stecken. Dann kann von 
diesem Pin kein Problem mehr ausgehen.

Tritt der Fehler dann immer noch auf, dann war deine Vermutung falsch.

von Hanns-Jürgen M. (yogy)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Hanns-Jürgen M. schrieb:
>> Wie gesagt, ich vermute hier kein SW-Problem, sondern ein Hardware
>> Problem über den unsauber verschalteten NRSTB Pin.
>
> Nach 50 Beiträgen sollte man genug gelernt haben, dass Vermuten und
> Raten nicht zur Ziel führen.
>
> Wenn schon, musst du deine Vermutung auch überprüfen. Ansonsten bleibt
> sie für immer unbestätigt im Raum und wirst kein bisschen schlauer. Also
> überlege Dir, wie du diese Vermutung bestätigen oder das Gegenteil
> beweisen kannst.
>
> Laut Schaltplan ist der NRSTB Pin am JTAG Anschluss herausgeführt und
> mit einem schwachen 100kΩ Pull-Up Widerstand versehen. Da kannst du zur
> Probe einfach mal ein Dupont Kabel nach 3,3V dran stecken. Dann kann von
> diesem Pin kein Problem mehr ausgehen.
>
> Tritt der Fehler dann immer noch auf, dann war deine Vermutung falsch.

Wie oben erwähnt tritt das Problem (Resets) nicht mehr auf, seit dem ich 
den NRSTB-Pin über 120 Ohm mit +3V3 verbunden habe. q.e.d., oder?

Wie ebenfalls erwähnt werde ich das System so ändern, daß eine 
anständige Reset-Schaltung mit zusätzlichem Hardware-Watchdog werkeln 
kann.

Ich vergaß übrigens zu erwähnen, daß ich den R23, über den der 
zuzsätzliche  AVR auf dem Board den SAM resetten kann, ausgelötet habe, 
ebenso wie den T3, der den Erase-schalten kann.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Hanns-Jürgen M. schrieb:
> Wie oben erwähnt tritt das Problem (Resets) nicht mehr auf, seit dem ich
> den NRSTB-Pin über 120 Ohm mit +3V3 verbunden habe. q.e.d., oder?

Das ist mir entgangen. Insofern:

> Wie ebenfalls erwähnt werde ich das System so ändern, daß eine
> anständige Reset-Schaltung mit zusätzlichem Hardware-Watchdog werkeln
> kann.

klingt das vernünftig. Dann gibt es bis dahin eigentlich auch nichts 
weiter zu diskutieren.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.