Forum: Mikrocontroller und Digitale Elektronik Atmega2560 mehrfach-Reset bei Start


von Thomas H. (Firma: Quasar-Astrotech) (magnitudo)


Lesenswert?

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

von Thomas (kosmos)


Lesenswert?

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

von Thomas (kosmos)


Lesenswert?

Wenn der besagte PIN als Ausgang geschaltet ist kann er den Resetpin 
gegen Masse ziehen dann wäre es normal das er errettet

von Hubert G. (hubertg)


Lesenswert?

Bei den ersten Arduino gab es ein ähnliches Problem. Abhilfe war eine 
Diode parallel zum Reset-PullUp. Kathode in Richtung +5V.

von SI-Präfixe (Gast)


Lesenswert?

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...

von Magnus M. (magnetus) Benutzerseite


Lesenswert?

[OT]

Thomas O. schrieb:
> dann wäre es normal das er errettet

Scheiss Rechtschreibkorrektur  :)

[/OT]

von Thomas (kosmos)


Lesenswert?

das stimmt und das µ habe ich leider auf den Androiden nicht gefunden.

von Thomas H. (Firma: Quasar-Astrotech) (magnitudo)


Lesenswert?

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

von Thomas (kosmos)


Angehängte Dateien:

Lesenswert?

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.

von Thomas H. (Firma: Quasar-Astrotech) (magnitudo)


Angehängte Dateien:

Lesenswert?

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.

von uwe (Gast)


Lesenswert?

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.

von Thomas (kosmos)


Lesenswert?

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.

: Bearbeitet durch User
von Thomas (kosmos)


Lesenswert?

und gibts was neues? Problem schon gelöst?

von Thomas H. (Firma: Quasar-Astrotech) (magnitudo)


Lesenswert?

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

von Sascha W. (sascha-w)


Lesenswert?

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

von Thomas (kosmos)


Lesenswert?

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.

von Thomas H. (Firma: Quasar-Astrotech) (magnitudo)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Thomas H. (Firma: Quasar-Astrotech) (magnitudo)


Lesenswert?

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

von Hubert G. (hubertg)


Lesenswert?

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.

: Bearbeitet durch User
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
Noch kein Account? Hier anmelden.