Hallo Ich habe die Frage schon mal gepostet, allerdings mit einem unglücklich gewählten Betreff. Die Frage habe ich auch im avrfreaks.net gestellt, allerdings keine Erklärung bekommen. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=772181&sid=00f66223b798914a7031062d6b795f78#772181 In einem anderen Post wird ebenfalls von einem Stromanstieg in einer stark gestörten Umgebung geschrieben. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=100805 Es liegt vielleicht auch an meinen Englisch-Kenntnissen die zwar reichen um ein Datenblatt zu lesen aber nicht für eine ausführliche Kommunikation. Ich habe mehrere Schaltungen in Betrieb (www.schorsch.at Transistorteseter, Quarztester) mit einem ATmega8L-PU oder ATmega8-16-PU. Diese funktionieren einwandfrei. Ersetzte ich nun diese Kontroller durch einen ATmega8A-PU, so steigt der Stromverbrauch der Schaltung nach einem manuellen Reset um mehr als 100mA an und geht erst nach einem Power-Down wieder auf normalen Wert zurück. Ich habe das dann auch auf einem Steckbrett probiert, nur mit Grundbeschaltung. Das Ergebnis ist das gleiche. Nach vielen Tests bin ich auf folgendes Ergebnis gekommen. Der Fehler tritt nachvollziehbar auf: Spannung höher als 4,9V Kondensator 100n von Reset nach GND Ein nicht prellfreier Resettaster Es ist egal ob der Kontroller neu oder programmiert ist. Ich habe mehr als 100 Stück liegen und zum testen willkürlich aus den Stangen herausgenommen. Hat vielleicht jemand einen Atmega8A und könnte das ebenfalls testen. Reset am besten mit einem Stück Draht machen, das prellt sicher.
Hi Hubert. Mangels Atmega8A kann ich dir leider keine Testdaten liefern. Aber eine Frage: Ist der prellende Resettaster und manueller Reset nötig oder tritt der hohe Strombedarf auch auf, wenn du mit dem ISP-Programmer Resets machst? Im anderen Posting hattest du ja geschrieben, dass der hohe Strombedarf nicht auftritt, wenn du den 100nF am Resetanschluss weg lässt. Vielleicht wäre das (oder andere Kapazitäten) ein Workaround.
Hallo Stefan Das Prellen ist anscheinend notwendig. Mit dem ISP-Programmer tritt das nicht auf, werde ich aber noch mal explizit testen. Es ist richtig, wenn ich den 100n weglasse tritt der Fehler nicht auf. Mit einem "prellfreien" Taster aber auch nicht. Ansonsten lässt sich der Fehler problemlos reproduzieren. Der 10k von VCC nach Reset hat keine Auswirkung, egal ob vorhanden oder nicht. Mit dem Oszi habe ich mir das mal angesehen. Ohne Kondensator sind viele, sehr kurze Spikes zu sehen. Mit Kondensator sind es nur wenige aber deutlich länger Spikes. In dem von mir angeführten posting wird ja auch von einer stark gestörten Umgebung geschrieben.
ISP noch einmal ausführlich getestet, damit ist der Fehler nicht zu reproduzieren. Ich weiß nicht was ich da noch machen soll, mein Vertrauen in diese Controller ist nicht mehr sehr groß, allerdings kann ich auch nicht mehr als 100 Stück in die Mülltonne schieben.
Das Problem scheint ja sogar bei nem unprogrammierten MC aufzutreten. Schreib dochmal an Atmel und telefonier mit Ineltek oder MSC. Hat zwar nichts mit Deinem Problem zu tun: Vielleicht kannst Du mal nen ATmega8A nehmen und zwischen VCC und AVCC messen, ob der Kurzschluß immer noch da ist. Ich finde es höchst befremdlich, daß Atmel das hartnäckig ignoriert und nicht dokumentiert, genauso wie den kritischen I2C-Multimaster Bug. Wenn man nicht AVRfreaks mitlesen würden, wäre man aufgeschmissen. Peter
Ich würde in diese Richtung suchen: Hochlaufzeit zu kurz, da die reset-Spannung zu langsam ansteigt, und das Prellen mehrere Resets zusammenstottert. Mach einmal die Hochlaufzeit (start-up-time) größer. Gerade für die Schwierigkeiten beim Hochlaufen ist die Wartezeit von 64ms bei der längsten start-up-time gedacht.
@ Peter Dannegger Die Verbindung zwischen VCC und AVCC besteht nicht mehr. Mit einem normalen Multimeter gemessen im MOhm Bereich. @Peter R Mit der Hochlaufzeit kann es nichts zu tun haben. Bei internem 1MHz-Oszillator ist ohnehin die längste Zeit eingestellt. Ein Controller mit Quarz zeigt in der obigen Schaltung das gleiche Verhalten. Hier kann der Oszillator gar nicht laufen. Das von mir aufgezeigte Problem wird wohl als Eigenfehler abgetan, wie auf der AVRfreaks Seite, die ich allerdings seit heute Mittag nicht mehr aufmachen kann.
Noch mal zum aufwärmen. Hat vielleicht jemand einen Mega8A-PU liegen und könnte mein Problem nachstellen.
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.