Hat hier jemand schonmal xmega A1U mit EBI und SDRAM verwendet?

[Christian (dragony)]

Moin.

Ich habe Probleme mit dem EBI. Der CS-Pin macht einfach nichts. Ich 
könnte ihn zwar auch einfach GNDen, aber das ist nicht Sinn der Sache. 
Das EBI ist schon soweit konfiguriert, dass es laut Oszi erfolgreich 
auto refreshes ausgibt (ist also im SDRAM Modus) und auch lds und sts 
toggelt an den richtigen Pins rum. CS bleibt aber immer HIGH oder LOW, 
je nachdem, wie ich _OUT voreingestellt habe. _DIR ist für den CS-Pin 
immer gesetzt. Eigentlich müsste er da rumtoggeln. Als ob er auf 3 Port 
EBI steht...

PORTCFG_EBIOUT = 0b10. Da erwarte ich den CS3 (den man für SDRAM nehmen 
muss) auf F7.

EBI_CTRL = 0b01000010. Also 8 Bit und 4 Port EBI.

Was kann man da sonst noch falsch machen?

Achja, es ist ein atxmega128a1u.

[Falk B. (falk)]

Beitrag "Re: Viel RAM am kleinen Controller"

[Christian (dragony)]

Hallo Falk,

ich habe mir deinen Code und dein Routing mal angeschaut. Das Routing 
ist identisch. Der Code ist hier Assembler, aber das spielt ja keine 
Rolle. In den Registern steht das selbe drin, wenn man davon ausgeht, 
dass Atmel damals keine Zahlendreher in ihren Headerfiles eingebaut hat.

Also ich finde den Fehler einfach nicht. Manuell vial PORTF_OUTSET 
PORTF_OUTCLR kann ich CS problemlos toggeln. Sieht im Oszi sauber aus. 
Aber EBI macht da nichts. Was ich etwas verdächtig finde ist, dass ich 
den CS manuell überhaupt toggeln kann. Wenn EBI aktiv wäre, müsste der 
Pin für Änderungen an PORTF_OUTSET PORTF_OUTCLR eigentlich gesperrt 
sein.

Da ich im Oszi den SDRAM-Refresh sehe, müsste EBI doch hier auch den CS 
periodisch LOW ziehen, oder?

Kannst du dich erinnern, ob der CS bei dir damals irgendwie rumgezickt 
hat?

[Christian (dragony)]

Achso und ich habe in deinem Code nirgendwio die Stelle gefunden, wo du 
vom CS-Pin PORTF_OUT HIGH setzt, bevor du _DIR auf 1 setzt. Das macht 
man ja eigentlich so, damit CS nicht kurz LOW geht. Wenn du das aber gar 
nicht gemacht hast, könnte bei dir der /CS chronisch LOW gewesen sein, 
ohne dass du es gemerkt hast?

[Falk B. (falk)]

Christian schrieb:
> Da ich im Oszi den SDRAM-Refresh sehe, müsste EBI doch hier auch den CS
> periodisch LOW ziehen, oder?
>
> Kannst du dich erinnern, ob der CS bei dir damals irgendwie rumgezickt
> hat?

Puhhh, du fragst mich Fragen. Das war von ZEHN Jahren!
Ich mach mal den Olaf S. . . .
An CS Probleme kann ich mich nicht erinnern. Ob ich dort mal das Oszi 
drangehalten habe aber auch nicht 8-0

Wait . . .

Ich habe meinen uralten Prototypen ausgegraben, den gibt's noch! Und 
siehe da, CS ist dauerhaft LOW.

Im Anhang CKE und CLK.

[Christian (dragony)]

Vielen Dank für die Info. Wenn ich hier CS einfach auf Dauer-LOW 
schalte, funktioniert es. Ist halt nicht sauber, weil der CS ja 
eigentlich nicht Dauer-LOW sein sollte. In diesem Fall natürlich egal. 
Bin froh, dass es überhaupt funktioniert. xmega ist ja leider eh tot. 
Ich kann mir zwar nicht vorstellen, dass so ein Errata nicht aufgefallen 
ist und vermute den Fehler weiterhin bei mir/uns, aber naja, wat solls.

Nutzt du die Dinger noch? Ist immerhin 10 Jahre her :D

[Falk B. (falk)]

Christian schrieb:
> Nutzt du die Dinger noch? Ist immerhin 10 Jahre her :D

Nö, das war mal ein nettes Projekt nebenbei, aber seit dem hab ich nix 
mehr mit Xmega gemacht.

[Volker B. (Firma: L-E-A) (vobs)]

Christian schrieb:
> Wenn ich hier CS einfach auf Dauer-LOW
> schalte, funktioniert es. Ist halt nicht sauber, weil der CS ja
> eigentlich nicht Dauer-LOW sein sollte.

Selber habe ich mit dem EBI nicht gearbeitet und deshalb auch keine 
eigenen Erfahrungen damit.

Meine Überlegung: Wäre es möglich, dass CS nur dann inaktiv wird, wenn 
mindestens 2 CS-Signale definiert sind? Das wäre vielleicht ein Versuch 
wert, wenn Du noch einen entsprechenden Pin übrig hast...

Grüßle,
Volker

[Rick (rick)]

Christian schrieb:
> Ist halt nicht sauber, weil der CS ja
> eigentlich nicht Dauer-LOW sein sollte.
Warum nicht? Hast du ein Datenblatt, wo das so drin steht?