Forum: Mikrocontroller und Digitale Elektronik at90s8515 -> mega8515 sram probleme


von Nik Bamert (Gast)


Lesenswert?

Hi!

Ich wollte den sourcecode des yampp3, der eigentlich für den at90s8515
geschrieben ist, für den atmega8515 umschreiben.
Bis jetzt leider mit nicht allzuviel Erfolg. Spi und Uart
funktionieren
weiterhin herrvorragend, nur bekomme ich die festplatte und das ram
nicht zum laufen. Nach einem Blick ins datenblatt habe ich bei den
einstellungen zwar einige neue register festgestellt, allerdings
sind die alten immer noch vorhanden und auch an der selben adresse.
Da steht auch noch was von einem schnelleren Timing, könnte ich dieses
evtl. wieder langsamer bekommen?

Zudem wird beim yampp3 die festplatte ganz normal über die ports a und
c
angesteuert, also ohne das sram interface. Somit sollte dieses
eigentlich funktionieren, tut es aber auch nicht. Gibt es denn beim
mega8515 so etwas wie ein Jtag interface, oder irgendwas das ich über
lock / fuse bits abschalten muss? Denn die Register die benutzt werden,
sind allesamt dieselben, ich kann mir das nicht wirklich erklären was es
sonst sein könnte.

Die Probleme habe ich im normal modus als auch im compatibility mode.
Hardwarefehler kann ich ausschliessen, ich habe alles mehrfach auf
lötbrücken überprüft und die verbindungen durchegemessen...

mfg Nik

von Nik Bamert (Gast)


Lesenswert?

-das timing kanns übrigens auch kaum sein, denn ich verwende für den
atmega nur einen 7.372mhz quarz

von Olaf (Gast)


Lesenswert?

Hast du auch beachtet das die mega8515 mit internem RC-Osc bei 1MHz
ausgeliefert werden?
Check mal die fuse-bits.

von Nik Bamert (Gast)


Lesenswert?

