ATTiny2313 verhaelt sich seltsam

Hallo,

ich versuche gerade, mit einem Tiny2313 die Fuses eines anderen Tiny2313 zu programmieren. Eigentlich klappt das auch, nur das zuruecklesen der Fuses will noch nicht. Es wird zwar scheinbar der richtige Wert gelesen, aber die Abfrage, ob er richtig ist, klappt nicht:

[...] ldi temp2, 0xDF rcall write_highfuse rcall read_highfuse cpi temp, 0xDF breq prog_end ldi error, 6 rcall eep prog_end: [...] ret

eep: sbic EECR, EEPE rjmp eep cbi EECR, EEPM0 cbi EECR, EEPM1 out EEAR, error out EEDR, temp sbi EECR, EEMPE sbi EECR, EEPE ret

Seltsamerweise steht nach dem Ausfuehren des Programms immer die 0xDF im EEPROM an Adresse 6, obwohl dann ja eigentlich das Laden der Adresse nach "error" und das Aufrufen der EEPROM-Schreibfunktion uebersprungen werden sollte?! Error ist danach auch wirklich 6 (ich habe da eine LED dran, die nach dem Programmieren so oft blinkt, wie es in "error" steht). Das seltsame ist, dass ich das gleiche fuer die Low- und Extended-Fuses auch noch im Programm drin habe, und da funktioniert es tadellos (0x62 -> Low, 0x01 -> Ext).

