Guten Abend werte uC-Gemeinde!
Ich habe seit gestern ein Problem mit einem ATmega128RFA1 mit externem
32 kHz-Quarz.
Mein Plan war es bei einem Überlauf des Timer2 (im asynchronen Modus)
eine angeschlossene LED ab- bzw. wieder abzuschalten. Dazu habe ich den
größtmöglichen Taktteiler (1024) gewählt, was bei 8-Bit-zähler und
32,768 kHz-Quarz eine Interruptperiode von 8 s geben sollte.
Das Problem ist, dass der AVR nach 8 Sekunden zurückgesetzt wird
(Watchdog ist deaktiviert).
Ich weiß nicht mehr weiter, deswegen hier dieser Eintrag und nachfolgend
mein Quellcode.
Vielen Dank im Voraus für Eure Bemühungen!
1
#include<avr/io.h> // include io definitions
2
#include<avr/interrupt.h> // include interrupt definitions
3
#include<util/delay.h> // delay functions
4
#include<avr/sleep.h> // provides sleep instruction etc.
LED_PORT|=ALL_LEDS;// Turn off LEDs for measurement
Wenn ich den Interrupt maskiere, kommt es nicht zum Reset.
In der Assemblerdatei sind die Einsprungadressen auch korrekt. Falls da
Interesse besteht, einfach melden.
Danke!
Die Idee war, dass die Verkürzung hilfreich sein könnte und auf das
Problem fokussiert.
Vielen Dank für die Hilfe!
Daniel
So, damit ich ausreichen Text habe, hier noch ein paar Zeilen unsinniges
BLABLA :(
So, Code ist da, jetzt fehlt nur noch die Fehlerbeschreibung ;D
Also, der uC startet und gibt das Muster aus, danach verweilt er in der
while-Schleife (was ein Wortspiel xD), und sollte alle 8 s seine LED3
toggeln.
Was funktioniert jetzt genau nicht an dem Programm, bzw. wo hängt er?
Flo schrieb:> So, Code ist da, jetzt fehlt nur noch die Fehlerbeschreibung ;D>> Also, der uC startet und gibt das Muster aus, danach verweilt er in der> while-Schleife (was ein Wortspiel xD), und sollte alle 8 s seine LED3> toggeln.> Was funktioniert jetzt genau nicht an dem Programm, bzw. wo hängt er?
Exakt. Aber nach 8 s erfolgt ein Reset und er präsentiert wieder das
"Startmuster".
@Holger: Dass das auskommentiert ist, ist schon in Ordnung. Einen
Kurzschluss kann ich bei der Beschaltung nicht erzeugen (LED hängt mit
Vorwiderstand von Vdd kommend am PIN). Um die jetzt zum Leuchten zu
bringen, muss ich den als Ausgang definierten PIN gegen Masse ziehen
(clear), zum Abschalten intern gegen Vdd (set).
Vielen Dank für die Hilfe!
Daniel
Haste grad das Datenblatt von dem Controller da? Find grad auf die
schnelle nur die Preliminary.
Ganz sicher, dass die Einsprungstelle stimmt? Weil sonst könnt ich mir
grad nichts denken, was den Controller wieder resettet.
Im Augenblick gibt es nur das Preliminary, die nächste Revision ist noch
im "Legal Review".
In der "iomega128rfa1.h" (avr/...) ist der Vektor aber identisch zu dem
im Datenblatt angegebenen (15). Eben deswegen kann ich es mir auch nicht
erklären.
Vielleicht fällt ja jemandem noch etwas ein.
Daniel
Die ISR hat den richtigen Namen, und der Vector wird richtig
eingetragen, aber dennoch gibt es beim Interrupt einen Soft-Reset. Dann
lautet die nächste Frage: wie compilierst du und was (welche Datei)
programmierst du in den Chip?
Ich kompiliere mit der WinAVR-20100110 beigefügten Version von avr-gcc
(4.3.3) und flashe mit der erzeugten HEX-Datei. Ich habe das Ganze aber
auch schon mit AVRStudio mit gleichem Ergebnis nachvollzogen. (Neues
Projekt -> nur die zwei Quelltextdateien eingefügt -> Plattform
eingestellt -> Build -> Flash von Datei)
Ich verstehe einfach nicht was da schief läuft. Anbei das verwendete
Makefile.
Danke für Eure Bemühungen!
Daniel
Daniel Pfefferkorn schrieb:> Ich kompiliere mit der WinAVR-20100110 beigefügten Version von avr-gcc> (4.3.3)
Das mag ja sein, gelegentlich werden aber Dateien aus einem andeen
Ordner als vermutet vearbeitet. Das passiert besonders, wenn man
Projekte kopiert hat. Schau Dir mal die Path-Angaben in der
Projekt-Datei an.
> und flashe mit der erzeugten HEX-Datei.
Das mag auch sein, ist jedoch gelegentlich auch ein Irrtum. Also lieber
nochmal genau hinsehen.
> Ich habe das Ganze aber> auch schon mit AVRStudio mit gleichem Ergebnis nachvollzogen. (Neues> Projekt -> nur die zwei Quelltextdateien eingefügt -> Plattform> eingestellt -> Build -> Flash von Datei)>> Ich verstehe einfach nicht was da schief läuft. Anbei das verwendete> Makefile.>> Danke für Eure Bemühungen!> Daniel
Ich kann wenn ich den Pre-Scaler anders wähle den|das Reset auch
schneller herbeiführen, d.h. es wird schon die richtige Datei geflasht.
Ich verwende dazu einen JTAGICE mkII mit neuester Firmware.
Das andere Dateien verarbeitet werden, kann eigentlich auch nicht sein,
weil ich (wie ich auch geschrieben habe) das Projekt nicht kopiere,
sondern gänzlich neu anlege und nur die beiden Quelltextdateien
hinzufüge. Nicht mehr, nicht weniger.
Danke für Eure Ideen!
Hallo,
ich programmier eigentlich nur in Assembler, könnt also grad Käse
erzählen. Mir is aufgefallen, dass nirgends der Prozessor-Typ angegeben
wird. Das mach ich immer gleich als erstes. Falls er für den falschen µC
compiliert, könnten die ISR-Adressen anders sein und der Rest
funktioniert nur zufällig. Aber dann könntest wahrscheinlich gar nicht
flashen. Nur so ne Idee :)
Gruß, Alex
Ist eine verdammt gute Idee. Leider steht im Makefile in Zeile 3
1
MCU=atmega128rfa1
Ich habe festgestellt, dass es sich nicht nur auf den Overflow-Interrupt
bezieht, sondern auch auf die Compare-Match-Interrupts.
Wenn ich z.B. den intern getakteten Timer4 nutze, funktioniert alles wie
erwartet. Aber ich brauche Timer2, weil ich ihn durch einen externen 32
kHz-Quarz takten lassen will/muss.
EDIT:
Wenn ich den Timer2 mit dem internen Systemtakt laufen lasse, wird die
ISR wie erwartet ausgeführt und es kommt nicht zum "Reset des Todes".
Es muss also etwas mit der "externen Clock" zu tun haben.
Hat da jemand eine Idee?
Viele Grüße,
Daniel
Daniel Pfefferkorn schrieb:> Wenn ich den Timer2 mit dem internen Systemtakt laufen lasse, wird die> ISR wie erwartet ausgeführt und es kommt nicht zum "Reset des Todes".> Es muss also etwas mit der "externen Clock" zu tun haben.>> Hat da jemand eine Idee?
Den internen Takt wollte ich dir auch vorschlagen, aber das hast du
selbst schon probiert.
Bleibt mir nur noch: Abspecken!
Alles rauswerfen, was nicht wirklich unmittelbar mit dem Timer zu tun
hat.
Zb. Watchdog, das ganze Power Reduction Gedöns, in einem deiner
Kommentare hab ich auch was von irgendwelchen UART Einstellungen
gelesen, etc.
Also erstmal ein UPDATE:
Es läuft jetzt auch mit externem Timer-Takt! YEAH!
Interessanterweise konnte ich noch keinen entscheidenden Unterschied im
Quellcode entdecken, aber ich mache gerade ein "diff" mit einer älteren
Version (Versionierungssysteme sind Dein Freund!).
Es freut mich schon mal sehr.
Werner B. schrieb:> A) Sind die Vektoren evtl. auf die Bootsection umgestellt?
Ich habe die Lösung gefunden!
Es ist ein Einzeiler und sowohl Werner B. als auch Karl heinz Buchegger
hatten "den richtigen Riecher".
1
PRR2|=(0xFF);// disables SRAM blocks
Ich habe einfach alle SRAM-Blöcke abgeschaltet. Keine so gute Idee. :D
Das war/ist sozusagen ein Überbleibsel aus den Energieaufnahmetests.
Wenn ich alle bis auf SRAM-Block0 geht es noch.
> B) In den "ISR(BADISR_vect)" am Ende ein "while(1);" Sonst sieht man> doch nichts.
Volle Zustimmung!
Karl heinz Buchegger schrieb:> Wenn es sich nicht in 10 oder weniger Worten beschreiben lässt, dann> lass es. Aber: Was macht das eigentlich?>>>
1
>>PRR2|=(0xFF);// disables SRAM blocks
2
>>
>>>> Ich habe einfach alle SRAM-Blöcke abgeschaltet.>> Lass mich raten: Du hattest dann kein SRAM für den Stack mehr?
Ganz genau diese Zeile war das Problem! Mit aktiviertem SRAM-Block0
läuft's wie geschmiert. :D
Daniel