danke für den tipp, aber das ist es leider nicht.
Ich hab die fusebits gesetzt und der externe quarz
geht garantiert auch auf jeden fall, denn der uart funktioniert
korrekt. ach was kann das nur sein :(

von Olaf (Gast)


Lesenswert?

Ich meine mich zu erinnern, daß das Xmem interface des mega8515 im
default ein anderes timing bzw. zustand hat als beim 90s8515.

Solltest mal die Appnote AN085 ansehn. Möglich daß dies hilft.

von Nik Bamert (Gast)


Lesenswert?

oo vielen Dank, das könnte es wohl wirklich sein, da steht nämlich:

>Improvements to External Memory Interface:
>The combined Address/Data port in ATmega8515 outputs data
>until a new address is set up.
>Refer to the ATmega8515 data sheet for details on the changed timing.

Ich habe mir also mal das Datenblatt vom atmega8515 ein wenig genauer
angesehen und dabei herausgefunden, dass der uc ein neues Register
bekommen hat, ein sogenanntes Emcucr (extended mcucr).

Darin kann man, sofern man das möchte, den Speicher in zwei sektoren
aufteilen. Was aber warscheinlich wichtiger ist, ist dass man dort
auch
noch zwei waitstate bits zur verfügugund hat, um den Zugriff zu
verlangsamen. Ich denke mir mal, dass das der Grund ist, dann muss ich
wohl im Yampp code mal gründlich etwas untersuchen.

Dazu müsste ich jedoch etwas wissen; Das erste was der Compiler
ausführt ist main(),
oder werden da vorher noch irgendwelche codeschnipsel ausgeführt?

mfg Nik

von Benedikt (Gast)


Lesenswert?

Vor main wird u.a. manchmal der RAM gelöscht, oder Daten ins RAM
kopiert.
Das ist jedoch Compilerabhängig.

von Rufus T. Firefly (Gast)


Lesenswert?

Der Compiler führt gar nichts aus, der kann nur was in Maschinencode
übersetzen.


Zuerst führt der Controller den Startup-Code aus. D.h. ggf wird vor dem
main noch etwas anderes gemacht. Schau dir den assemblierten Quelltext
an und Du wirst sehen was dein Controller nach dem reset machen soll...

von Nik Bamert (Gast)


Lesenswert?

>Der Compiler führt gar nichts aus, der kann nur was in Maschinencode
>übersetzen

lol ich meinte ja den controller, sry :P

>Zuerst führt der Controller den Startup-Code aus. D.h. ggf wird vor
dem
>main noch etwas anderes gemacht. Schau dir den assemblierten
Quelltext
>an und Du wirst sehen was dein Controller nach dem reset machen
soll...
ok, dann sollte das aber so funktionieren wie ich das programmiert
habe.
Ich habe noch einen etwas älteren gcc und habe desshalb einfach
sbi benuzt, um die Register zu beschreiben. Waitstate ist nun auf dem
höchsten, was ich überhaupt einstellen kann, aber das funktioniert
immer
noch nicht, wie es soll-langsam gehen mir echt die ideen aus.
Kann es denn sein, das im bezug auf extMem ausser den Timings noch
etwas anderes geändert wurde,
wovon dann im Datenblatt allerdings nichts erwähnt wäre?

Als Latch habe ich ein sn74hc573 verwendet-ist dieses evtl. zu langsam?

von ape (Gast)


Lesenswert?

http://www.nongnu.org/avr-libc/user-manual/index.html

FAQ -> How to use external RAM?

Da is nen kleines Beispiel angeführt wie man es anstellt, das das SRAM
wirklich ganz zu Anfang initialisiert wird (noch vor dem restlichen
Start Up Code)

Ein normaler hc573 sollte schon schnell genug sein, bei mir
funktioniert er jedenfalls auch mit 18,432MHz ohne zusätzliche
Waitstates problemlos.

von Nik Bamert (Gast)


Lesenswert?

danke für den Link, den werde ich mir merken - da hats ja ziemlich
viel über den Gcc, oder besser gesacr die libc, da kann ich wies
aussieht noch ne riesen Menge lernen.

Doch im Code von dem yampp3 ist mir aufgefallen, das das Ram
auch erst im main initialisiert wird. Und zwar mit der Zeile

outp(MCUCR, 0xC0); //aktiviert Sram und waitstate

die zusätzlichen wait state bits im extended mcucr habe ich aber mit
sbi gesezt. Nun, der Compiler compiliert das brav, aber dennoch
steht im Datenblatt das man die Register nur bis adresse 0x1f bitweise
beschreiben kann. Mcucr und emcucr sind aber adresse 0x35.

Ich werde nun mal ausprobieren auch die weiteren waitstates mit
outp zu setzen. Liege ich total falsch und der gcc macht aus sbi sowiso
etwas anderes oder könnte dies die Lösung meines Problems sein?

von Nik Bamert (Gast)


Lesenswert?

mist, tippfehler, ich meinte

outp(0xC0, MCUCR);

von Nik Bamert (Gast)


Lesenswert?

oho, das hat schon mal etwas gebracht, ich krieg das busy flag der hdd
richtig ausgelesen :)

Nun gehts aber mit Fat noch nicht richtig weiter, ich denke mal das ist

ein Problem mit dem Ram-da dort die Fat tabelle sector buffer usw.
Liegen. Nun, vielleicht liegt es grundsätzlich an meinem Ram, es
handelt sich um ein "BS62LV256".
Nach datenblatt ist dies ein Very Low Power/voltage CMOS sram.
Und cmos brauch immer einen definierten Pegel an den Eingängen, wenn
ich mich da nicht täusche... Stellt das irgendein Problem dar? Ich
habe
leider nicht gerade ein anderes ram zur hand womit ich das testen
könnte...

von Nik Bamert (Gast)


Lesenswert?

naja ich hab nun auch noch ein anderes standard sram ausprobiert,
wieder nichts :( was kann das denn noch sein, ausser das timing und die
register?(verkabelung ist es ja auch nicht-alles durchgemessen)

von Nik Bamert (Gast)


Lesenswert?

Okay, ich denke, dass ich wieder mal eine Idee habe, was das Problem
sein könnte. Und zwar hängt das write signal der Festplatte an pb0
seit dem at90s8515 eine neue Funktion hinzugekommen; "OC1"
Dem Datenblatt kann ich zwar entnehmen, für was dass dieser Pin benutzt
werden kann, allerdings finde ich nirgends etwas darüber, wie ich den
denn einfach "normal" benutzen kann, also ohne dieses "OC1"...kann
mir jemand sagen ob es dazu ein register gibt, mit welchem ich die
funktion ausschalten könnte?

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.