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\$
4
  • 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\$ Commented Jun 7, 2015 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\$ Commented Jun 7, 2015 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\$ Commented Jun 8, 2015 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\$ Commented Jun 8, 2015 at 18:53

1 Answer 1

Reset to default
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
  • 1
    \$\begingroup\$ There's a lesson here - post the code! When I showed someone else the ISR, he saw it immediately. \$\endgroup\$ Commented Jun 13, 2015 at 15:07

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.