Hat irgendjemand eine Idee, was da schief laufen koennte? Kann das daran liegen, dass ich das alte AVR Studio 3.56 verwende (das den Tiny2313 eigentlich nicht unterstuetzt - das richtige Include-File habe ich aber natuerlich angegeben)? Ich bim im Moment echt der Verzweiflung nahe :-(

Gruss, Arne

Reply to
Arne Rossius
Loading thread data ...

Nein, der Fehler liegt wie in 99.99999% der Fälle beim Programmierer selbst, und nicht an den Tools oder an den Libs oder an fremden Code.

Dein Fehler vermutlich: Einmal verwendest Du "temp2", das nächstemal nur "temp" (ohne "2""...

Reply to
Michael Roth

Wenn du damit das temp2 vor dem write und das temp nach dem read meinst: das ist beabsichtigt. Meine Frage zielte aber eher in die Richtung, wie es passieren kann, dass ein 0xDF im EEPROM landet (das EEPROM war vorher leer, ich habe es sogar testweise wieder geloescht und das Programm nochmals laufen lassen, und wieder stand 0xDF an Adresse 0x06).

Gruss, Arne

Reply to
Arne Rossius

Arne Rossius schrieb:

Läufst Du evtl. aufgrund eines fehlerhaften Stacks oder eines anderen Bugs später im Programmablauf in die Routine "eep" hinein?

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
 Click to see the full signature
Reply to
Christian Zietz

Probieren geht ja bekanntlich ueber studieren: wenn ich das "rcall eep" durch ein "nop" ersetze (was ja am Programmablauf anderswo nichts veraendern sollte), wird nichts ins EEPROM geschrieben. Der rcall wird also auf jeden Fall ausgefuehrt. Ich habe aber auch die Erkenntnis gemacht, dass die Programmteile fuer die Low- und Ext-Fuses, von denen ich geschrieben hatte, dass es dort funktionieren wuerde, leider doch genau den gleiche Fehler machen. Es sieht also ganz danach aus, als ob das "cpi temp, 0xDF" oder das "breq prog_end" entweder nicht ausgefuehrt wird oder nicht funktioniert, warum auch immer. Ich werde gleich noch mal einen anderen Assembler probieren, aber ich glaube kaum, dass sich da was aendert.

Gruss, Arne

Reply to
Arne Rossius

Hi Arne, ich hatte gerade was ähnlich unerklärbares. (u.a. unerklärbare Werte im EEprom, es fehlten z.B. die unteren Nibbles). Code tausend mal geprüft, nix... Den Stack hatte ich auch geprüft, aber der war es auch nicht. Lösung: ich hatte das *.hex und auch ein *.eep file über PonyProg in einem Script (... WRITE-ALL) geschickt. Nach dem Ändern des Scripts war alles OK.

Reply to
Achim Metzen

Daran liegt es ganz sicher nicht, weil ich nach einer Aenderung im Programm auch andere Werte im EEPROM habe. Trotzdem danke fuer den Tipp.

Gruss, Arne

Reply to
Arne Rossius

[...]
[...]

Ich habe gerade noch ein wenig herumprobiert, und nachdem ich das Programm einmal mit einem anderen Assembler assembliert hatte, war der Fehler weg, und kam auch nicht wieder, als ich das Hexfile wieder mit AVR-Studio erzeugt habe. Sehr seltsam.

Allerdings gibt es noch ein anderes Problem: wenn ich zuerst die Low- und Extended-Fuses *lese* und dann die High-Fuses *schreibe* und wieder

*lese*, dann klappt alles. Wenn ich aber zuerst die High-Fuses schreibe und wieder lese oder zuerst die Low- und/oder Extended-Fuses schreibe und wieder lese, dann klappt es nicht (im zweiten Fall wird (fast?) immer 0xFF gelesen, im ersten hatte ich eben 0xD5 statt dem gewuenschten 0xDF im EEPROM stehen). Bei der Signatur hatte ich schon ein aehnliches Problem, wenn ich den Befehl zum Lesen der Signatur-Bytes einmal lade und dann die 3 Adressen nacheinander lese, ohne den Befehl neu zu laden, klappt es. Wenn ich aber den Befehl jedes Mal neu lade, wird das dritte(!) Signaturbyte nicht/falsch ausgelesen.

Wenn keinem etwas dazu einfaellt, woran das liegen koennte (es kann durchaus auch an der Hardware liegen, obwohl ich das eher bezweifle), dann lade ich morgen mal den kompletten Quellcode irgendwo hoch.

Gruss und danke schonmal, Arne

Reply to
Arne Rossius

versuch es mal mit einem "Delay" zwischen den Lese- und Schreibzyklen...bzw. lass "Ihn" kurz was anderes machen z.B. Stack "push -> pop"

(nur so eine Idee, bin Anfänger)

Reply to
Stefan "Hänky"

Wie sieht es mit der Stromversorgung aus? Ist diese Sauber -> Akku ?

-> Spannungsschwankungen beim Schreiben -> OSZI messen ?

-> EMV? -> Layout

-> Quarze ? -> Entkoppelt mit 2 x C ? -> Takt zu hoch ?

Reply to
Stefan "Hänky"

Laut Datenblatt braucht man da eigentlich keine, ich glaube, die laengste Zeit, die eingehalten werden muss ist irgendwas bei 250ns. Da der AVR mit 512kHz laeuft, ist das auch gar kein Problem ;-)

Uebrigens: fuer "was anderes machen" gibt es nop, da braucht man kein push/pop oder was auch immer zu machen. Davon habe ich auch einige eingebaut, ich lade den Code gleich mal hoch.

Gruss, Arne

Reply to
Arne Rossius

Arne Rossius wrote: Arne Rossius wrote in de.sci.electronics:

Ich habe jetzt mal den Quellcode und den Schaltplan hier hochgeladenL

formatting link
formatting link

Wenn irgendwas ueberfluessig/umstaendlich/seltsam sein sollte, bitte Bescheid sagen!

Hat eigentlich jemand hier schon mal eine funktionierende Software zur HV-Programmierung der Tiny2313 geschrieben (auf welcher Plattform auch immer) und koennte mir davon evtl. die relevanten Teile des Quellcodes zukommen kassen?

Gruss, Arne

Reply to
Arne Rossius

Hi Arne,

Arne Rossius schrieb:

Die 10k Widerst=E4nde in Serie zur Basis des Vcc schaltenden Transistors ist viel zu hoch, nimm 1k. Und schon wird die Spannung nicht mehr zusammenbrechen.

HTH Wolfgang

--=20 From-address is Spam trap Use: wolfgang (dot) mahringer (at) sbg (dot) at

Reply to
Wolfgang Mahringer

Hi,

Dem rechten Controller fehlt das C an der Versorgung, selbst wenn er mal für ne µs 200mA brauchen sollte, wo soll der Strom herkommen? Da die Basiswiderstände der Transistoren maximal 0,5A Basistrom zulassen, bekommst Du gerade mal 100-200mA durch, das ist aber schon grenzwertig. Und weil das C fehlt, wird das ganze noch viel kritischer.

Geb dem µC 100nF zwischen Pin 10 und 20.

Michael

Reply to
Michael Rübig

Hi, mal meine Schreibfehler korrigieren:

^mA

Gib

Außerdem solltest Du die Basiswiderstände verkleinern. Wenn die Schaltzeit der Transistoren kritisch ist, helfen vielleicht kleine Cs über den Basisvorwiderständen, so 1nF oder so.

Ohne diese Cs musst Du mit Abschaltzeiten der Transistoren von 5µs und mehr rechnen. Niedrigere Basiswiderstände helfen da auch.

Du kannst ja mal mit dem Scope mit den beiden Kanälen den Schaltvorgang an Basis und Kollektor ausmessen und Dir die Verzögerung anschauen. Michael

Reply to
Michael Rübig

Ich weiss zwar nicht, warum das zu viel sein soll, aber ich habe es gerade mal mit 1k ausprobiert - leider keine Aenderung.

Gruss, Arne

Reply to
Arne Rossius

Oh, den habe ich im Schaltplan vergessen, in der Schaltung ist er da.

Warum das? Braucht der Controller beim Programmieren so viel Strom?

Was mich aber vor allem verwirrt ist, dass die Spannung erst ab dem 2. Programmiervorgang zusammenbricht, beim ersten mal nach dem Einschalten bleibt sie konstant bei 5V (aber die Fehler beim Programmieren sind die gleichen).

Gruss, Arne

Reply to
Arne Rossius

Laut Datenblatt muss die Spannung IIRC binnen 20us auf 5V sein, 5us waeren also noch voellig im Rahmen.

Siehe mein anderes Posting, leider nicht.

Wie soll das gehen? Das geht so schnell, da sehe ich auf dem Oszi vermutlich gar keinen Unterschied.

Gruss, Arne

Reply to
Arne Rossius

Hi,

es geht eh ums Abschalten. Ich weiß nicht, wie kritisch das beim Programmieren ist.

Ohne Speicherscope musst Du im linken Controller ne Testroutine einbauen, die den Port mehr als 10mal pro Sekunde umschaltet. Dann kannst Du Dir das auch mit dem Analog-Scope anschauen.

5µS sind für ein durchschnittliches Scope aber in der Regel noch kein Problem, triggere mit dem einen Kanal auf die fallende Flanke an der Basis und schau Dir mit dem zweiten Kanal das Signal am Kollektor an.

Michael

Reply to
Michael Rübig

Hi, als Anmerkung: Ich habe keine Ahnung, wie das Programmieren dieser Controller mit Deiner Schaltung funktioniert, ich kann Dir nur bei den rein elektrischen Problemen helfen.

Das ist ja schonmal was.

dauernd sicher nicht, aber kurzfristig vielleicht schon. Der

100nF-Kondensator verliert bei 100mA Strom 1V/µs. Wenn Dein Transistor also nur 100mA liefern kann (wegen Basisvorwiderstand), der Controller aber 1µs lang 200mA benötigt, bricht die Spannung in dieser Zeit um 1V zusammen. Darüber solltest Du Dir im Klaren sein. Also auf jeden Fall mal Basisvorwiderstände verkleiner, schaden tuts bestimmt nicht.

Vielleicht gibts da irgendwie Probleme, dass ein Port des einen Controllers nach oben zieht, der des anderen aber nach unten. Die Ports sind ja direkt miteinander verbunden. Aber wie gesagt, ich weiß nicht, was da beim Programmieren so alles abläuft.

Michael

Reply to
Michael Rübig

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.