mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SPI-FRAM antwortet immer nur 0xFF


Autor: Albi G. (deralbi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Magnus Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: sechs ueber drei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albi G. (deralbi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albi G. (deralbi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hmm...

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albi G. (deralbi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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/F...

@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

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe den gleichen Chip hier. WP und HOLD habe ich auf VCC gelegt.
Ansteuerungstechnisch mache ich es eigentlich genauso wie Du:

Schreiben:
CS low
WREN
CS high
CS low
WRITE
16 Bit Adresse
Daten schreiben...
CS high

Lesen:
CS low
READ
16 Bit Adresse
Daten lesen...
CS high

Autor: Magnus Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albi G. (deralbi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ;-)

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
 #define SPI_DDR  DDRB
 #define SPI_PORT  PORTB
 #define SPI_SCK_BIT  PB7
 #define SPI_MISO_BIT  PB6
 #define SPI_MOSI_BIT  PB5

 #define FRAM_SEL_DDR  DDRB
 #define FRAM_SEL_PORT  PORTB
 #define FRAM_SEL_BIT  PB2
void
spi_init(uint8_t mode)
{
    SPI_DDR |= 1<<SPI_MOSI_BIT | 1<<SPI_SCK_BIT;
    SPCR = 1<<SPE | 0<<DORD | 1<<MSTR | 0<<SPR1|0<<SPR0 | mode<<CPHA;
    SPSR = 1<<SPI2X;
}

uint8_t
spi(uint8_t data)
{
    SPDR = data;
    while (!(SPSR & 1<<SPIF))
  ;
    return SPDR;
}
#define FM_WREN    0x06  // set write enable latch
#define FM_WRDI    0x04  // write disable
#define FM_RDSR    0x05  // read status register
#define FM_WRSR    0x01  // write status register
#define FM_READ    0x03  // read memory data
#define FM_WRITE  0x02  // write memory data

#define SPI_MODE  0

#define select()  FRAM_SEL_PORT &= ~(1<<FRAM_SEL_BIT)
#define deselect()  FRAM_SEL_PORT |=  (1<<FRAM_SEL_BIT)

void
fram_init(void)
{
    FRAM_SEL_PORT |= 1<<FRAM_SEL_BIT;
    FRAM_SEL_DDR  |= 1<<FRAM_SEL_BIT;
}

void
fram_read(unsigned addr, uint8_t *data, unsigned size)
{
    spi_init(SPI_MODE);
    
    select();
    spi(FM_READ);
    spi(addr >> 8);
    spi(addr);
    while (size--)
  *data++ = spi(0);
    deselect();
}

void
fram_write(unsigned addr, uint8_t *data1, unsigned size1, uint8_t *data2, unsigned size2)
{
    spi_init(SPI_MODE);
    
    select();
    spi(FM_WREN);
    deselect();
    
    select();
    spi(FM_WRITE);
    spi(addr >> 8);
    spi(addr);
    for (; size1; --size1)
  spi(*data1++);
    for (; size2; --size2)
  spi(*data2++);
    deselect();
}

Autor: Albi G. (deralbi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hold+WP also per PullUp..

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, habe ich so gemacht oder direkt auf VCC.

Autor: Albi G. (deralbi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albi G. (deralbi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-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.

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie sieht es denn mit der StartUp-Zeit aus? Der FRAM braucht, glaube 
ich, um die 10ms...

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Albi G. (deralbi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albi G. (deralbi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Holt euch Steine und Waffen, bindet mich fest und lasst euch an mir aus


Ich bin dann mal schnell Fackeln und Mistgabeln holen... ;))

Autor: Albi G. (deralbi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu Hilfe!! :-P

Autor: winne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jaja

meißt sind fehler dort zu finden, wo niemand sucht  ;-)))))))

wer den Schaden hat, spottet jeder Beschreibung

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.