Hallo zusammen und frohes Neues,
über SPI möchte ich ein 256-Kbit FM25W256 FRAM Modul von Cypress
Semoconductors beschreiben und auslesen - was man damit eben so macht.
Leider funktioniert das noch nicht so wirklich hervorragend.
Genauer gesagt scheint das Auslesen wohl zu funktioieren allerdings
hapert es es beim Schreiben. Das WEN Bit wird anscheinend nicht gesetzt.
Meine Funktion zum Beschreiben sieht wie folgt aus:
1
constuint8_tFRAM_READ=0b00000011;
2
constuint8_tFRAM_WRITE=0b00000010;
3
constuint8_tFRAM_WRDI=0b00000100;
4
constuint8_tFRAM_WREN=0b00000110;
5
constuint8_tFRAM_RDSR=0b00000101;
6
constuint8_tFRAM_WRSR=0b00000001;
1
voidSPI_FRAM_WRITE(uint16_tadress,uint8_t*pdata){
2
3
HAL_GPIO_WritePin(FRAM_CS_GPIO_Port,FRAM_CS_Pin,RESET);//Enable FRAM SPI
Wenn ich anschließend den Speicher auslese hat sich nichts verändert.
Das Statusregister hat den Wert 0b00100000.
Ich finde einfach nicht meinen Fehler...
Fragenhagel schrieb:> void SPI_FRAM_WRITE(uint16_t adress, uint8_t* pdata){> ...> for(int i = 0; i < sizeof(pdata) / sizeof(pdata[0]); i++){
Du gibst einen Pointer auf einen Buffer runter und berechnest dann die
zu übertragende Länge als sizeof(pdata) / sizeof(pdata[0]). Das ist hier
aber nicht zielführend, denn der Trick funktioniert nur für Arrays,
nicht für Pointer.
Erweitere die Funktion um die Angabe der Länge:
Wenn Du in der aufrufenden Funktion ein "echtes" Array hast, kannst Du
dort den Divisionstrick anwenden, um die Länge auszurechnen.
P.S.
Und nein, komm jetzt nicht auf die Idee, in der Parameterliste jetzt
"uint8_t pdata[]" zu schreiben. Das ist auch kein Array, nur eine andere
Schreibweise für den Pointer. Die Längeninformation hast Du hier einfach
nicht mehr, daher musst Du diese übergeben.
Ah, das werde ich morgen früh direkt Mal testen! Klar, dass man so nicht
auf die Größe des Arrays kommt. Aber müsste dann nicht trotzdem immerhin
das WREN Bit gesetzt werden?
Fragenhagel schrieb:> Aber müsste dann nicht trotzdem immerhin das WREN Bit gesetzt werden?
Quatsch.. das wird ja durchs schreiben wieder zurückgesetzt. Bzw. durch
die High Flanke vom NSS...
Bist Du sicher das die Funktion HAL_SPI_Transmit_DMA(..) blockiert?
Falls nicht wird direkt nach dem Start der Übertragung das Interface mit
writePin wieder deaktiviert.
Beide Ansätze haben bisher noch keinen Erfolg erbracht. Langsam habe ich
die Vermnutung, dass ich generell bei der SPI-Übertragung Fehler mache.
Selbst wenn ich einfach nur in der while-Schleife, ohne irgendetwas
anderes im Programm zu tun, versuche nur das WREN-Bit zu setzen und
anschließend auszulesen klappt dies bei mir nicht.
Das ganze sieht dann so aus:
1
uint8_tWREN=0b00000110;
2
uint8_tWRITE=0b00000010;
3
4
uint8_ttx_buf[2];
5
uint8_trx_buf[2];
1
while(1)
2
{
3
tx_buf[0]=WRITE;
4
5
HAL_GPIO_WritePin(FRAM_CS_GPIO_Port,FRAM_CS_Pin,RESET);//Enable FRAM SPI
Fragenhagel schrieb:> Das Array rx_buf wird nicht beschrieben und behält die Werte 0,0...
Das ist erwartet ... du sendest einen WRITE Befehl (keinen
vollständigen), dabei wird nur vom Master gesendet, der FRAM sendet
keine Daten zurück (siehe Datenblatt Memory Write: SO ist Hi-Z). Dann
liest der SPI halt nur 0/1 (je nach Pull-up/down Situation am MISO Pin)
oder zufällige Daten.
Um herauszufinden ob dein WREN Befehl geklappt hat kannst du es mit
einem RDSR (Read Status Register, 0000 0101b) versuchen. WEL (Bit 1)
müsste gesetzt sein wenn der WREN Befehl vorher geklappt hat.
AVerr schrieb:> Fragenhagel schrieb:>> Das Array rx_buf wird nicht beschrieben und behält die Werte 0,0...>> Das ist erwartet ... du sendest einen WRITE Befehl (keinen> vollständigen), dabei wird nur vom Master gesendet, der FRAM sendet> keine Daten zurück (siehe Datenblatt Memory Write: SO ist Hi-Z). Dann> liest der SPI halt nur 0/1 (je nach Pull-up/down Situation am MISO Pin)> oder zufällige Daten.>> Um herauszufinden ob dein WREN Befehl geklappt hat kannst du es mit> einem RDSR (Read Status Register, 0000 0101b) versuchen. WEL (Bit 1)> müsste gesetzt sein wenn der WREN Befehl vorher geklappt hat.
Das ist natürlich ein dummer Fehler. Ich hatte eigentlich vor das
Statusregister auszulesen. Werde das sofort mal ausprobieren.
Fragenhagel schrieb:> Es funktioniert leider immernoch nicht.
Ich finde leider gerade den Thread nicht, aber es gab einen wo
der Problemsteller mit seinem Aufbau (Flash-EPROM) zu kämpfen
hatte. Das leidige Stichwort Abblock-Kondensator. Also wenn du
mal deinen Aufbau zeigen könntest ob da vielleich ein rein
elektisches Problem drin steckt? Ob jetzt FRAMs gegenüber
Flash-EPROMs empfindlicher oder unempfindlicher sind wage ich
nicht einzuschätzen.
Und dann wie üblich: Leitungslängen bzw. Flanken-Empfindlich-
keit bei SPI Leitungen und Massebezug ist auch ein Thema für
den Aufbau.
jo mei schrieb:> Fragenhagel schrieb:>> Es funktioniert leider immernoch nicht.>> Ich finde leider gerade den Thread nicht, aber es gab einen wo> der Problemsteller mit seinem Aufbau (Flash-EPROM) zu kämpfen> hatte. Das leidige Stichwort Abblock-Kondensator. Also wenn du> mal deinen Aufbau zeigen könntest ob da vielleich ein rein> elektisches Problem drin steckt? Ob jetzt FRAMs gegenüber> Flash-EPROMs empfindlicher oder unempfindlicher sind wage ich> nicht einzuschätzen.>> Und dann wie üblich: Leitungslängen bzw. Flanken-Empfindlich-> keit bei SPI Leitungen und Massebezug ist auch ein Thema für> den Aufbau.
Eigentlich sollte der Aufbau keine Probleme bereiten, da ich das
CY15FRAMKIT-001 Development kit von Cypress direkt über den Arduino
Connector auf einem NUCLEO Board verbunden. Ich sehe auch dass gesendet
wird allerdings kann ich momentan leider nur ein Signal zur selben Zeit
auf meinem Oszilloskop betrachten. Das macht es schwierig zu erkennen,
ob wirklich die richtigen Bytes gesendet werden.
Werner P. schrieb:> vielleicht hilft dir das weiter
Vielen Dank schon einmal für die Bereitstellung deines Codes. Ich werde
mich dransetzen und versuchen das ganze wie bei dir umzusetzen.
Fragenhagel schrieb:> Werner P. schrieb:>> vielleicht hilft dir das weiter>> Vielen Dank schon einmal für die Bereitstellung deines Codes. Ich werde> mich dransetzen und versuchen das ganze wie bei dir umzusetzen.
Hab mir grad mal den Schaltplan von dem Dev Board angesehen.
Hast Du mal geprüft ob die Pins WP und Hold des SPI FRAM auch die
richtigen Pegel haben? Sollten beide auf HIGH liegen.
Moin in die Runde,
Fragenhagel schrieb:> Eigentlich sollte der Aufbau keine Probleme bereiten, da ich das> CY15FRAMKIT-001 Development kit von Cypress direkt über den Arduino> Connector auf einem NUCLEO Board verbunden.
Ich kämpfe zufälligerweise auch gerade mit einem Nucleo64-Board und dem
Cypress FRAM Kit :-) Ich hatte zuerst das Problem, dass meistens nur
"Müll" über SPI gekommen ist, egal welche SPI-Geschwindigkeit. Erst als
ich die 2. Masse vom Nucleo-CN10-Connector zum GND neben SCK am
FRAM-Board verbunden habe lief alles, sogar mit 20 MHz über 15 cm
Drätchen.
Hast du den CyKit Jumper auf 3.3V umgestellt? Wie ist denn deine SPI
konfiguriert (CubeMX)? Welche SPI und CPU-Geschwindigkeit?
Ich selbst habe nun immer noch ein komisches Problem, und zwar dass
manchmal beim ersten Schreiben (oder Lesen?) von 9 Bytes ab Adresse 0
nur Nullen geschrieben (oder gelesen?) werden. Die darauffolgenden
Burst-Writes/Burst-Reads (nutzen dieselbe Funktion) an Adressen weiter
hinten im FRAM klappen dagegen immer problemlos.
UPDATE: Sieht so aus, dass es bei mir das Auslesen ist, was die Nullen
zurückliefert. Manchmal werden nach dem Reset die 9 richtigen Bytes
ausgelesen, manchmal 9 mal 0x00. Es hängt auch NICHT von der
SPI-Geschwindigkeit ab. Bin momentan ratlos.
Grüße
Anguel
Noch ein Update zu meinem Problem:
Ich glaube ich habe es gelöst :-) Ich hatte das FRAM-Board "zum Schutz"
in seiner Plastikverpackung drin. Wahrscheinlich ein
super-antistatisches Material.
Als ich es jetzt da heraus nehme, treten keine Probleme mehr auf. Kommt
das irgendwie hin? Wenn es drin ist sehe ich die Fehler, draußen nicht.
Jetzt brauche ich auch die 2. Masse vom Nucleo-Board nicht.
Ich hoffe das hilft,
Anguel