PIC16 I2C-Interrupt tritt nicht auf, wenn die serielle Schnittstelle aktiviert ist

Ich verwende einen PIC16F1825-PIC mit mittlerer Reichweite und habe ihn eine ganze Weile ohne Probleme mit einem UART und SPI verwendet. Als ich Code hinzufügte, um I2C zu handhaben (anstelle von SPI - es ist entweder das eine oder das andere auf diesem PIC), stieß ich auf Probleme, weil ich den I2C-Interrupt nicht erhielt - daher würde SCL für immer gestreckt bleiben.

Nach einigem umfangreichen Debugging habe ich herausgefunden, dass das Entfernen des Codes, der die serielle Schnittstelle aktiviert hat, das Problem behoben hat - die I2C ISR wird aufgerufen und verhält sich normal.

Alles, was ich in der seriellen Initialisierung tue, ist, SPBRG einzustellen und dann:

 bcf         TXSTA, SYNC             ; Async (default)
 bsf         RCSTA, SPEN             ; Active serial port

 bsf         TXSTA, TXEN             ; Enable TX
 bsf         RCSTA, CREN             ; Enable RX

Dass es. Es sind keine Interrupts aktiviert (ich habe nur das Flag auf Senden gesetzt)

Ich habe die Dokumentation und die Errata durchsucht und finde keinen Hinweis darauf, dass das Aktivieren der seriellen Schnittstelle die I2C-Funktionalität wie folgt beeinträchtigen würde. Ist das mein Missverständnis oder gibt es hier einen tatsächlichen Siliziumfehler?

Ich sehe dies nicht in den Errata für das Gerät aufgeführt. Um einen Programmierfehler auszuschließen, könnten Sie Ihre ISR auch einfügen? Es ist jedoch nicht unmöglich, dass Sie ein neues Siliziumproblem gefunden haben.
Ich kann aufgrund von Firmenproblemen usw. nicht den gesamten Code einfügen. Der Code ähnelt meinem PIC16F88-Code ( github.com/conoror/picmicro ). Ich bin aber kein Neuling bei asm :-) Ich habe wirklich versucht zu sehen, ob jemand anderes das schon einmal gesehen hat. Was ich tun werde (es muss in ein paar Tagen sein), ist, Portbits in der ISR umzuschalten, um zu sehen, wo es hinkommt, wenn überhaupt. Ich frage mich, ob Microchip Fehlerberichte (von einem Nicht-Hobbyisten) akzeptieren wird.
Ich fand Microchip immer sehr empfänglich für Fehlerberichte, wenn ich sie in der Vergangenheit wegen Compiler-Fehlern kontaktierte. Ich habe ein Konto auf ihrer Website registriert und obwohl mein Unternehmen sicherlich nicht annähernd groß genug ist, um auf ihrem „Radar“ zu sein, haben sie mich dennoch ernst genommen.
@brhans: Gut zu wissen, danke. Meine Firma besteht aus 3 Personen, also überhaupt nicht groß. Ich werde einen Logikanalysator finden, um sicherzugehen, bevor ich ihre Zeit verschwende! Ich antworte hier, wenn ich es weiß.

Antworten (1)

Das ist kein Silikonfehler. Das bin ich, ein kompletter Idiot.

Was passiert ist, dass mein UART-Code vor einem Jahr geschrieben wurde und sich auf die Tatsache stützte, dass PIR1, TXIF hoch war, wenn der UART-Sendepuffer leer war . Mein Code schaufelt Daten, auf die FSR0 zeigt, bis er auf ein "\0" trifft, und deaktiviert dann TXIE. Wenn ich also FSR lade und TXIE einstelle, werden die Daten automatisch übertragen. Ein Jahr vergeht und ich schreibe eine ISR wie folgt:

    .intr   CODE        4

    ; Enhanced Midrange CPU does a context save on:
    ; W, STATUS, BSR, FSR, PCLATH
    ; retfie restores context

    pagesel     $

    ifbset      INTCON, TMR0IF          ; Timer0
      goto      Timer0_Entry

    banksel     PIR1                    ; Bank #0
    ifbset      PIR1, TXIF              ; Serial transmit
      goto      SerialTX_Entry

    ifbset      PIR1, SSP1IF
      goto      I2C_Entry               ; I2C Peripheral

    retfie                              ; Nothing else

Nun, das ist totaler und völliger Unsinn. Wenn ein anderer Interrupt als ein Timer empfangen wird - also entweder UART oder I2C -, wird SerialTX_Entry aufgerufen. TXIF wird immer gesetzt, wenn der UART aktiviert ist und kein Zeichen zur Übertragung bereitgehalten wird. Im obigen Beispiel wird I2C_Entry also nie erreicht.

Hier gibt es eine Lektion - poste den Code! Als ich jemand anderem den ISR zeigte, sah er ihn sofort.