SPI Interrupt wird nicht ausgelöst nach Sendevorgang

Hallo an alle,

Ich habe ein Problem mit der SPI, und zwar wird nach dem Senden der Daten das Interrupt Flag nicht gesetzt. Es geht um ein dsPic33E.

Hier die SPI und Interrupt Einstellungen:

Code:

---

INTCON2bits.GIE=0;   
IFS2bits.SPI2IF=0;//clear Interrupt flag
    IEC2bits.SPI2IE=0;//disable interrupt
   
    SPI2STATbits.SPIEN=0;
    SPI2CON1bits.DISSCK=0;
    SPI2CON1bits.DISSDO=0;
    SPI2CON1bits.MODE16=0;
    SPI2CON1bits.MSTEN=1;
    SPI2CON1bits.SMP=0;
    SPI2CON1bits.CKE=0;
    SPI2CON1bits.CKP=0;


    SPI2STATbits.SISEL=0b101; //interrupt when transmit is complete
    IPC8bits.SPI2IP=0b001; //priorioty 1
         
    SPI2STATbits.SPIEN=1; // ENABLE spi
   
    SPI2BUF=0x00;//clear buf
    SPI2STATbits.SPITBF=0; //clear BF
   
    IFS2bits.SPI2IF=0;//clear int flag


    INTCON2bits.GIE=1;
    IEC2bits.SPI2IE=1; //enable interrupt

---

Hier der Sendevorgang :

Code:

---

      CS=0;
      SPI2BUF=0xAD;
        CS=0; //no operation
        while(IFS2bits.SPI2IF==0); // wait
        IFS2bits.SPI2IF=0;//clear Int flag.
        dummy=SPI2BUF;
        CS=1;

---

Die SPI funktioniert, die Daten samt Takt kommen am Oszi an. JEDOCH wird das IFS2bits.SPI2IF Flag nie gesetzt.. Die Einstellungen sind genau so wie aus dem Microchip Datenblatt empfohlen.
Das Problem mit while(SPI2STATbits.SPITBF==1); ist, dass der gesetzt wird wenn der Buffer leer ist, jedoch arbeitet das Schieberegister dann noch, auch gut im Zeitdiagramm zu sehen.

Wer weiß was hier nicht stimmt ?

Vielen dank
Liebe Grüße,
steckplatte

Zitat:

---

Zitat von steckplatte

Hier der Sendevorgang :

Code:

---

      CS=0;
      SPI2BUF=0xAD;
        CS=0; //no operation
        while(IFS2bits.SPI2IF==0); // wait
        IFS2bits.SPI2IF=0;//clear Int flag.
        dummy=SPI2BUF;
        CS=1;

---

Die SPI funktioniert, die Daten samt Takt kommen am Oszi an. JEDOCH wird das IFS2bits.SPI2IF Flag nie gesetzt.. Die Einstellungen sind genau so wie aus dem Microchip Datenblatt empfohlen.
Das Problem mit while(SPI2STATbits.SPITBF==1); ist, dass der gesetzt wird wenn der Buffer leer ist, jedoch arbeitet das Schieberegister dann noch, auch gut im Zeitdiagramm zu sehen.

---

Hallo,

ich hab zwar gerade einen PIC24EPxxx am Wickel, der sollte da identisch sein, komme aber nicht dazu etwas zu testen. Ich würd das mal anders probieren und das Receivebuffer-Flag testen

Code:

---

uint8_t Send( uint8_t data)
{
    int temp;
    CS = 0;
    temp = SPI1BUF;                // empty receive buffer
    SPI1BUF = data;                  // data into buffer
    while( !SPI1STATbits.SPIRBF ) {  // all bits are shifted, receivebuffer is full
        ;
    }
    CS = 1;
    return SPI1BUF;
}

---

Wenn der Receivebuffer am Anfang leer ist, kann er erst voll sein, wenn alle Bits einmal durchgeschoben worden sind.

