Problem externer Bus bei ATmega64

[Joachim (Gast)]

Hallo,

Ich setze das erste Mal den externen Bus des ATmega64 ein und habe 
massive Probleme damit.
Laut ATMEL muss man nur das Bit SRE in MCUCR auf 1 setzen und einen 
Schreib/Lesezugriff auf Adressen höher als 0x1100 machen.
Das Problem: Zwar messe ich an ALE einen Takt, nicht aber an RD oder WR.
Die bleiben ständig auf H.
Ich probiere seit Tagen, ein Signal aus RD oder WR herauszubekommen - 
ohne Erfolg. Habe alle möglichen Programmvarianten versucht (C, 
Assembler) und in einer Schleife alle Adressen von 0x1100 bis 0xFFFF 
angesprochen.
Die Signale bleiben tot.
Wenn ich "mit Gewalt" R30 und R31 z.B. mit 0xFF beschreibe und z.B. R24 
mit 0xA5, und dann den Befehl ST Z, R24 ausführe, dann müsste doch ein 
Schreibvorgang an Adresse 0xFFFF, Data 0xA5 ausgelöst werden. Versteh 
ich nicht..
Zuletzt habe ich noch gemerkt, dass alle neuen Bauteine defaultmäßig die 
Fuse "103 Kompatibilität" gesetzt haben.
Diese gelöscht brachte auch keinen Erfolg. Nun war auch das Signal ALE 
tot.
Ich habe im Internet nach Hinweisen oder Problemen durchsucht.
Aber scheinbar bin ich der einzige mit diesem Problem.
Gibt es jemanden, der mit dem externen Bus arbeitet und wenn, gibt es da 
einen Punkt, den ich übersehen habe?
Ich weiss nicht mehr weiter.

Danke.

Joachim

[Michael U. (Gast)]

Hallo,

normalerweise nur SRE in MCUCR setzen, um das Interface einzuschalten.
Ansonsten eben 74HC(T)373 und passenden Ram ran und fertig.
Hatte ich noch nie Probleme mit, daß da was nicht ging, auch nicht mit 
LCD-Modul als Memory-Mapped usw.

Allerdings habe ich da noch nie gemessen, ging eben. ;)

Gruß aus Berlin

[Joachim (Gast)]

Ist bei Dir die Fuse "103" 0 oder 1?
Ich habe nun einen neuen Test gemacht, und PORTG als normalen Port 
angesprochen. Alle Ports wechseln zwischen 0 und 1. Nur Port G bleibt 
davon unberührt (SRE = 0).
Ich dreh langsam echt durch.

Joachim

[holger (Gast)]

Die Fuse muss 1 sein. Wobei die 1 gelöscht bedeutet.
Vieleicht spielt dein Prommerprogramm dir einen Streich.
Anklicken heisst programmieren, und damit 0 (gesetzt).
Negative Logik !

[Joachim (Gast)]

Also Haken weg = Kompatibilitätsmodus aus.
Soviel hab ich nun verstanden.
Trotzdem bleiben die Signale tot. Habe alle möglichen Kombinationen 
versucht. Mit und ohne Waitstates, SRE 1 oder 0 (Ports versucht, als IO 
direkt anzusprechen).
Es nutzt nichts, Ports F und G bleiben tot. Egal was ich mache.
Alle anderen funktionieren einwandfrei.

Ich gebs jetzt erstmal auf.. nach 5 Stunden Probiererei für heute die 
Nase voll.

Trotzdem Danke.

Joachim

[gtf (Gast)]

Hi  Joachim ,
 hast du auch AVCC mit der Versorgungsspanung verbunden,  hab mal gehört 
dass der PortF beim m64 vom AVCC versorgt wird?

[gtf (Gast)]

JTAG Fuse auf Eis gelegt? :- )
Beim m16 lassen sich alle JTAG Pinns nicht ändern wenn JTAG an ist.

[Joachim (Gast)]

So, Lösungsansatz gefunden.
Das Problem scheint nicht am Bus zu liegen, sondern am C-Compiler.
Die Port- und CPU-settings wurden über ein Unterprogramm aufgerufen.
Nun habe ich mal ein "Spaghetti" Programm geschrieben und keine CALLs 
benutzt.
Und plötzlich läufts!
Vermutlich wird der Stackpointer falsch initialisiert (laut Listfile auf 
0x10FF). Jedenfalls liegt es definitiv an Unterprogrammaufrufen.
Verwende den ICC Compiler und habe bisher mit Mega8 nie Probleme gehabt.
Vielleicht ist die Startup-Prozedur für den Mega64 falsch.
Alle bisherigen Messungen und Laufverhalten waren also nur Zufall.

Wieder ein Grund mehr für mich, künftig ausschließlich in Assembler zu 
programmieren.
Da sucht man 2 Tage lang nach irgendeinem eingebauten Compiler-Mist :-(
Von "effektiverem" Programmieren kann da keine Rede sein. Pure 
Zeitverschwendung.
Grrr!!

Trotzdem Danke für die Tips.

Joachim