Hallo zusammen, habe eine mysteriöses Problem mit einem ATTiny13A in einer Routiene, die zweimal eine Spannung an ADC1 mißt. Mysteriöser Weise stimmen die Meßergebnisse unmittelbar nach dem Flashen. Wird aber einmal die Stromversorgung unterbrochen sind sie völlig anders. Wenn ich das Programm dann wieder neu aufspiele stimmts wieder bis zur nächsten Stromunterbrechung. Konkret: - Ich messen zwei mal dies Spannung an einer Diode (ca. 480mV) an ADC1. - Einmal gegen die interne Referenz und - ein zweites Mal gegen die Betriebsspannung - Die Ergebnisse werden dann an einem Pin signalisiert und auf dem Oszi dargestellt. (Wenn die Sache läuft sollen die natürlich anders weiterverarbeitet werden) - Direkt, nach dem Flashen, mit Stromversorgung über den Progger, stimmen beide Meßergebnisse und stehen stabil. - Nach dem Wiedereinschalten sind beide Ergebnisse falsch, wobei das, welches gegen die interne Referenz gemessen wurde gegen 0 fällt und das gegen VCC gemessene gegen 255 tendiert, wobei die letzten 4 Bit flattern. Woran es nicht liegen kann: - Am Stromsaparregister PRR ändere ich nichts - Das Programm greift nicht auf das SRAM oder das EEPROM zu - Mit Speicher-Oszi lies sich auch feststellen, dass der erste Programmdurchlauf nach neuverbinden der Spannungsversorgung das gleiche falsche Ergebnis liefert wie die Späteren - Die Meßergebnisse sind stabil. Wenn man die Verbindung zur Diode abzielt, flattern die Werte (erwartungsgemäß) - Prozessor läuft mit 4,8MHz. ADC läuft mit 75kHz - Ich habe zwei Exemplare ATTiny13A probiert. Beide verhalten sich gleich. Mir ist völlig schleierhaft, was das Problem ist. Brüte jetzt seit mehreren Tage und werde bald wahnsinnig. Ist vermutlich nur eine Kleinigkeit, aber ich komme nicht drauf. Danke! LG Ben
Angehängte Dateien:
-
Oszillogram.png
310 KB
Angehängte Dateien:
-
Schaltplan.png
16 KB
Die Diode wird zum Proggen natürlich abgezogen. Spannungsversorgung über Progger. Wenn der kurz abgezogen wird oder auf externes Netzteil gewechselt wird tritt der Fehler auf. bleibt der PRogger drann, ist alles ok. Oszi bleibt beim Proggen dann.
Die Diode ist aber in Durchlassrichtung geschaltet die alles über 0,7V kappt. Aber wenn die sowieso im Betrieb fehlt, kann die es eigentlich nicht ursächlich sein. Der 50k belastet zwar eine externe Quelle, aber das hängt von dem Innenwiderstand ab, ob es stört oder nicht. Nutzt du Interrupts um den ADC auszulesen oder pollst du das Register? Könnte ein Stack-Problem sein. Bin jetzt aber mit den Tinys nicht vertraut. Risc-Architekturen hatte ich mal in ner Vorlesung.
Kann es sein das in diesem Fall die Vf der Diode das Problem ist? Die schwankt sehr stark, bei 0,1µA eine Vf von 0,16V bei 2mA liegt sie bereits bei 0,7V. Besteht das Problem denn auch mit einem simplen Spannungsteiler ?
Die Diode hat mit den 50k davor etwa 480mV. Das ist der Wert, der gemessen wird - werden soll. Der Stack wird nicht benutzt. Und Interrupts auch nicht. Es wird in einer Schleife ADSC abgefragt.
Spannung an der Diode ist recht stabil (mit Multimeter nachgemessen). Spannungsteiler hatte ich die Tage schon probiert, macht aber keinen Unterschied.
Es fehlt ein 100n Keramik zwischen VCC/GND direkt am uC, der 2u2 kann das nicht richten.
Üblich ist ein 100nF Kerko zwischen Vcc und GND. Auch wenn der 2µ2 ein Kerko sein sollte: "Viel hilft viel" ist an dieser Stelle nicht zutreffend. Auch nicht sinnvoll: Elko, Folie. Es fehlt noch der Aufbau. Steckbrett? Bild?
Angehängte Dateien:
-
Aufbau.jpg
240 KB
Habe einen 47nF Kerko mit draufgesteckt. Macht einen minimalen Unterschied, aber keine Lösung. Neben dem 2µ2 sind noch weitere Kerkos im Aufbau. Der 2µ2 ist aber an nächsten dran.
Ben T. schrieb: > habe eine mysteriöses Problem mit einem ATTiny13A in einer Routiene, die > zweimal eine Spannung an ADC1 mißt. Mysteriöser Weise stimmen die > Meßergebnisse unmittelbar nach dem Flashen. Wird aber einmal die > Stromversorgung unterbrochen sind sie völlig anders. Wenn ich das > Programm dann wieder neu aufspiele stimmts wieder bis zur nächsten > Stromunterbrechung. Zeig' einfach das offensichtlich fehlerbehaftete Programm.
c-hater schrieb: > Zeig' einfach das offensichtlich fehlerbehaftete Programm. Lies einfach den Eröffnungspost noch mal ;) @TE: Ich hab nicht geschaut aber schaltest du das ADMUX um? Und hast du beachtet, dass dabei das ein und andere beachtet werden sollte? Datasheet >> ADMUX can be safely updated in the following ways: >> a. When ADATE or ADEN is cleared. >> ...
Mir fällt auf, dass der Reset-Pin offen ist. Braucht der USBASP-Clone den Reset-Eingang nicht? Wie funktioniert das?
c-hater schrieb: > Ben T. schrieb: > >> habe eine mysteriöses Problem mit einem ATTiny13A in einer Routiene, die >> zweimal eine Spannung an ADC1 mißt. Mysteriöser Weise stimmen die >> Meßergebnisse unmittelbar nach dem Flashen. Wird aber einmal die >> Stromversorgung unterbrochen sind sie völlig anders. Wenn ich das >> Programm dann wieder neu aufspiele stimmts wieder bis zur nächsten >> Stromunterbrechung. > > Zeig' einfach das offensichtlich fehlerbehaftete Programm. Du bist die Inkompetenz in Reinkultur.
c-hater meldete sich um 05:56 Also wenn das ein "schickes Wochenende" sein soll, dann möchte ich lieber nicht wissen, wie ein lausiges aussieht.
50k ist zu viel. Laut Datenblatt sollen es maximal 10k sein. Vermutlich bringt das Besserung, ist allerdings noch nicht die Vollständige Lösung des Rätsels. Ich denke, für den Rest muss man sich den Quelltext genau anschauen.
M. K. schrieb: > c-hater schrieb: >> Zeig' einfach das offensichtlich fehlerbehaftete Programm. > > Lies einfach den Eröffnungspost noch mal ;) Bladewinner schrieb: > Du bist die Inkompetenz in Reinkultur. Das kann nicht sein, sogar sein Ton war diesmal in Ordnung. Falls etwas direkt nach dem Flashen geht, später aber nicht mehr, kann es nur am Programm liegen. Und das wiederum kann auch nur mit Werten im Eeprom zusammenhängen. Der TO sagt nein, keine Werte aus Eeprom - OK. Ben T. schrieb: > - Direkt, nach dem Flashen, mit Stromversorgung über den Progger, > stimmen beide Meßergebnisse und stehen stabil. Dass es mit Stromversorgung zusammenhängt und nicht mit Ein- oder Ausschalten ist dem TO wohl gar nicht in den Sinn gekommen. Und dass der Progger die Resetleitung auf einem definiertem Pegel hält, wohl auch nicht.
Marc V. schrieb: > M. K. schrieb: >> c-hater schrieb: >>> Zeig' einfach das offensichtlich fehlerbehaftete Programm. >> >> Lies einfach den Eröffnungspost noch mal ;) > > Bladewinner schrieb: >> Du bist die Inkompetenz in Reinkultur. > > Das kann nicht sein, sogar sein Ton war diesmal in Ordnung. Jemand der nicht einmal den Eingangsbeitrag liest/versteht, nenne ich inkompetent. Basta!
Danke für Eure Beiträge heute Nacht! (Sonntags gehört dieser Teil des Vormittags bei mir noch zur Nacht -nur um Präzise zu sein) Edi R. schrieb: > Mir fällt auf, dass der Reset-Pin offen ist. Braucht der USBASP-Clone > den Reset-Eingang nicht? Wie funktioniert das? Im Schaltplan habe ich tatsächlich den ~RESET vergessen. Natürlich braucht der Progger die Reset-Leitung. Das Fehlverhalten tritt auch auf, wenn ich den Progger kurz abziehe und wieder draufstecke. Da ist kein unterschied ob ich den Progger wieder dran machen oder ein externes Netzteil. M. K. schrieb: > @TE: Ich hab nicht geschaut aber schaltest du das ADMUX um? Und hast du > beachtet, dass dabei das ein und andere beachtet werden sollte? Ich schalte ADMUX vor dem Messdurchlauf um, wärend den Messungen aber nicht. ADEN ist dann schon auf enable. Das macht wohl grundsätzlich Sinn das zu ändern.
Ben T. schrieb: > Ich schalte ADMUX vor dem Messdurchlauf um, wärend den Messungen aber > nicht. ADEN ist dann schon auf enable. Das macht wohl grundsätzlich Sinn > das zu ändern. Aha. Vor allem weil es einen Unterschied macht, ob das direkt nach dem Flashen geschieht oder erst beim erneuten einschalten. > Das Fehlverhalten tritt auch auf, wenn ich den Progger kurz abziehe und > wieder draufstecke. Da ist kein unterschied ob ich den Progger wieder > dran machen oder ein externes Netzteil. Da dein Programm so geheim ist, schlage ich vor, dass du eine LED nimmst, die beim Start genau einmal blinken soll. Könnte sein, dass die LED dann trotzdem munter blinkt...
habe jetzt noch mal folgendes Probiert: 1. Der Fehler tritt unabhängig davon auf, ob der Progger am USB abgezogen wird oder ob er am ISP-Interface getrennt wird. 2. M. K. schrieb: > schaltest du das ADMUX um? Auf M. K.s Rat hin habe ich das Programm so geändert, das ADEN (AD- enablet) wären Konfigurationsänderungen am ADC auf disable gesetzt wird. Bewirkt aber keinen Unterschied.
Marc V. schrieb: > Aha. > Vor allem weil es einen Unterschied macht, ob das direkt nach dem > Flashen geschieht oder erst beim erneuten einschalten. Das Programm läuft in einer schleife (zu Testzwecken). Ich habe mal mit dem Speicher-Oszi den ersten Durchlauf eingefangen. Der ist nicht anders als die weiteren. Marc V. schrieb: > Da dein Programm so geheim ist, schlage ich vor, dass du eine LED > nimmst, die beim Start genau einmal blinken soll. So geheim ist das Programm gar nicht. Quelltext ist angehängt (siehe oben). Eine Blink-LED wäre wohl kaum erkennbar. Das Trigger-Signal ist quasi diese LED.
Udu schrieb: > Pull up 10k an den Reseteingang Interner Pull up ist eingeschaltet. Zusätzelicher externer Pull up (15k auch ok?) macht keinen Unterschied.
Ich lese jetz schon geraume Zeit mit .... Sorry aber nachdem die Erscheinungsform des Fehlers so dubios ist würde ich - wenn ich mit der Schaltung zu tun hätte - keinen Cent darauf verwetten dass der Aufbau zuverlässig ist. Dazu gehört auch das Netzteil über das noch kein Wort verloren wurde (sehr wenig Stromaufnahme von einer Quelle die das 1000?-fache liefern könnte). Ein Geschlinge von langen Leitungen die wild voa A nach B führen und bei jedem Schritt im Experiment eine andere Lage haben lasen mir als Hochfrequenztechniker Haare und Zehen- nägel zu Berge stehen. Die Abblock-C Problematik wurde ja bereits angesprochem, ob das unzweifelhaft gelöst ist .... ich weiss es nicht. Jedenfalls kommt mit das Herangehen an die Sache von der Hardware-Seite aus sehr hemdsärmelig vor. Auch mit Steckbrettern muss man erst mal umgehen können.
Ben T. schrieb: > Eine Blink-LED wäre wohl kaum erkennbar. Das Trigger-Signal ist quasi > diese LED. Nein. Beim START LED an, 500ms warten, LED aus, weiter im Programm. LED bleibt aus. Wie willst du sonst erkennen, ob sich dein Programm dauernd resettet ?
HEUREKA! Danke, an alle, die sich mit mir das Hirn zermartert haben!!! Das Problem ist folgedes: Ich benutze das Registr r1 als "rZero", welches den Wert 00000000 enthalten soll. Ich bin davon ausgegangen, das die Register zuverlässig 00000000 haben beim Power on. Diese Annahme ist falsch! Sie haben zufällige (?) Werte. Der Progger hinterläßt sie aber schön auf 00000000. Deswegen funktioniert es nach dem Proggen. Habe jetzt r1 alias rZero sauber initialisiert und es tut was es soll. Erwartungsgemäß ein dummer Fehler. Aber jetzt kann das Projekt weitergehen. Nochmal danke an alle!
Hätte da noch einen eventuellen Fehler gefunden, kenne mich allerdings
in ASM nicht gut genug aus.
[c]
ADCUSE:
in rTmp, ADCL ; LSB einlesen
add rAdcLsb, rTmp ; und aufaddieren
in rTmp, ADCH ; MSB einlesen
adc rAdcMsb, rTmp ; und aufaddieren
[\c]
Sind rAdcLsb und rAdcMsb nicht 8 Bit Register?
Frage nur wegen der Logik, 4 mal hintereinander einen 8 Bit Wert in
einem 8 Bit Register zu addieren. Dabei sollten doch zufällige Werte bei
herauskommen.
Hans Dampf schrieb: > Sorry aber nachdem die Erscheinungsform des Fehlers so dubios > ist würde ich - wenn ich mit der Schaltung zu tun hätte - > keinen Cent darauf verwetten dass der Aufbau zuverlässig > ist. Dem ganze "Steckzeug" traue ich auch nicht weiter, als ich es werfen kann. In diesem Falle ist auf den Strippen aber keine HF-Signale. Schnell sind lediglich die Signale zum Oszi. Da gab es leichte Instabillitäten auf der Tiggerleitung. (Kein Tastkopf, keine vollständig parallele Signalfürung bis zum Messobjekt) Der zusätzliche Abblockkondensator hat bei den Messungen, die Vcc als Referenz hatten das flattern auf den letzten beiden Bits etwas reduziert.
Holger L. schrieb: > Sind rAdcLsb und rAdcMsb nicht 8 Bit Register? Das sind die beiden 8-Bit Hälften eines 16-Bit Wertes. Wie ADCL/H. Alles zusammen ist das eine saubere 16-Bit Addition.
Holger L. schrieb: > [c] > ADCUSE: > in rTmp, ADCL ; LSB einlesen > add rAdcLsb, rTmp ; und aufaddieren > in rTmp, ADCH ; MSB einlesen > adc rAdcMsb, rTmp ; und aufaddieren > [\c] > > Sind rAdcLsb und rAdcMsb nicht 8 Bit Register? > Frage nur wegen der Logik, 4 mal hintereinander einen 8 Bit Wert in > einem 8 Bit Register zu addieren. Dabei sollten doch zufällige Werte bei > herauskommen. Bei der zweiten Addition mit wird das Carry mit einaddiert (adC). Ansonsten sind in ADCH nur zwei Bits belegt. Es ist also Platz für sechs Überläufe. Was in diesem Fall auch erwünscht ist. Danke!
Hi Das ist aber nicht das vollständige Programm. Der Teil 'DBG' fehlt. MfG Spess
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.