Noch zwei Hinweise deinen Code für andere lesbarer zu machen: wenn hier mit CS=0; //no operation gemeint ist, was der Kommentar sagt, schreib Nop(): hin. Sonst muß man dauernd überlegen, warum hier CS behandelt wird. Und rück bei while(IFS2bits.SPI2IF==0); // wait
wenigstens das Semikolon auf die nächste Zeile. Dann erkennt jemand, der den Code nicht gut kennt (und das bist auch du selbst in 3 Monaten) sofort die Schleife. Ich schreib das normalerweise noch etwas ausführlicher. Dann kann man da auch mal schnell irgendwelchen (Debug)Code einfügen und auch wieder rauskommentieren.

Vielleicht hilfts ja

MfG Klebwax

Hallo Klebwax,

Vielen dank für deine Antwort.
Leider funktioniert auch das nicht. Ist auch gut im Zeitdiagramm zu erkennen. Möchte auch nicht mit vielen delays und NOP's arbeiten um diese paar Taktzyklen aufzufüllen bis das Receive buffer wieder auf low ist..mit einem Interrupt ist das viel sauberer und genauer.
Das Datenblatt schlägt ja auch vor mit einem Interrupt zu arbeiten, verstehe nur eben nicht warum das nicht funktioniert..

Und Danke für die Tipps, werde das berücksichtigen!

Liebe GrüßeAnhang 33428

Zitat:

---

Zitat von steckplatte

Leider funktioniert auch das nicht. Ist auch gut im Zeitdiagramm zu erkennen. Möchte auch nicht mit vielen delays und NOP's arbeiten um diese paar Taktzyklen aufzufüllen bis das Receive buffer wieder auf low ist..mit einem Interrupt ist das viel sauberer und genauer.

---

Auf deinem Bild ist zwar kaum was zu erkennen, wenn ich aber die gelben Marken mal ernst nehme, schaust du aufs falsche Signal. Es geht um SPIRBF, ganz unten rechts. Das wird low, sobal du SPI1BUF liest, ( temp = SPI1BUF; ) ganz egal wann das ist, sonst könnte man das Byte je mehrmals auslesen ohne es zu merken. Und es wird high, wenn ein Datenwort hinausgetaktet worden ist. Das ist genau was du willst. Im Gegensatz zum Interruptflag kommt es immer, auch wenn man die Interruptbedingung mal falsch konfiguriert hat. Erst wenn du die FIFOs benutzt, hat das Interruptflag Vorteile. Nach der Theorie sollte es gehen und ich glaub, ich hab das auch schon so gemacht. Ich hab bloß im Moment keinen Code zur Hand, um nachzuschauen.

MfG Klebwax

P.S. Hab in meinem alten Code gefunden, daß ich das genauso gemacht habe.

Hallo Klebwax,

Oh tut mir leid, habe nicht gemerkt dass das Bild so klein geraten ist. Die gelben Marken waren um zu zeigen was ich eingestellt habe(CKE/CKP..)
Okay eventuell war mein Fehler dass ich vorher den Buffer nicht ausgelesen habe, damit der SPIRBF auf Low geht.
Werde dann das hier morgen ausprobieren, hoffe es klappt.

Code:

---

CS=0;
dummy=SPI2BUF; // auslesen damit SPIRBF auf Low geht
SPI2BUF=0xAD;
while(SPI2STATbits.SPIRBF==0)
; // warten bis SPIRBF wieder High wird
dummy=SPI2BUF;
CS=1;

---

Es wundert mich nur warum das mit dem Interrupt Flag nicht funktioniert. Hab im Microchip forum viele Problem Threads dazu gelesen, dass das Interrupt Flag einfach nicht gesetzt wird. Da kam auch die Lösung wegen den Remappable Pins, zuerst das SCK auf Eingang zu setzen und dann erst als Ausgang. Aber so richtig geklappt hat das noch nicht.

lG