PIC SPI-Receive liefert immer null

[Student (Gast)]

Hallo,

ich nutze gerade das erste Mal den SPI Modus des MSSP eines PIC18F.

Testweise wird ein Register des (Slave-) Chips beschrieben und dann 
wieder ausgelesen. Auf dem Oszi sieht das ganze auch gut aus (Befehl 
wird empfangen und es wird korrekt geantwortet).

In der Software allerdings gibt mir meine SPI-receive Funktion immer 
0x00 zurück. Mir gehen mittlerweile die Ideen aus, an welchen Stellen 
ich weiter nach Fehlern suchen sollte.

Ich habe bereits folgendes probiert:

- SPI Modus von 0 auf 1 geändert (2 und 3 lassen sich ausschließen)
- PPS geprüft; die Anschlusszuordnungen sind korrekt

-> Im Datenblatt wird angedeutet, dass es einen Unterschied zwischen 
Senden und Empfangen gibt, allerdings finde ich keine Möglichkeit ein 
Empfangen anzustoßen ohne Dummy-Daten zu senden.

Ich hoffe ihr könnt mir helfen :).

void main()
{
  [...]
    SRAM_CS = 0;
    spi_transmit(0x05); // Read Mode Register
    uint8_t mode_register = spi_receive();
    SRAM_CS = 1;
  [...]
}

uint8_t __inline spi_receive() // <-- liefert immer null?!
{
    SSP2BUF = 0x00;// transmit dummy data
    while(!SSP2IF)
        ;
    SSP2IF = 0;
    return SSP2BUF;
}

[volksvorg (Gast)]

Bräuchten ein paar mehr Infos.
Init der SPI.
Init der GPIO. Klassiker hast du auch die entsprechenden GPIO Pins als 
Ausgang bzw. als Eingang konfiguriert. ?
Ist der uC SPI Master oder Slave. Was für ein Chip hängt als Slave am 
SPI-Bus ?

[Jim M. (turboj)]

Wie sieht spi_transmit() aus? Ich frage das, weil SPI gerne mal einen 
FIFO hat und Du dann in spi_receive() ein "altes" Bye lesen würdest.

[Student (Gast)]

Der Chip wird im Master Mode betrieben. Es soll ein SRAM (23LC1024) 
angesteuert werden.

volksvorg schrieb:
> Init der SPI.

void spi_init(uint8_t spi_mode)
{
    SSP2STATbits.CKE = !(spi_mode       & 0x01);
    SSP2STATbits.SMP =  (spi_mode >> 1) & 0x01;
    
    SSP2CON1 |= 0x02; // Mode: SPI Master; Clock = Fosc/64
    SSP2CON1 |= _BS(5); // Enable MSSP2
}

volksvorg schrieb:
> Init der GPIO.

/* MSSP2 SPI */    
    LATB  &= ~ _BS(2); // Idle Level: Low
    TRISB &= ~ _BS(2); // SPI_CLOCK Output
    TRISB &= ~ _BS(3); // SPI_SO Output
    TRISB |=   _BS(1); // SPI_SI Input
    LATB  |=   _BS(0); // SPI_CS = High (unselect slave)
    TRISB &= ~ _BS(0); // SPI_CS Output

SPI Transmit sieht folgendermaßen aus:

void __inline spi_transmit(uint8_t data)
{
    SSP2BUF = data;
    while(!SSP2IF)
        ;
    SSP2IF = 0;
    // Read SSP2BUF to clear the Buffer Full (BF) Bit
    uint8_t trash_data = SSP2BUF;
}

Das mit dem FIFO gucke ich mir gleich nochmal an. Danke :).

[Student (Gast)]

Habe folgendes vergessen:

spi_init() wird folgendermaßen aufgerufen

spi_init(0x00);

[volksvorg (Gast)]

Wie hast du Chip Select gelöst? Ist eine weile her das ich mit PICs 
gearbeitet habe. Generell Vor dem Lesen muss CS HIGH sein. Um lesen zu 
können ziehst du CS auf LOW sendest vom Master Dummy Daten und zwar 
solange du Daten lesen möchtest. Und wenn du fertig bist ziehst du CS 
wieder auf HIGH. Z.B. Datenwort 16Bit. und du möchtest 1 Datenwort 
einlesen.

CS auf LOW. 

SPI_recieve();

CS auf HIGH

bei Zwei Datenworte

CS auf LOW. 

SPI_recieve();
SPI_recieve();

CS auf HIGH

usw.

[Student (Gast)]

Guten Abend,

danke für die Hinweise. Es gibt aber kein Problem mit dem Empfangen an 
sich.

Der Chip sendet als Antwort auf den Lese-Befehl 0x80. Der PIC liefert 
als empfangenen Wert aber immer 0x00 (anstatt 0x80), unabhängig von den 
(laut Oszi) tatsächlich empfangenen Daten.

[Volker S. (vloki)]

Der unbekannte PIC hat auf dem Pin für den SPI Eingang eine 
Analogfunktion, die nicht deaktiviert wurde?

So, oder ähnlich...

ANSELBbits.ANSB2 = 0;

[Student (Gast)]

Volker S. schrieb:
> Der unbekannte PIC hat auf dem Pin für den SPI Eingang eine
> Analogfunktion, die nicht deaktiviert wurde?
>
> So, oder ähnlich...ANSELBbits.ANSB2 = 0;

Gute Idee, leider ist das die richtige Lösung.

Das dürfte aber eigentlich nicht der Fall sein, denn ich habe alle 
Analogen Eingänge deaktiviert:

[Etwas über dem I/O-Setup vom MSSP2]
/* Disable ALL analog functions */
    ANCON0 = 0xFF;
    ANCON1 = 0x1F;

Ich habe einfach mal hinter der Init-Routine einen Breakpoint gesetzt 
und nachgesehen was in den ANCONx Registern drinsteht. Es sind nicht die 
obigen Werte. Nach etwas gesuche habe ich festgestellt, dass ein 
Programmteil diese Werte (falsch) neu schreibt. Wow. Ich stell mich dann 
mal in die Ecke.

danke :D