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
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.
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....
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.
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.
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.
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
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.
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.
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
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
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.
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.
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
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...
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.
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.
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
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.
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.
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.
Hi
>Hätte ich ja sogar gemacht, wenn ich einen Distributor gefunden hätte.
WIZnet hat eigene Shops.
MfG Spess
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
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.
H
>Ich kann (dienstlich) leider nicht so ohne weiteres überall bestellen.
Mein Chef hat vor eniger Zeit probemlos von dort Module bekommen.
MfG Spess
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
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...
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.
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..
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....
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
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?
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
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.
"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
Angehängte Dateien:
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.
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
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.
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
Angehängte Dateien:
-
nrstb.gif
9,7 KB
Sorry, aber der NRSTB Pin ist grundsätzlich und immer ein Input. (NRST ist nicht NRSTB)
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...
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
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
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/
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.
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
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
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..)
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.
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.
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.