Forum: Mikrocontroller und Digitale Elektronik Neuling! AVR kaputt? Timing fehler? Ratlos! Hilfe!


von Martin Weber (Gast)


Lesenswert?

Hallo!

Ich bin ein Neuling in der µC PRAXIS. Die Theorie ist mir ziemmlich gut
bekannt (studiere TI).

Ich habe mir einen ATMEL AT90S2313 gekauft und über ein
selbstgeschriebenes Programm per SPI programmiert. Offensichtlich
funktioniert dies auch. Ich kann Chip-Erase ausführen, den
Programmspeicher fehlerfrei schreiben und lese später auch die
geschriebenen Programmdaten korrekt aus (so wie hineingeschrieben). Bei
diesen Aktionen takte ich XTAL1 extern über die PC-Schnittstelle (ich
weis, das ist extrem langsam).

Wenn ich den AVR dann auf ein anderes Steckbord stecke und den progr.
Chip benutzen will, passiert gar nichts, wobei ich XTAL1 wieder über
ein Taktsignal vom PC-Parallelport speise. Der RESET-Pin ist fest per
2kOhm Pull-Up mit Vcc (5V) verbunden und wird versuchshalber mit einem
Taster gegen Masse geschaltet. Vcc und Masse sind natürlich auch
angeschloßen und 100nF "puffern" die Spannungsversorgung am Chip.

In der Simulation mit AVRStudio4 funktioniert das Miniprogramm, was PB0
bis PB4 endlos zählen läßt. Auf dem Steckbord bleiben alle Pins
hochohmig, als wäre ein niemals endendes Reset, was die Pins hochohmig
bleiben läßt. Nach den original Datenblättern zufolge kann man
eigentlich kein Timingfehler begehen bei jeglichem Reset, oder doch?

Ich habe alle Register (bis auf DDRB und PORTB) in ihrem Initialzustand
belassen. Ebenso habe ich nicht an den Fuse- und Lock-Bits geändert.

Ich habe einen 2. Chip gekauft, der sich jedoch genauso verhält.

Was mache ich falsch???

Im Voraus vielen Dank,
Martin!


Das ASM-Prg:


  rjmp RESET
RESET:
    ldi r16,0b00011111
  out $17,r16
  ldi r16,1
  ldi r17,0
MARK1:
  add r17,r16
  out $18,r17
  rjmp MARK1

von Ronny Schulz (Gast)


Lesenswert?

Mal davon abgeshen, dass es vielleicht sinnvoll wäre die
Definitionenusw. zu includen, damit man auch weiss was Du beschreibst
kann ich so keinen Fehler sehen:

.include "2313def.inc"

Hast Du das mit einem Oscilloskop gemessen? Mit dem Multimeter wirst Du
nichts sehen, wenn der schnell genug läuft.

P.S.: "add r17,r16" macht in deinem Fall genau das Gleiche wie "inc
r17".

von Martin Weber (Gast)


Lesenswert?

Danke für Deine Antwort!

Ein Oscilloskop hab' ich leider nicht. Mit dem Multimeter konnte ich
im Betrieb zumindest die Spannungen überprüfen, die jedoch auch
stimmen. Mir ging als Fehlerquelle noch der WATCHDOGTIMER durch den
Sinn, aber der ist ja eigentlich nach einem Reset ausgeschaltet. Ich
habe einen einfachen Logikprüfer und bei der "Geschwindigkeit", die
ich für XAL1 per Parallelport erzeuge, sollte man - denke ich -
zumindest einen kurzen "Blitz" am Prüfer sehen können.

Andere Idee/Frage:
In den original Datenblättern steht,

--> daß Port-Pins auch beim Ausbleiben des Taktsignals hochohmig
geschaltet werden - wie bei einem Reset.

Mir ist allerdings nicht klar, wie bei einem statischen µC, der
beliebig langsam getaktet werden kann (0-10MHz laut Datenblatt), ein
ausbleibendes Taktsignal erkannt werden soll. Einzige Möglichkeit wäre
ein Time-Out-Mechanismus (wie nach einem Reset), der allerding bewirken
würde, daß die Angabe 0MHz-10Mhz nicht wirklich stimmt. So ein
T.O.Mechan. würde eine untere Schranke der Frequenz festlegen -
zumindest in Bezug auf die Port-Fähigkeiten. Wenn ich das so schreibe,
könnte ich mir das allerdings glatt vorstellen. Ich werde mir mal einen
Quarz besorgen.

Für weitere Ideen oder Anregungegn wäre ich weiterhin dankbar!

Martin

von Ronny Schulz (Gast)


Lesenswert?

Darüber kann ich auch nichts sagen. Aber warum setzt Du nicht erstmal
einfach ein paar Bits und misst die nach?

    ldi r16,0b11111111 ;alle auf Bits
    out ddra,r16       ;Port A auf Ausgang
    ldi r16,0b01010101 ;abwechselnd ein und aus
    out porta,r16      ;auf Port A
stop:
    rjmp stop          ;warten bis Weltuntergang ;)

von Martin Weber (Gast)


Lesenswert?

FEHLER GEFUNDEN!

War mein Fehler!
Mein selbstgeschriebenes Programm hat 2x denselben Fehler, beim
Schreiben und beim Lesen. Dadurch kommt der Programmcode falsch in den
Chip und durch den 2. Fehler beim Lesen aber wieder korrekt herraus,
wodurch ich dachte das Programm sei fehlerfrei gespeichert worden.
PonyProg hat mich eines besseren belehrt.

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
Noch kein Account? Hier anmelden.