Vorweg: auch Leute mit SPI-EERPOM-Erfahrung können hier helfen!
Hallo.
Ich bin am Ende. Ich habe hier von Ramtron SPI-FRAMs liegen und ich kann
die auf Teufel komm raus nicht ansprechen. Doer vllt kann ich die
ansprechen.. aber die Viecher reden nicht mit mir.
Das SPI-Protokoll hab ich jetzt aus Wut in Software realisiert um
Hardware-Protokoll-Phasen-und-Clock-Polatiäts-Fehler zu umgehen.
Die Dinger haben sonen komischen Hold und WriteProtect Pin. Vielleicht
liegts auch daran. Beide sind "Active Low" also hab ich die auf +
gelegt. Bzw jetzt nochmal das ganze oper Software auf high gezogen...
Betriebsspannung liegt an und alle Signale kommen dort an, wo sie
sollen. Die SPI hab ich durch Warteschleifen schön langsam gemacht.
Prinzipiell isses aber egal.. die Chips können angeblich 20Mhz.
Der Code ist im Anhang.
Es geht um den Chip FM25CL64 und FM25L256b also ein 8 bzw 32kb-FRAM.
Die Chips sind eigentlich direkt als Ersatz für EEPROMs geeignet. Also
ist das Protokoll wahrscheinlich ähnlich/gleich.
Das Schreiben in den Chip hinein kommt an den Beinen des Chips an. Ob es
auch tiefer in den Chip eindringt weiß ich nicht... da das Lesen nicht
klappt und immer nur 0xFF zurückkommt. An der MISO-Leitung ist weder ein
Pull-Up, noch ein Pull-Down. Wenn ich die Leitung auf GND lege, lesen
meine Routinen auch 0x00 ein. Also klappt das Lesen prinzipiell.
Insgesamt sitze ich an dem Chip nun schon seit 2 Tagen un bekomme es
einfach nicht hin. Keine Ahnung mehr, an was es liegt. Ich hab nun
mitlerweile auch schon den 4. Chip drauf... falls irgendeiner mal
kaputtgegangen ist... Fehlanzeige.
Wenn sich jmd den Code anschauen könnte oder sonstige Tips geben könnte
wäre ich irre Froh.
Vllt hat auch schon jemand direkt mit den Chips erfahrung.. wäre auch
interessant.
Danke.
> Es geht um den Chip FM25CL64 und FM25L256b also ein 8 bzw 32kb-FRAM.> Die Chips sind eigentlich direkt als Ersatz für EEPROMs geeignet. Also> ist das Protokoll wahrscheinlich ähnlich/gleich.
^^^^^^^^^^^^^^
Wie bitte?
Hast du noch keinen (ernsthaften!) Blick ins Datenblatt riskiert?
Gruß,
Magnetus
2 Tage am Tisch sitzen. Und es klappt nicht. Das Datenblatt nicht
angeschaut. Kein Scope, oder Logikanalyzer. Muss ne tiefe Meditation
sein. Nirwana und zurueck. Und es laeuft immer noch nicht. Tja..... Wie
waer's mit Kung Fu ? Nicht dass es nachher gehen wuerde, aber dann ist
zumindest etwas gemacht worden.
Daß CLK und MOSI beide 15 sind, kommt mir merkwürdig vor.
Dann ist ja eine von diesen Zeilen überflüssig:
pio.OutputDriverEnable(CLK);
pio.OutputDriverEnable(MOSI);
Was bedeuten diese Werte überhaupt?
Ich hätte da Bitmasken vermutet, also 1,2,4,8,16 usw., aber nicht 15.
Peter
Hehe Peter.. ja sorry. Die 15 bei MOSI war nur ein Test.. ist in
wirklichkeit ne 14 ;-). Die Zahlen geben an, welcher GPIO-Pin
angesetuert werden soll. Die Funktionen suchen sich dann automatisch das
richtige Port raus und setzen das entsprechende Bit an der richtigen
Stelle. Das ganze wird vom Compiler so optimiert, dass es letztlich nur
ein einziger ASM-Befehl ist. Ich arbeite mit nem AVR32.
@Die anderen: Nunja. Ich hab sehr wohl schon "ein wenig" in Datenblatt
geschaut... das "Wahrscheinlich" resultiert daraus, dass ich die
Datenblatter von SPI-EEPROMs bisher nicht angeschaut habe. Im DS der
FRAMs steht aber "Direct Hardware Replacement for EEPROM" gleich auf der
ersten Seite oben. Aber zu schreiben, dass man erstmal das Datenblatt
lesen soll.. nuja.. wenn man nix zum Thema beitragen kann und selber nix
konstruktives weiß, macht man sich halt anders wichtig. Wow, leute.. ihr
habt echt den längeren. -_-
Das SPI Interface der Chips ließt immer bei steigender Flanke der Clock
ein. Ich denke daher, dass meine SPI-Emulation korrekt ist.
Das SPI-Lesen hab ich noch ein Wenig verändert, aber von der Sache her
ist es kein großer Unterschied. Der FRAM gibt die Daten bei sinkender
Flanke raus.. danach kann man sie einlesen.
Fehlerquellen können sein:
-SPI-Emulation ( ich glaubs nicht )
-Hold-Pin blockiert die Kommunikation (Dürfte aber eigentlich nicht, da
ich den Holdpin auf + ziehe und das sogar datenblattgerecht, nur
dann, wenn die Clock auf 0 ist. Den /WP-Pin mache ich mit dem Hold-Pin
in einem Schub.
-Der Write-Protect-Pin funkt dazwischen.. aber das erklärt nicht, warum
das lesen des Statusregisters 0xFF liefert.
-> Gerade mit dem Hold und WriteProtect-Zeug hab ich Angst, dass ich was
im Datenblatt falsch verstanden habe.
-Betriebsspannung liegt an (3.3V, nur 100nF geblockt).
-Das SPI-Protokoll verwendet MSBfirst.. das tue ich auch.
-MISO ist hochohmig. (6µA, wenn ich es nach + kurzschließe.. 192µA, wenn
ich es mit GND kurzschließe. Da 192µA wesentlich mehr sind als 6µA hab
ich mal den internen Pullup zusätzlich deaktivert. jetzt sind es in
beide Richtungen 0.6µA - Am Ergebnis 0xFF hat sich nix geändert)
Eigentlich ist das Protokoll ja kinderleicht. Deswegen bin ich ja so
verzweifelt. ..und bitte.. Sprüche. ala "Trottel.. schau ins
Datenblatt!!" hmmh naja. Muss sowas sein? Meckert lieber über die
Rechtschreibung.. das kommt eurem Nieveau näher.
Im Anhang nochmal der aktuelle Code, wie er gerade compiliert ist.
Eine Kleinigkeit: Welcher SPI Modus verwendet wird entscheidet sich u.A.
darüber, ob SCLK bei fallender Flanke von CS low oder high ist. Ist bei
dir aber beim ersten CS undefiniert.
FRAM funktioniert mit AVR SPI Mode 0.
Gut, danke. Ich habs jetzt so, dass CLK immer low ist, solange kein
Transfer ist. So sind die Transfers im Datenblatt auch dargestellt. Am
Kommunikationsverhalten hat sich aber nix verändert. :-(
Hmmh. Im Datenblatt ist mir noch was aufgefallen: Einerseits sagt das
Datenblatt, dass der Holdpin - wenn er auf GND liegt - die Kommunikation
unterbricht. Andererseits ist auf Seite 4 des Datenblatts (des
32kb-Chips) wunderschön dargestellt, wie man einen FRAM mit nur 3
Leitungen verbindet.
-> Dort ist Hold dauerhaft auf GND. :-/ Was nun?
http://www.ramtron.com/lib/literature/datasheets/FM25L256Bds_r3.0.pdf
@Andreas Kaiser: Wenn du so einen Ram-Baustein schonmal zum Laufen
bekommen hast, kannst du bitte den Code dazu senden? Ist nicht schlimm,
wenns für die kleinen 8bitter ist ;-) Wichtig ist mir das Prinzip.
Irgendeine Kleinigkeit fehlt mir hier noch.
MFG
Mal ein paar (doofe?) Fragen:
Hast du auch wirklich deinen "MOSI"-Pin mit SI des FRAMs und deinen
"MISO" mit SO des FRAMs verbunden? Überprüfe das bitte noch mal, auch
wenn du dir im Moment sicher bist, dass es so ist.
Hängt an deinem SPI-Bus noch etwas anderes ausser dem FRAM?
By the way: Ich lasse mich nur ungern anpöbeln.
Albi G. wrote:
> ersten Seite oben. Aber zu schreiben, dass man erstmal das Datenblatt> lesen soll.. nuja.. wenn man nix zum Thema beitragen kann und selber nix> konstruktives weiß, macht man sich halt anders wichtig. Wow, leute.. ihr> habt echt den längeren. -_-> verzweifelt. ..und bitte.. Sprüche. ala "Trottel.. schau ins> Datenblatt!!" hmmh naja. Muss sowas sein? Meckert lieber über die> Rechtschreibung.. das kommt eurem Nieveau näher.
Gruß,
Magnetus
>By the way: Ich lasse mich nur ungern anpöbeln.
Nunja.. ;-) Ich hab nicht angefangen... oder? :-P
Zur Verbindung: ja, ich habs grade nochmal gecheckt. Ich hab auch alle
Pins schonmal einzeln wacheln lassen... das kommt überall dort an, wos
ankommen soll.
Es hängt nix anderes am SPI-bus. Die Kabel sind recht lang.. (vllt 8cm)
aber das dürfte bei den Geschwindigkeiten bei Weitem noch kein Problem
sein.
@ Andreas Watterott (andreasw)
Kannst du mal konkreten Quelltext posten? Ich meine, wenn das Prinzip
gleich ist, wird der Fehler nicht im Prinzip liegen, sondern im Code ;-)
Oder Hardware. hmmh.
Hast du die Hold bzw WP-Pins per Pull-up auf + gezogen, oder per
software?
Danke für die Antworten erstmal ;-)
Schau dirs an. Genau dein Abklatsch.. nur mit meinen IO-Funktionen. (Die
IO-Funktionen funktionieren aber tadellos)
Meine SPI-Funktion sollte Mode0 darstellen.
es wird konstant 0xFF empfangen.
MISO-Leitung lässt sich Stromlos auf beide Potentiale ziehen. Ein
Kurzschluss isses nicht.
Der AVR läuft auf 10Mhz.. also laufen die IOs mit max 750kHz. Zu schnell
kann das nicht sein.. selbst bei 8cm-kabeln.
:-D Fortschritt!!! Ich hab grade nen neuen Ram draufgelötet! Er antworte
nun
nur 0x00! Wahnsinn.
-> Lötfehler hab ich aber schon kontrolliert.
Edit:
:-D Noch was tolles! Ich hab nach dem Beitrag hier gleich wieder mein
JTAG-MkII angeschlossen.. und siehe da: 0xFF :-)
JTag ab: 0x00, JTAG dran: 0xFF.
Gehen tuts nicht egal wie.
-> Vermutung: Vllt ist die Resetquelle anders, wenn das JTAG-Ding dran
ist. Eventuell sind die Pins dann anders initalisiert, wenn ich Strom
auf den AVR32 gebe. Wer weiß. Komisch ist das. Keines der Pins die ich
zur SPI-Kommuniaktion nutze haben was mit dem JTAG-Interface zu tun.
Die Initialisierung der SPI-Pins direkt an den Programm-Start zu legen
bringt auch nix.
@Albi:
Hast du auch WIRKLICH nachgeschaut, ob deine 750 kHz maximale
Pin-Frequenz nicht zu schnell sind?
Vielleicht verändert der angeschlossene JTAG auch das Timing des
Controllers ein wenig, und dadurch funktionieren deine Routinen, die
vorher nicht geklappt haben, plötzlich?
Ne Leute. Jetzt ist schluss! :-D :-D :-D
Holt euch Steine und Waffen, bindet mich fest und lasst euch an mir aus
;-)
Meine GetPinLevel-Funktion hatte einen Fehler. Dort wurde in der Tat die
Pinnummer als Bitmaske werwendet und nicht als Bit-Offset. :-/
also:
return GPIO.port[pin >> 5].pvr & (pin & 0x1F);
anstatt
return GPIO.port[pin >> 5].pvr & 1<<(pin & 0x1F);
Booar. Nun antwortet es korrekt. Booar. Bekloppter Albi :-)
Der FRAM Grüßt mich nun mit einem netten "Hallo!".
Jetzt musses noch mit der Hardware-SPI klappen.. dann ists gut.
Danke für eure nette Hilfe und so.. und sorry für eure
Zeitverschwendung.
Wie ich drauf gekommen bin: Vollkommen irrationales Denken ;-)
Ich hab mir gedacht, wenn der Miso-Pin durch das JTAG-Interface geärgert
wird, mache ich mir den Spaß und Leite das MISO-Signal mal um. Und
immernoch kamen Konstante Werte raus - aber unabhängig vom
JTAG-Inferface. Toll. Also hab ich das Kabel wieder zurücklöten wollen..
aus Flüchtigkeit (zum glück!) unter Spannung. Ich löte das Kabel ab, der
Controller bekommt beim Absetzen des Lötkolbens einen Resetstoß
(passiert öffters) Das Display blinkt, initalisiert neu und es kommt
immernoch der gleiche Wert aus dem FRAM (0xFF). Ich hätt wenigens
erwartet, dass es zu 0x00 wird. Nix ist. Ich löte nun also einfach nur
um die Funktionalität der SPI-Routine zu testen ein kabel an den Pin und
Zeihe das Potential auf Masse. Immernoch 0xFF. Nun wars klar:
Softwarefehler beim Einlesen. Geschaut ob meine SPI-Routine stimmt..
stimmte. In die PIO-Klasse gescrollt.. und PATSCH!
Hehe.
HardwareSPI klappt bis 30MHz. Zumindest sind es rein rechnerisch 30Mhz.
Hab leider kein Oszi zur Verfügung. Aber eingestellt hab ich 30Mhz.
Verwunderlicht dass 30Mjhz durch die langen Kabel findet. Egal. Aber
60Mhz klappen leider nicht mehr ;-)
juhu. Ich gönn mir jetzt erstmal ne Milch.
