hallo, derzeit beschäftigt mich folgendes Problem: Zur Evaluierung einer brauchbaren MCU habe ich in meinem Laboraufbau einen Atmega2560 mit einem FT232 USB UART kombiniert. Der Aufbau läuft in der „Self Powered Configuartion“. Zur Statusüberwachung des 2560 dient eine LED an PIN 26 = (OC0A/OC1C/PCINT7)PB7. Diese LED blinkt bei einem gewöhnlichen RESET 2x kurz auf (z.B. bei PowerOn). Das ist so in Ordnung. Verbinde ich jedoch den PIN 2 (DTR#) des FT232 mit dem RESET PIN 30 am 2560, entsteht ein fehlerhaftes RESET-Verhalten ! Die obig beschriebene Status-LED blinkt 15x kurz auf (bei PowerOn). Fast so, als würde der 2560 6,7 oder 8 RESET-Impulse hintereinander bekommen. Trenne ich die Verbindung (PIN2 mit PIN30) dann ist das Verhalten bei PowerOn wieder normal. Allerdings ist die Verbindung PIN2 mit PIN30 zur Programmierung des 2560 zwingend erforderlich, da der FT232 hierüber sein Handshake-Signal für Terminal-Ready bekommt. Der FT232 verweigert also bei getrennter Verbindung das aufspielen der Daten auf den 2560. Jetzt könnte ich im zukünftigen Platinen-Layout einen Jumper vorsehen, der nur dann gesteckt wird wenn der 2560 programmiert wird. Danach wird er gezogen und alles ist gut. Das ist aber nicht wirklich die optimale Lösung, da der zukünftige Benutzer des Systems auch selbst in der Lage sein soll, eine neu Firmware aufzuspielen, ohne dafür vorher erst das Gerät aufschrauben zu müssen und einen Jumper zu stecken ! Kann es sein dass der Auslöser der Mehrfach-Reset's einfach nur Störsignale sind ? Mir ist auch aufgefallen, dass beim einschalten meiner Lupenleuchte die hier am Arbeitsplatz steht, ebenfalls ein Reset ausgelöst wird. Über hilfreiche Tipps wäre ich dankbar Thomas
Hast du den Reset Pin wie im Datenblatt oder der App Note beschaltet? 10 kOmm Pullup und 100nF Kerko. Könnte aber genau so gut über die Stromversorgung kommen. 100nF Kerko zw. VCC und GND möglichst nah an die Pins dann evtl. noch 10-100myH vor VCC
Wenn der besagte PIN als Ausgang geschaltet ist kann er den Resetpin gegen Masse ziehen dann wäre es normal das er errettet
Bei den ersten Arduino gab es ein ähnliches Problem. Abhilfe war eine Diode parallel zum Reset-PullUp. Kathode in Richtung +5V.
Gast
#3729232
Thomas O. schrieb: > evtl. noch 10-100myH vor VCC 10 bis 100 Milli-Yokto-Henry? Da dürfte die Leiterbahn leicht genug Induktivität haben...
[OT] Thomas O. schrieb: > dann wäre es normal das er errettet Scheiss Rechtschreibkorrektur :) [/OT]
das stimmt und das µ habe ich leider auf den Androiden nicht gefunden.
Der ResetPin des 2560 geht über 100nF zu DTR# und ist mit 10k und einer parallelen 1N4007 gegen VCC geschalten. Zusätzlich ist am ResetPin noch ein 22pF gegen GND geschaltet. Die Diode hatte ich schon mal drin. Hatte sie nur wieder herausgenommen da der Vielfach-Reset damit nicht zu verhindern war. Aber die wirkt sich tatsächlich positiv auf Störimpulse aus. Das Ein/Aus-schalten der Lupenleuchte stört bei eingebauter Diode fast nicht mehr. Nur etwa jedes 10te Schalten führt noch zu einem Reset. Jedoch hat sich der Fielfach-Reset bei PowerOn dadurch nicht verbessert. Also unverändert 6-8 Reset's hintereinander. Eine Induktivität habe ich noch nicht getestet. Hoffentlich liegts nicht am Breadboard-Aufbau und den langen Steckbrücken ?! Grüße Thomas
Kann mit DTR auf die schnelle nichts anfangen. Vielleicht erklärst du das nochmal kurz. Tausche mal denn 22pF Kerko gegen 100nF aus. Ich hantiere auch mit sehr langen Leitungen ohne das es zu mehrfach Resets kommt. Habe mal das Bild nicht zu stark verkleinert damit man was erkennt.
Angehängte Dateien:
-
20140717_221920-1.jpg
(770 KB)
DTR# ist der PIN2 "Data Terminal Ready Control Output / Handshake Signal" des FT232. Ich vermute Du hast auf Deinem Foto einen 328er im Betrieb. Der macht diesbezüglich keinerlei Probleme. Einen Atmega328P hatte ich auch schon mal aufgebaut, der hat aber leider zu wenig Flash-Speicher und auch zu wenig Ports. Wenn ich den 22p durch einen 100n ersetze ist das Vielfach-Reset-Problem behoben. Allerdings lässt sich der 2560 dann nicht mehr programmieren. Es ist also im Prinzip der gleiche Effekt wie wenn ich die Verbindung FT232 PIN2 zum RESET-PIN des 2560 ganz trenne, was ich wahrscheinlich über einen Jumper lösen muss, da ich im Moment nicht weiterkomme.
Angehängte Dateien:
-
P7.jpg
(410 KB)
Gast
#3730469
100nF Abblockkondensatoren an JEDEN VCC Pin nicht weiter als 5mm vom IC entfernt SIND PFLICHT UND NICHT OPTIONAL, JA 5mm. Sonst kommt es zu unerklärlichem Verhalten welches Programmabhängig, lageabhängig, Umgebungsabhängig sein kann.
der 2560 hat doch genug Pins zur Verfügung wieso verwendest du ausgerechnet den Resetpin für DTR, jeder andere Pin würde es doch auch tun. Könntest ja auch einen INT PIN verwenden. Was gibt den der FT232 an diese Leitung aus High oder Low, ein High würde ja nichts bewirken da die Resetleitung je eh hochgezogen wird und ein Low (wenn stark genug) würde einen Reset auslösen. Scheint also kein ungewöhnliches Verhalten des AVRs zu sein wenn an seinem Reset pin rumgemacht wird. Was du noch probieren könntest: Ein RC Glied an VCC damit dort die Spannung erst ansteigt nachdem der Resetpegel stabil ist, falls der FT232 hier noch dran rumnuckelt.
und gibts was neues? Problem schon gelöst?
Sorry, ich komme mit dem Laboraufbau per Breadboard einer Lösung des Problems leider nicht näher. > der 2560 hat doch genug Pins zur Verfügung wieso verwendest du > ausgerechnet den Resetpin für DTR, jeder andere Pin würde es doch auch > tun. Könntest ja auch einen INT PIN verwenden. Lt. Schaltplan muss DTR# des FT232 mit RESET des 2560 verbunden werden. Das mit den 100n Abblock-Kondensatoren max.5 mm vom VCC PIN entfern kann ich im Layout-Design der zukünftigen Platine problemlos einfließen lassen. Im Laboraufbau aber nicht. Möglicherweise rührt der Vielfach-Reset ja tatsächlich daher. Ich werde dies dann am ersten Prototyp näher eruieren können. Vielen Dank erst mal Thomas
Hallo Thomas, dann zeig doch mal den Schaltplan, was ich noch nicht ganz verstehe - die Verbindung soll zum programmieren des μC erforderlich sein!? Wie wird der μC programmiert seriell oder per BitBang. Du schreibst in deinem ersten Post des der MAX ein Signal vom μC bekommt - Reset ist am μC aber nun mal ein Eingang. Kann es nicht eher sein, das der μC per DTR-Leitung vom MAX ein Reset bekommen soll? Sascha
Habe mir das mit DTR mal durchgelesen: Data Terminal Ready ist ein Signal welches Anzeigen soll "das Gerät ist betriebsbereit". Hier soll der ATM2560 also erst starten wenn der FT232 betriebsbereit meldet. Ich würde dieses Signal aber nicht auf den Resetpin hängen. Mir fallen dazu ein paar andere Möglichkeiten ein. 1. ATMega starten lassen und z.B. erstmal auf das Signal (an einem anderem Pin) pollen bis er dann mit dem eigentlichen Programm startet, bzw. kann man schonmal andere Dinge erledigen, bis der FT232 auf Trab kommt. 2. ATMega per Fuses erst 64mSek verzögert starten lassen. Verwende ich z.B. immer alleine schon wegen der Stromversorgung. Schau dir mal die VCC und die Spannung am Resetpin am 2 Kanaloszi an, vielleicht erklärt das schon deine mehrfachen Resets (z.B. sehr langsamer Anstieg der Betriebsspannung oder der Spannung am Resetpin.
Hallo Sascha, programmiert wird der 2560 über die Datenleitungen TXD und RXD. Der Jumper ist die Notlösung und gehört da eigentlich nicht rein.
Angehängte Dateien:
-
P8.jpg
(150 KB)
Hallo Thomas, die Lösung nach Variante #2 von Dir hatte ich mir auch schon überlegt, konnte aber im AtmelStudio auf die schnelle dafür keine Einstellmöglichkeit finden. Welche Fuses sind das denn mit denen man ein Zeitverzögertes Starten einstellen kann ? Das würde ich gerne mal testen. Grüße Thomas
Die Schaltung mit dem DTR wird bei den Arduino verwendet um den Bootloader zu starten. Schau dir die Schaltung vom Arduino Nano mal an, dort wird ein FT225RL verwendet. Fuseeinstellungen findest du hier. http://www.engbedded.com/fusecalc/ Für den Oszillator ist es die letzte. Du solltest auch BrownOut Detection auf 4,3V aktivieren.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.