Hallo. Habe hier einen Atmel Mega 168 am laufen der sich ein wenig merkwürdig verhält. Er gibt aus VCC ca. 2,5V aus, wenn ich in die Pins TXD/RXD einen TTL-Pegel gebe. Dadurch werden sogar die LEDs getrieben, die eigentlich "VCC OK" signalisieren sollen. Das ist nun natürlich unschön. Was auch merkwürdig ist, wenn ich bei eingeschalteten uC per UART etwas drauf schreibe, fängt er von vorne an und hört dann auch nicht mehr damit auf. Per Debugger konnte ich sehen, dass er immer genau bis zu sei() läuft und dann wieder beim main() anfängt. Ich denke hier hat wohl der IC nen Schaden :-) BOT ist disabled und ansonsten sollte er auch kein Reset bekommen. Björn
Björn G. schrieb: > Er gibt aus VCC ca. 2,5V aus, wenn ich in die Pins TXD/RXD einen > TTL-Pegel gebe. Thema Schutzdioden: Von jedem Pin gegen GND bzw. Vcc liegt eine Diode. Ist ganz normal das Verhalten.
Gast
#1290699
Das eigentlich unschoene ist, dass du an einen IC-Pin eine Spannung anlegst, obwohl der IC selbst aus ist. Sowas macht man nicht :) Gruessle
Blöde Sache das. An dem ATMega ist ein FT232R angeschlossen dessen TX/RX immer auf high ist, auch wenn er den PowerOn-Pin noch nicht aktiviert hat (bzw. auf low gezogen hat). D.h. durch den PFet bekommt der uC noch kein Strom, aber die Datenleitungen haben schon Saft. Der POn schaltet erst durch, wenn der FTDI am PC richtig angemeldet ist was nun diesen Zustand mit sich bringt. Aber schon merkwürdig, dass der Atmel bei UART-Daten einfach mal so einen Reset durchführt. Irgendwas ist doch hier total fischig. Björn
Gast
#1290727
Mach doch einfach in die Datenleitung welche zum Avr geht ein Widerstand rein. So 1k - 10k dann sollte die Spannung einbrechen und den Avr bzw die LEDs nicht mehr treiben können - ohne VCC. lg
Auf sowas muß ich wohl zurück greifen. Leider ist die Platine schon fertig. Aber zumindest nur der Prototyp. An diese Möglichkeit habe ich nun wirklich nicht gedacht :-) Björn
Hallo, der FTDI hat in der Beziehung ein etwas unschönes Verhalten. Ich habe dann bei einer ähnlichen Geschichte dann folgende Lösung genutzt: VccIO an der AVR-Spannung, Vcc an ein Port-Pin des AVR und abgeschaltet, wenn nicht gebraucht. Ub vom USB geht an ein AVR-Portpin und der schaltet den ganzen Kram ein, wenn der USB-Anschluß hergestellt wird. Zumindest war dann die Stromaufnahme im Sleep so, wie erhofft. Gruß aus Berlin Michael
Darf man VccIO vom FT2xx komplett auf 0V legen? Das Datenblatt erlaubt dies nirgends explizit, allerdings steht auch nirgends, dass man das nicht darf. Man könnte den Bereich 1,8V-5,2V allerdings so auslegen... Ich habe daher bisher immer zu der Widerstandslösung gegriffen, bzw. den AVR laufen lassen, nur den Rest hinter dem AVR per AVR abgeschaltet.
Björn G. schrieb: > Per Debugger konnte ich sehen, dass er immer genau bis zu sei() läuft > und dann wieder beim main() anfängt. > > Ich denke hier hat wohl der IC nen Schaden :-) Das ist wenig wahrscheinlich. Vermutlich hat eher Dein Code einen Schaden. Wenn man z.B. Interrupts einschaltet, für die es keine Interruptfunktion gibt, kann es leicht zu dem von Dir beschriebenen Verhalten kommen.
Björn G. schrieb: > Er gibt aus VCC ca. 2,5V aus, wenn ich in die Pins TXD/RXD einen > TTL-Pegel gebe. Einfach mal das AVR-Datenblatt lesen. Da gibt es maximale Eingangspegel bezogen auf den VCC-Anschluß! D.h. VCC muß immer zuerst anlegt werden! Peter
Hi Ihr da. @Michael: Ja, das ist wirklich nicht so schick gelöst was FTDI da gemacht hat. Normalerweise gehörten TX/RX im unangemeldeten Zustand auf Tristate und nicht einfach auf high. @Andreas: Du hattest recht mit Deiner Vermutung in Sachen falschem ISR-Namen. Hatte leichtgläubig den UART-ISRNamen eines Mega1280 benutzt was hier nicht zu traf. Ist mir bisher noch nicht aufgefallen, dass der uC dann so reagiert :-) Nun funktioniert alles wie es sollte. @Peter: Mir war schon klar dass das nicht die feine Art ist einen IC zu betreiben. Wie oben beschrieben ist bisher nie diese "Arbeitsweise" des FTDIs bei meinen Platinen aufgefallen. Blöde Sache das. ...wieder was dazu gelernt. Schönen Abend noch, Björn