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
Ich habe den gleichen Chip hier. WP und HOLD habe ich auf VCC gelegt. Ansteuerungstechnisch mache ich es eigentlich genauso wie Du: Schreiben:
1 | CS low |
2 | WREN
|
3 | CS high |
4 | CS low |
5 | WRITE
|
6 | 16 Bit Adresse |
7 | Daten schreiben... |
8 | CS high |
Lesen:
1 | CS low |
2 | READ
|
3 | 16 Bit Adresse |
4 | Daten lesen... |
5 | CS high |
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 ;-)
1 | #define SPI_DDR DDRB
|
2 | #define SPI_PORT PORTB
|
3 | #define SPI_SCK_BIT PB7
|
4 | #define SPI_MISO_BIT PB6
|
5 | #define SPI_MOSI_BIT PB5
|
6 | |
7 | #define FRAM_SEL_DDR DDRB
|
8 | #define FRAM_SEL_PORT PORTB
|
9 | #define FRAM_SEL_BIT PB2
|
1 | void
|
2 | spi_init(uint8_t mode) |
3 | {
|
4 | SPI_DDR |= 1<<SPI_MOSI_BIT | 1<<SPI_SCK_BIT; |
5 | SPCR = 1<<SPE | 0<<DORD | 1<<MSTR | 0<<SPR1|0<<SPR0 | mode<<CPHA; |
6 | SPSR = 1<<SPI2X; |
7 | }
|
8 | |
9 | uint8_t
|
10 | spi(uint8_t data) |
11 | {
|
12 | SPDR = data; |
13 | while (!(SPSR & 1<<SPIF)) |
14 | ;
|
15 | return SPDR; |
16 | }
|
1 | #define FM_WREN 0x06 // set write enable latch
|
2 | #define FM_WRDI 0x04 // write disable
|
3 | #define FM_RDSR 0x05 // read status register
|
4 | #define FM_WRSR 0x01 // write status register
|
5 | #define FM_READ 0x03 // read memory data
|
6 | #define FM_WRITE 0x02 // write memory data
|
7 | |
8 | #define SPI_MODE 0
|
9 | |
10 | #define select() FRAM_SEL_PORT &= ~(1<<FRAM_SEL_BIT)
|
11 | #define deselect() FRAM_SEL_PORT |= (1<<FRAM_SEL_BIT)
|
12 | |
13 | void
|
14 | fram_init(void) |
15 | {
|
16 | FRAM_SEL_PORT |= 1<<FRAM_SEL_BIT; |
17 | FRAM_SEL_DDR |= 1<<FRAM_SEL_BIT; |
18 | }
|
19 | |
20 | void
|
21 | fram_read(unsigned addr, uint8_t *data, unsigned size) |
22 | {
|
23 | spi_init(SPI_MODE); |
24 | |
25 | select(); |
26 | spi(FM_READ); |
27 | spi(addr >> 8); |
28 | spi(addr); |
29 | while (size--) |
30 | *data++ = spi(0); |
31 | deselect(); |
32 | }
|
33 | |
34 | void
|
35 | fram_write(unsigned addr, uint8_t *data1, unsigned size1, uint8_t *data2, unsigned size2) |
36 | {
|
37 | spi_init(SPI_MODE); |
38 | |
39 | select(); |
40 | spi(FM_WREN); |
41 | deselect(); |
42 | |
43 | select(); |
44 | spi(FM_WRITE); |
45 | spi(addr >> 8); |
46 | spi(addr); |
47 | for (; size1; --size1) |
48 | spi(*data1++); |
49 | for (; size2; --size2) |
50 | spi(*data2++); |
51 | deselect(); |
52 | }
|
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.
Wie sieht es denn mit der StartUp-Zeit aus? Der FRAM braucht, glaube ich, um die 10ms...
@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.
> Holt euch Steine und Waffen, bindet mich fest und lasst euch an mir aus
Ich bin dann mal schnell Fackeln und Mistgabeln holen... ;))
jaja meißt sind fehler dort zu finden, wo niemand sucht ;-))))))) wer den Schaden hat, spottet jeder Beschreibung
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.