Hallo Miteinander, ich suche hier in diesem super Forum öfters mal nach einer Lösung und bin bis jetzt auch immer fündig geworden, aber jetzt habe ich ein Problem, an dem ich mir schon einen ganzen Tag vertrödelt habe und keine Lösung gefunden habe, weshalb ich mich angemeldet habe und selbst mal einen Tread eröffne. Ich beschreibe mal in groben Zügen mein Projekt: Ich baue zur Zeit eine automatische Beladeanlage für eine Maschine mit einigen Schrittmotoren, Relais und Magnetventilen, die von insgesamt 4 Arduino Nano-Boards V3.0 gesteuert werden sollen. Diese bekommen ihre Daten von einem zentralen Touchscreen-PC, der an eine MySQL-Datenbank angebunden ist, in der die Programmabläufe und Anfahrtmaße hinterlegt sind. Die nanos habe ich gewählt, weil die preiswert sind und eigentlich schon alles mitbringen was ich brauche (USB und Spannungsversorgung). Die Programmierung ist in Bascom mit ISP-Programmer erfolgt (der Bootloader ist überschrieben) und funktioniert auch, bis auf den Fehler, dass bei seriellem Schreibzugriff auf die Arduino Nano Boards ab und zu ein Auto-Reset ausgeführt wird (aller 3-10 abgeschickter Befehle). Ich habe daraufhin das Internet durchforstet und auch etwas gefunden. Folgende Ratschläge habe ich der Reihe nach an drei verschiedenen Boards (1 x original mit FT232, 2 x Klones mit CH340) abgearbeitet: - C4 ausgelötet (Verbindung DTR - Reset) - 120 Ohm Wiederstand von 5V nach Reset - 10uF Elko von Reset nach GND - alles zusammen - dann noch Reset mit 5V gebrückt (habe ich mir selber ausgedacht) Das hat alles nicht zu einer sicheren Unterdrückung des Auto-Resets geführt, so dass ich vermute, dass das bei den Nano-Boards irgendwie anders gelöst ist. Dazu habe ich trotz intensiver Recherche leider nichts mehr gefunden. Ich kann mir nicht vorstellen, dass nur ich das Problem habe, daher bitte ich alle, die zu diesem Problem eine Idee oder Lösung haben, mir mit einem Beitrag zu helfen. Vielen Dank! Gunter
"One of the hardware flow control lines (DTR) of the FT232RL is connected to the reset line of the ATmega168 or ATmega328 via a 100 nanofarad capacitor" Ausfindig machen und auslöten oder zerstören ;)
Danke, das ist der C4, den habe ich als erstes ausgelötet .... Gunter
Oh, den Punkt hatte ich überlesen. Den richtigen C haste aber entfernt (Rückseite über A2/A3). Kannst du einen Fehler vom Programm ausschließen, der deinen Controller resetet? 5V direkt vom Reset würde ich wenn möglich wieder runternehmen. Denn wenn du nun den Reset drückst, bauste dir einen schönen Kurzschluss.
:
Bearbeitet durch User
... dass keine Verbindung mehr ist, habe ich nachgemessen. Der das Programm ist zwar noch nicht bis auf's letzte getestet, ich habe aber einige Tests gemacht. Wenn nur der Arduino arbeitet und von sich aus sendet, funktioniert alles prima und ausdauernd. Sobald ich aber was hinschicke, geht es manchmal, manchmal stürzt er ab. Vielleicht habe ich einen Programmfehler, aber soweit ich gelesen habe, ist es ziemlich schwierig, den Controller per Software zu resetten. Pin PC6 habe ich in der Konfiguration nicht angefasst. Gunter
Gunter Dünnbier schrieb: > aber soweit ich gelesen habe, > ist es ziemlich schwierig, den Controller per Software zu resetten Das geht einfacher (schneller) als Du denkst! :)
... aufhängen und festfahren ja, aber ein sauberer Reset mit neuem Programmstart und dass genau zu dem Zeitpunkt, an dem die Daten am Arduino eintreffen ...? Gunter
nein, eine nicht vorhandene ISR genügt... Brownout, EMV Probleme usw. sind auch immer mögliche Ursachen für spontane Abstürze. Aber wie du das beschreibst, tippe ich auf deine Software...
Hast du ggf. einen einfachen Logik Analyser oder ähnliches rumliegen? Denn könntest du mal an Reset packen und Triggern sobald es einen Flankenwechsel gibt.
... Danke für die Hinweise, ich habe heute mit dem Oszi den Port beobachtet, dabei aber nichts gesehen (ist kein digitaler), einen Logiktester habe ich leider nicht. Ich will die Software nicht ausschließen, aber ich gebe zu bedenken, dass, obwohl ich immer den selben String zum Test losschicke, es machmal beim ersten mal resettet, im besten fall nach 20 mal, es ist also nicht richtig reproduzierbar. Gunter
... schrieb: > nein, eine nicht vorhandene ISR genügt... Falsch, das ist bei C so, in Bascom steht ohne ISR einfach ein RETI im Interruptvektor, da passiert also gar nichts. Hört sich aber so an, als ob der TE nur da sucht, wo's hell ist, denn da wo's dunkel ist, sieht er ja nichts. Ein Softwarefehler, Array-/Stacküberlauf kann gar lustige und interessante Auswirkungen haben.
Besorge dir den Beitrag "10 Euro Logikanalyzer" ein Scope ist hier sinnlos, sowie das Arduino Geraffel.
Guten Morgen, super Forum - da wird bis nach Mitternacht gearbeitet. Der Tip mit dem Stack war's, man sieht den den Wald manchmal vor lauter Bäumen nicht. Jetzt, nach dem Verdoppeln der Stack- und Framewerte läuft es sauber. Ich hätte bei Überlauf eigentlich ein Festhängen oder Überschreiben von Variablen anstatt eines sauberen Neustarts erwartet - man lernt eben nie aus ... Ich möchte allen Beteiligten noch mal vielen Dank sagen. @ Peter: Was meinst Du mit Arduino-Geraffel? Ich finde, die Nano-Boards sind doch super - zumindest jetzt, seit sie wieder tun was sie sollen ... ;-))) Gunter
Gunter Dünnbier schrieb: > @ Peter: Was meinst Du mit Arduino-Geraffel? Ich finde, die Nano-Boards > sind doch super - zumindest jetzt, seit sie wieder tun was sie sollen Vergiß Peter. Der hat keine Ahnung.
Gunter Dünnbier schrieb: > - 10uF Elko von Reset nach GND Den würd' ich entfernen, der macht dem ISP-Programmer das Leben schwer.
wozu kann man bei Bascom die Stackgrenze künstlich verkleinern? Um mehr SRAM zu reservieren? Wenn du Probleme mit einem Stacküberlauf hast wird irgendwo ein erforderlich Rücksprung wie ret oder reti fehlen oder es wurde häufiger gepush als gepopt das du zuviele Unterprogramme hast kann ich mir weniger vorstellen. Vielleicht kannst du dein .hex-File das dir Bascom erzeugt im AVR-Studio durchlaufen lassen um zu sehen ob dein SRAM immer voller wird und irgendwann überläuft. Lass doch mal am Anfang deines Programms erst mal eine LED 2 mal aufblinken so kannst du einen Reset sicher erkennen, vielleicht zeigen sich ja nur nicht jedes mal die gleichen Auswirkungen so das du manche Resets gar nicht bemerkst. Ansonsten könntest du noch ein paar Vergleiche ins Programm aufnehmen, wenn sich die letzten Stellen im SRAM nicht mehr FF zeigen das eine LED angeht, dann weißt du es ist bald wieder soweit um etwas einfacher debuggen zu können. Als Resetbeschaltung würde ich zu der von Atmel empfohlenen raten 10kOhm Pullup und 100nF Kerkos am Reset. Ansonsten könne in deiner Umgebung eine Filterrung der Versorgungsspannung ratsam sein. Schau dir mal folgende App-Notes an AVR040 Bild 4-1 - 4.3 und 4.7 ich verwende hier immer 10kOhm und 100nF Atmel meint 4,7nF reichen. In AVR042 Note ist unter Bild 6-1 ein Musterbeschaltung eines älteren AT90S8515 dort wurde nochmal etwas mehr aufwand betrieben. Spannungsversorgung mit 4,7µF Tantal, 47nH Drosselspule und 100nF Kerko. Resetpullup mit 4,7kOhm aber ohne Kerko. Was du noch probieren könntest wäre mal die Aktoren abzutrennen vielleicht erzeugen die oder ein einzelner Störungen auf der Versorgungs oder Resetleitung die den Reset verursachen.
Hallo Miteinander! Ich habe noch was vergessen und fasse die Schritte zum Abschalten des Auto-Reset beim Arduino-Board für alle, die später mal vor dem selben Problem stehen und diesen Thread finden, mal der Reihe nach zusammen, in der ich vorgehen würde: 1.) Abschalten von DTR in der Software (Terminalprogramm oder ggf. im Betriebssystem) entweder 2a.) Auslöten des Verbindungskondensators von DTR nach Reset auf dem Arduino-Board (beim Nano 3.0 C4 auf der Unterseite). Das ist die sauberste Lösung, allerdings kann der Arduino dann nur noch über ISP progrmmiert werden oder 2b.) Widerstand mit 120 Ohm vom +5V-Pin gegen den Reset-Pin. Das soll angeblich sich auch noch über USB programmieren lassen (habe ich nicht probiert). Nach entfernen des Widerstandes funktioniert es aber auf jeden Fall wieder. oder 2c.) Elko mit 10uF von Reset nach GND. Auch das lässt sich wieder entfernen und der Originalzustand bleibt erhalten. 3.) Falls das alles nicht geholfen hat, war's vermutlich die Software, so wie bei mir ...;-))) Gunter
Das ist ja gerade das Gute an der Arduino Hardware, da brauchst du gar nichts machen. Die sind absolut robust aufgebaut.
F. Fo schrieb: > Das ist ja gerade das Gute an der Arduino Hardware, da brauchst du gar > nichts machen. > Die sind absolut robust aufgebaut. ... den Kondensator musste ich aber schon auslöten, sonst hat es bei einigen Strings automatisch resettet, warum auch immer. Gunter
@ alle DAS PROBLEM IST GELÖST - DANKE!!!!! @ Thomas O. ich habe den Stack nicht verkleinert, sondern auf die empfohlenen 32 Byte eingestellt. Jetzt habe ich alles verdoppelt und es funktioniert, keine Ahnung warum so viel Stack benötigt wird. Den Weg mit der blinkenden LED beim Programmstart und in den betreffenden Programmteilen bin ich gestern leidvoll gegangen und das hat mich zu dem Schluss gebracht, dass es der Auto-Reset sein muss, der es zum Teil ja auch war. Darauf, dass der Stack zu klein ist, wäre ich nicht gekommen, zumal das Programm ja sofort so sauber neu gestartet wurde. Dank des Forums ist aber nun alles gut. Gunter
Zwischen einem Reset und einem Soft-Restart kann man so unterscheiden: Du reservierst eine I/O leitung für eine Status LED. Die LED lässt du beim Programmstart drei mal blinken. Aber den I/O Pin konfigurierst du erst NACH dem ersten Blinken als Ausgang. Bei einem echten Reset durch den I/O Pin oder Watchdog oder Brown-Out Detektor wird die LED nur zweimal sichtbar blinken. Denn beim ersten Blink istbder I/O Port noch ein Eingang. Bei einem Neustart durch die Software wird die LED dreimal blinken, denn der I/O Pin ist dann bereits ein Ausgang. 100% Zuverlässig ist das zwar nicht, aber einfach und trotzdem hilfreich.
Gunter Dünnbier schrieb: > keine Ahnung warum so viel Stack benötigt wird. Lies dochmal in der Bascom Hilfe nach, was die einzelnen Stacks bedeuten. Ob es am Stacküberlauf liegt, kann man ganz einfach feststellen: Lies direkt am Programmbeginn das MCUSR Register aus und lösche es. Bei einem echten Reset muß darin mindestens eine Reset-Ursache gesetzt sein. Ansonsten ist Dein Programm Amok gelaufen. Beim AVR-GCC gibt es nur einen Stack und daher kann man da auch nichts einstellen. Die globalen Variablen laufen von unten nach oben und der Stack für Calls und lokale Variablen von oben nach unten. Wenns also kracht, sind zuviel Variablen in Benutzung und man muß den Programmablauf ändern.
Hallo Stefan und Peter, danke für Eure Tipps, aber da es jetzt funktioniert, bin ich erst mal zufrieden und will keine weitere Ursachenforschung betreiben. Zu wenig Speicher insgesamt würde ich ausschließen, da ich nur ein sehr kleines Array und nur etwa 20 Variablen verwende und auch das Programm ist nicht allzu lang. Es wird der Stack gewesen sein, da nach dessen Vergrößerung alles sofort funktioniert hat. Warum das so war ist nicht weiter wichtig, Hauptsache es funktioniert. Danke trotzdem! Gunter
Zeige uns doch mal ein Bild von deiner neuen Maschine. :-)
Gunter Dünnbier schrieb: > Warum das so war ist nicht > weiter wichtig, Hauptsache es funktioniert. Naja, zu wissen, wieviel Reserve der Stack noch hat, ist nicht ganz uninteressant. Denn bist Du Dir sicher, das Dein Programm bei dem Testlauf auch den ungünstigsten Fall abgearbeitet hat? Beispiel: Das Hauptprogramm befindet sich gerade in der tiefsten Verschachtelung von Unterprogrammen, wenn der Interrupt eintritt, der selber wiederum Unterprogramme bearbeitet. Der Beweis, ob der Stack im Worst-Case ausreicht, ist sehr schwer zu erbringen. In dem Fall beruhigt es aber, wenn da noch etwas Reserve ist. Aber vielleicht ist Deine Programmstruktur ja so "übersichtlich", dass Dein Test ausreichende Sicherheit gibt. Gruß Dietrich
Gunter Dünnbier schrieb: > Es wird der Stack gewesen sein, da nach dessen > Vergrößerung alles sofort funktioniert hat. Warum das so war ist nicht > weiter wichtig, Hauptsache es funktioniert. Deine Schlußfolgerung ist etwas übermütig. Du hast noch Glück gehabt, daß das Programm recht schnell und reproduzierbar abgestürzt ist. Stell Dir vor, Deine Maschine stürzt dreimal am Tag ab, irgendwann nach Lust und Laune. Dann hast Du absolute Trauer, einen Fehler zu finden. Gunter Dünnbier schrieb: > ich habe den Stack nicht verkleinert, sondern auf die empfohlenen 32 > Byte eingestellt. Jetzt habe ich alles verdoppelt und es funktioniert, > keine Ahnung warum so viel Stack benötigt wird. Ohne jetzt BASCOM näher zu kennen, sind 32 Byte ein Witz. Die werden ja schon benötigt, wenn ein einziges Unterprogramm alle Register retten muß. Nimm als Standard 256 Byte. Wenn das RAM für's Programm zu klein werden sollte, müßte BASCOM sagen, daß nicht genug Platz für Variablen vorhanden ist. Dann könntest Du den Stack ggf. verkleinern.
m.n. schrieb: > Ohne jetzt BASCOM näher zu kennen, sind 32 Byte ein Witz. Die werden ja > schon benötigt, wenn ein einziges Unterprogramm alle Register retten > muß. Ohne Bascom näher zu kennen braucht man auch keine Ratschläge dazu zu geben. Beim Ansprung eine Unterprogramms wird nur der PC gesichert, 2 Byte. Meinst wohl Interrupt?
chipsfrisch schrieb: > Meinst wohl Interrupt? Ich habe ja keine Ahnung, aber geht das in BASCOM? Wahnsinn!
Angehängte Dateien:
-
Schaltkasten_1.jpg
470 KB -
Schaltkasten_2.jpg
370 KB
@ alle Interessierten anbei ein paar Bilder der Schaltkästen der Maschinenteile, die schon fast fertig sind. Die Maschinen als Ganzes möchte ich nicht ins Netz stellen, damit unser Wettbewerb nicht so einfach nachbauen kann. Die Steck-Platinen werden, nach einem ausgiebigen Test dann gegen richtig geätzte getauscht und im Schaltkasten wird etwas aufgeräumt ... Gunter
m.n. schrieb: > chipsfrisch schrieb: >> Meinst wohl Interrupt? > > Ich habe ja keine Ahnung, aber geht das in BASCOM? Wahnsinn! Ok. Bleib besser bei dem was du sonst so machst aber überdenke das sicherheitshalber auch nochmal.
Das der Aufbau überhaupt funktioniert mit diesen Chinastrippen. Da kannst du den EMV Gott loben und preisen. Es gibt auch Adapterbord für die Nanos. http://www.uctronics.com/nano-terminal-adapter-for-arduino-nano-v30-atmega328p-au-p-1702.html
unfassbarer Murks, Steckbrett im Schaltschrank, ohne Worte
EMV schrieb: > Das der Aufbau überhaupt funktioniert mit diesen Chinastrippen. > Da kannst du den EMV Gott loben und preisen. > > Es gibt auch Adapterbord für die Nanos. > ... das funktioniert wunderbar. Bloß weil an dem (sicherlich auch aus China stammenden) Adapterboard ein paar Schraubklemmen dran sind, wird es auch nicht besser. Dort kann ich keine weiteren Bauteile aufbringen, was auf dem Steckbrett hervorragend geht. Wie geschrieben, nach einer längeren Testphase und wenn die endgültige elektronische Schaltung incl. Software steht, bekommt die Elektronik eine geätzte Leiterplatte und alles ist gut. Ich finde, es gibt keine besseren Testmöglichkeit als diese Steckbretter, da kann man schnell mal was dazubasteln, falls sich die Notwendigkeit ergibt oder auch die Schaltung ändern. Aber das muss jeder für sich selbst entscheiden ... Gunter
Gunter Dünnbier schrieb: > Ich finde, es gibt keine besseren Testmöglichkeit als diese > Steckbretter, da kann man schnell mal was dazubasteln, falls sich die > Notwendigkeit ergibt oder auch die Schaltung ändern. > Aber das muss jeder für sich selbst entscheiden ... Da gebe ich Dir recht. Allerdings sollte man bei so einem Aufbau immer im Hinterkopf haben, das mögliche Probleme genau dadurch entstehen. Gerade bei Deinem Reset-Problem hätte ich bei diesem Aufbau zuerst an EMV-Ursachen gedacht... Gruß Dietrich
ttl schrieb: > unfassbarer Murks, Steckbrett im Schaltschrank, ohne Worte ... wer lesen kann ist klar im Vorteil. Ich hatte weiter oben geschrieben, dass das ein Testaufbau ist, der nach der Testphase durch eine richtige Leiterplatte ersetzt wird. Bitte keine weiteren Beleidigungen - einfach selber besser machen und andere in Ruhe lassen. Gunter
> Da gebe ich Dir recht. Allerdings sollte man bei so einem Aufbau immer > im Hinterkopf haben, das mögliche Probleme genau dadurch entstehen. > Gerade bei Deinem Reset-Problem hätte ich bei diesem Aufbau zuerst an > EMV-Ursachen gedacht... > > Gruß Dietrich Hallo Dietrich, bei meinem Test hing nur das Arduino Nano-Modul an der USB-Strippe, manchmel nur noch zusätzlich mit 12V versorgt, daher konnte ich das als Ursache ausschließen. Gunter
Thread beobachten
Seitenaufteilung abschaltenBitte 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.