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
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.
Ü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?
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.>> ...
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.
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!
Oszillogram.png
(310 KB)
