Forum: Mikrocontroller und Digitale Elektronik ATmega644 tot?


von Markus M. (adrock)


Lesenswert?

Hi,

wollte heute meinen neuen ATmega644 ausprobieren, aber irgendwie scheint 
er tot zu sein :-(

- ISP Programmierung geht
- HV/parallel Programmierung geht
- JTAG geht nicht

Wenn ich das Programm geflasht habe, macht er einfach... nichts. Die 
Portausgänge sind LOW (müssten doch eigentlich high sein?) und er 
scheint mein Programm überhaupt nicht auszuführen.

Da ich schon an mir selbst zweifelte, habe ich ihn auch nochmal ins 
STK500 eingesetzt, aber da tut er auch einfach nichts. Programmieren + 
Verify ist OK, die Fuses kann ich auch lesen und schreiben, aber die CPU 
läuft einfach nicht los wie es scheint... die Taktgenerierung hatte ich 
sowohl mit einem externen Oszillator als auch mit dem RC-Oszillator 
ausprobiert.

Noch irgendeine Idee was falsch sein kann, oder ist er wirklich tot?

Ciao...
Markus

von (prx) A. K. (prx)


Lesenswert?

RC-Oszillator oder interner Oszillator? Es gibt auch einen externen 
RC-Osz.

von (prx) A. K. (prx)


Lesenswert?

Markus M. schrieb:

> Wenn ich das Programm geflasht habe, macht er einfach... nichts. Die
> Portausgänge sind LOW (müssten doch eigentlich high sein?)

Sie dürften offen sein, also low wenn gegen GND und high wenn gegen VCC 
gemessen wird.

von spess53 (Gast)


Lesenswert?

Hi

>Noch irgendeine Idee was falsch sein kann, oder ist er wirklich tot?

Woran machst du das genau fest? Led-Blinken an PortC oder an etwas etwas 
koplexeren.

MfG Spess

von Markus M. (adrock)


Lesenswert?

A. K. schrieb:
> RC-Oszillator oder interner Oszillator? Es gibt auch einen externen
> RC-Osz.

Ich habe es sowohl mit dem internen RC-Oszillator als auch mit einem 
externen "Full Swing Crystal Oscillator" mit entsprechender Beschaltung 
ausprobiert. Der interne RC-Osz. sollte doch aber auf jeden Fall 
funktionieren?

Ciao...
Markus

von Markus M. (adrock)


Lesenswert?

spess53 schrieb:
> Hi
>
>>Noch irgendeine Idee was falsch sein kann, oder ist er wirklich tot?
>
> Woran machst du das genau fest? Led-Blinken an PortC oder an etwas etwas
> koplexeren.

Nein, ich habe es im STK-500 mit einem wirklichen einfachen Programm 
ausprobiert:

.include "m644Pdef.inc"

.org $0000
  rjmp  Main

.org INT_VECTORS_SIZE

Main:
  ldi    r16, $ff
  ldi    r17, $00
  out    DDRA, r16

loop2:
  out    PORTA, r16
  out    PORTA, r17
  rjmp  loop2

Sollte einfach ein Rechtecksignal auf allen Pins am Port A ausgeben, 
oder?

Ich hatte es auch zwischenzeitlich mit einem Programm ausprobiert, 
welches auf Port A die Taster ausliest und ihren Status auf Port B (LEDs 
angeschlossen) ausgibt... null Reaktion.

Ciao...
Markus

von Gast (Gast)


Lesenswert?

Wenn du die Device-ID auslesen kannst, sollte der Prozessor 
funktionieren.

von Markus M. (adrock)


Lesenswert?

...die Device ID kann ich auslesen. Ich würde ihn ja gerne mal mit 
meinem Dragon über JTAG debuggen, aber ich bekomme das JTAG nicht zum 
laufen.

Bekomme das JTAG auch mit einem ATmega162 nicht hin, ist da noch etwas 
zu beachten ausser die Leitungen entsprechend der Beschreibung zu 
verbinden?

Ciao...
Markus

von Markus M. (adrock)


Lesenswert?

Hi,

also das Phänomen mit dem Programm an sich ist geklärt :-) Das dumme AVR 
Studio hat im Dialog für die Programmierung bei "Input Hex File" immer 
noch die .hex Datei von einem meiner letzten Projekte für einen 
ATmega168 genommen, ist mir aufgrund des langen Pfadnamens nicht 
aufgefallen, da nur der Anfang des Pfades angezeigt wird... Grrr...

Ist das ein normales Verhalten? muss ich bei jedem Wechsel zu einem 
anderen Projekt in diesem Dialg den Dateinamen manuell anpassen?

