2
\$\begingroup\$

I'm using a PIC16F1825 mid range PIC and I've used it with a UART and SPI for a good while without issues. When I added code to handle I2C (instead of SPI - it's either one or the other on this PIC) I ran into problems with not receiving the I2C interrupt - thus SCL would remain stretched forever.

After some considerable debugging I figured out that removing the code that activated the serial port fixed the issue - the I2C ISR gets called and acts normally.

All I'm doing in the serial init is setting SPBRG and then:

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

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

That it. No interrupts are enabled (I just set the flag on transmit)

I've searched the docs and the errata and find no hint that enabling the serial port would mangle I2C functionality like this. Is this my misunderstanding or there an actual silicon bug here?

\$\endgroup\$
  • 1
    \$\begingroup\$ I don't see this listed in the errata for the device. To rule out a programming bug could you paste your ISR too? It's not impossible you found a new silicon issue though. \$\endgroup\$ – David Jun 7 '15 at 22:54
  • \$\begingroup\$ I can't paste the entire code due to company issues etc. The code is similar to my PIC16F88 code (github.com/conoror/picmicro). I'm not a newbie at asm though :-) I was really trying to see if anyone else had seen this before. What I'll do (it'll have to be in a few days) is toggle port bits in the ISR to see where it gets to, if anywhere. I wonder will Microchip accept bug reports (from a non-hobbyist). \$\endgroup\$ – carveone Jun 7 '15 at 23:30
  • \$\begingroup\$ I've always found Microchip to be very receptive of bug reports when I contacted them with compiler bugs in the past. I have an account registered on their site and although my company is certainly not anywhere near big enough to be on their 'radar', they've still taken me seriously. \$\endgroup\$ – brhans Jun 8 '15 at 12:34
  • \$\begingroup\$ @brhans: Good to know, thanks. My company is 3 people so not big at all. I'm going to find a logic analyser to make sure before wasting their time though! I'll put an answer here when I find out. \$\endgroup\$ – carveone Jun 8 '15 at 18:53
0
\$\begingroup\$

This is not a silicon bug. This is me being a complete idiot.

What is happening is that my uart code was written a year ago and relied on the fact that PIR1, TXIF was high if the UART transmit buffer was empty. My code shovels data pointed to by FSR0 until it hits a "\0" and then disables TXIE. Thus when I load FSR and set TXIE, the data is automatically transmitted A year passes and I write an ISR like this:

    .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

Well that's total and utter nonsense. If any interrupt is received other than a timer one - so either UART or I2C, the SerialTX_Entry will be called. TXIF is always set if the UART is enabled and no character is beng held for transmission. So in the above example, I2C_Entry will never be reached.

\$\endgroup\$
  • 1
    \$\begingroup\$ There's a lesson here - post the code! When I showed someone else the ISR, he saw it immediately. \$\endgroup\$ – carveone Jun 13 '15 at 15:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.