PIC18F46k22 serial reception interrupt not triggering

[bob7185]

Hello everybody , I m currently working on a project where I am interfacing a pic18F46K22 to a sim900 module , problem is I cannot even get the interrupt routine for serial reception working  I m using mplab and XC8 v 1.45  ,  serial interrupt is not triggering, below is a picture of my isr and main Any suggestions help is welcome

[voltsandjolts]

Is the RX pin setup to be an input?

[bob7185]

Is the RX pin setup to be an input?

Yes it is

[voltsandjolts]

Are you sure the interrupt doesn't fire (debugger?) or do you say that because the LCD doesn't show a char?
Maybe just sending some chars first, then echo all received chars, then add in LCD stuff.

[bob7185]

it doesn't fire at all , I have the debugger hooked up to proteus for hardware simulation, and set up a breakpoint in the isr

[amyk]

Have you checked the errata?

[chris_leyson]

Maybe RC1IF is stuck at "1". From what I can see in the data sheet the only way to clear RC1IF is to read the receive buffer RCREG1. Also, if there is a responce to the interrupt then the GIE bit is cleared and has to be set at the end of the interrupt routine. It's been a while since I had to poll interrupt flag bits. I would check the INTCON and PIR1 registers.

[JPortici]

do you have a debugger? check what happens after you receive one message.

a number of potential issues:
-RC1IE and RC1IF: how are they defined? mid-button click on them and check if they correspond to the CORRECT pin. I had ton of headaches with the K42 because the include files were INCORRECT. the RC1IF and RC1IE bits  are defined in multiple PIR and PIE registers, because the include files have a lot of legacy crap on them. opened a ticket a couple of versions ago, they haven't fixed it yet.
-RX overflow. if the UART is in a RX overflow condition, it will stop receiving data and won't generate any more interrutps. to resume operation, switch off and on the receiver by using the CREN bit. I doubt it's your case since it seems you never enter the interrupt routine.
-High priority interrupts are incorrectly configured or you didn't write the code correctly. Try to disable prioritized interrupts for now

[bob7185]

  Thanks everybody for the tips .  I finally  figured the issue , it is with the baudrate, when using  the pic internal oscillator , the baudrates generated are not precise , for instance I was using the internal oscillator at a frequency of 8MHz , with a value of SPBRGx=51 according to the datasheet the baudrate generated is 9615 bps instead of 9600 bps  with a 0.16 % of error ,configuring the proteus virtual terminal at  the same baudrate fixes the issue. I m opting for a 11.0592 MHz for the prototype.

[TomS_]

the baudrate generated is 9615 bps instead of 9600 bps  with a 0.16 % of error

As I understand it, UART should be able to handle 2-3% error. In real life you would probably find this works just fine. You dont need a clock that cleanly divides down to an exact baud rate as a result of this.

Sounds more like Proteus is the issue.

[NorthGuy]

I m opting for a 11.0592 MHz for the prototype.

HFINTOSC in your PIC has 2% accuracy at 25C. UART requires 2.5% accuracy. More precisely, the difference between sender and receiver should be 5% or less. So, there's no need for a crystal for UART operations.

Besides, even if your baud rate is way off (like several times off), you will still receive something (which will look like a garbage). If you receive nothing, you haven't even got to the point where baud rate matters.

[bob7185]

 

the baudrate generated is 9615 bps instead of 9600 bps  with a 0.16 % of error

As I understand it, UART should be able to handle 2-3% error. In real life you would probably find this works just fine. You dont need a clock that cleanly divides down to an exact baud rate as a result of this.

Sounds more like Proteus is the issue.

Thanks TOMS_ I kind of suspected that. I' ll build the circuit in the next couple of days.I ' ll let you guys know if I have any issues

[bob7185]

I have built the circuit and  everything is working just fine , I am using the pic internal oscillator and serial communication is working like a charm , seems like issue was with proteus as  many users have pointed out