Jetzt wüsste ich nur noch ganz gerne, warum das mit dem JTAG nicht 
funktioniert. Die Fuses dafür sind enabled, aber ich bekomme es weder 
mit dem ATmega162 noch mit dem ATmega644 zum funktionieren.

Ciao...
Markus

von spess53 (Gast)


Lesenswert?

Hi

>also das Phänomen mit dem Programm an sich ist geklärt :-) Das dumme AVR
>Studio hat im Dialog für die Programmierung bei "Input Hex File" immer
>noch die .hex Datei von einem meiner letzten Projekte für einen
>ATmega168 genommen, ist mir aufgrund des langen Pfadnamens nicht
>aufgefallen, da nur der Anfang des Pfades angezeigt wird... Grrr...

Dummes AVR-Sudio? Was hat ein Programmiertool mir deinem Projekt zu tun?

>Ist das ein normales Verhalten? muss ich bei jedem Wechsel zu einem
>anderen Projekt in diesem Dialg den Dateinamen manuell anpassen?

Ja. Ausser du befindest im Debug-mode. Dann lässt sich im STK500-Dialog 
'Use current Simulator/Emulator Flash Memory' auswählen.

MfG Spess

von Ben _. (burning_silicon)


Lesenswert?

das programm ist aber auch müll. den rechteck messen könnte durch die 
kapazität der leitung zum oszi bereits probleme geben. du hast da 
keinerlei verzögerung drin, bei 10MHz CPU takt hast du ein 
rechtecksignal mit 3,3MHz und 33% duty am port. klasse! ist der port 
überhaupt so schnell?

von Markus M. (adrock)


Lesenswert?

spess53 schrieb:
> Hi
>
>>also das Phänomen mit dem Programm an sich ist geklärt :-) Das dumme AVR
>>Studio hat im Dialog für die Programmierung bei "Input Hex File" immer
>>noch die .hex Datei von einem meiner letzten Projekte für einen
>>ATmega168 genommen, ist mir aufgrund des langen Pfadnamens nicht
>>aufgefallen, da nur der Anfang des Pfades angezeigt wird... Grrr...
>
> Dummes AVR-Sudio? Was hat ein Programmiertool mir deinem Projekt zu tun?

???

Naja, ich finde es schon "dumm", wenn ich in einem Projekt arbeite, 
welches eine .hex Datei erzeugt, und ich, wenn ich aus diesem Projekt 
das Programmiertool aufrufe, den Dateinamen der .hex Datei nochmal extra 
angeben muss, weil ansonsten die falsche vom Projekt verwendet wird, 
welches ich vorher bearbeitet/programmiert habe.

Ich würde erwarten, dass der Dialog zum Programmieren des AVRs den 
korrekten Namen der .hex Datei (zumindest als Vorgabe) welche zum 
aktuellen Projekt gehört verwendet.

Ciao...
Markus

von Markus M. (adrock)


Lesenswert?

Ben _ schrieb:
> das programm ist aber auch müll. den rechteck messen könnte durch die

Es war das kürzestmögliche Programm um mit minimalen Mitteln eine 
Reaktion am Portausgang zu erzeugen. Es entspricht nicht dem, was ich 
eigentlich programmieren möchte.

> kapazität der leitung zum oszi bereits probleme geben. du hast da
> keinerlei verzögerung drin, bei 10MHz CPU takt hast du ein
> rechtecksignal mit 3,3MHz und 33% duty am port. klasse! ist der port
> überhaupt so schnell?

Das geht schon, mit dem eingebauten RC-Oszi. und CKDIV8 gesetzt läuft 
der AVR mit 1 MHz, da sollte das 50MHz Oszi dann den 166KHz Takt 
darstellen können.

Dieses "Problem" ist ja nun auch gelöst. Wegen dem JTAG mache ich mal 
einen neuen Thread auf, das ist hier OT.

Ciao...
Markus

von M. M. (miszou)


Lesenswert?

Hi

warum soll das Programm Müll sein. 1 Takt lang PINS von PORTA high und 3 
Takte Low. Und wenn auch wenn ich mich bei den Takten verrechnet habe 
auch egal. Zumindest kurze Zeit High etwas länger Low, funzt einwandfrei 
und läsßt sich mit dem Oszi auch messen. Die Kapazitäten würden dann 
stören wenn er mit einem 1 zu 1 Tastkopf die Schwingung vom Quarz messen 
wollte.

Und die PINs sind auch so schnell.

@ hex Datei auswählen.
Finde ich auch blöd ;-)

Gruß MISZOU

von Ben _. (burning_silicon)


Lesenswert?

> @ hex Datei auswählen.
hatte ich auf jeden fall weniger probleme mit als mit dem programm ^^

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.