USART interrupt not interrupting right

[Bruce]

You always want to clear interrupt flag bits before re-enabling interrupts.
RCIF is the serial receive interrupt flag.

Since RCIF is read-only, you need to read RCREG until it's empty to clear
RCIF. You'll also want to clear any over-run conditions.

OERR VAR RCSTA.1    ' Alias USART over-run bit
CREN VAR RCSTA.4    ' Alias USART continuous receive enable bit
RCIF VAR PIR1.5	    ' Alias USART received character interrupt flag bit

Try adding this to your BASIC interrupt routine.

     DISABLE
indirizzo:
     PORTB.7 = PORTB.7 ^ 1   ' Toggle LED on entry to int handler
     IF OERR = 1 THEN   ' If over-run, then clear it
        CREN = 0   ' Disable receive
        CREN = 1   ' Re-enable & clear over-run condition
     ENDIF
     WHILE RCIF   ' If RCIF is set, then read RCREG until it's clear
        X = RCREG
     WEND
     RESUME
     ENABLE

[Morpheus]

Thank you Bruce for the answer, now the pic is interrupting, but I have a problem reading the register right..

indirizzo:

    ric = RCREG

    
    While RCIF                   'to be sure that the register'll be empty the next time I am going to read it
       	ric2=RCREG
    Wend
    
     IF OERR = 1 Then   ' If over-run, then clear it
        CREN = 0   ' Disable receive
        CREN = 1   ' Re-enable & clear over-run condition
     EndIF
     

     'print the first 3 bit of the received char on three external leds
     PORTA.0=ric.2
     PORTB.7=ric.1
     PORTB.6=ric.0
     
     
	Write 0+X,ric           'write the received byte in the eeprom
	X=X+1  

	
	
  Resume
 Enable

I am just sending to the pic a 9-bit char like this: 1 0000 0001
the 9th bit generate the interrupt, and "ric" has to be 1.
so at the end I have to read X locations of my eeprom programmed with a "01h" byte.

in the fact I have only the 40-50% of the x locations with 01, and the others has a random-like value (FF, E9, 9b, FE......).

naturally the problem is not on writing the eeprom, because the 3 external led shows that the byte is far from "01h"!!!

I can't explain why this happens, do you?

Thanks a lot
Simone.

[Bruce]

If you need the 9th bit, then simply read it from RCSTA.0 (as shown in your datasheet) before reading RCREG.

Example;

Received 9-bit data = %1 1010 0011

ric var word

ric.HighByte = RCSTA & %00000001 ' Read RCSTA bit #0 into ric bit #8
ric.LowByte = RCREG

ric now contains %0000 0001 1010 0011

[Morpheus]

sorry, I think I didn't explain myself well..

I don't need the 9th bit, it works well 'cause I need it just to interrupt the pic.
I need to read the correct address, but I don't know why the char is not always correct.

for example in 10 sended char, 10 times that the pic generates the interrupt and 10 times that i've the rcreg in the var ric. But "ric" contains only 4-5 times the char that I've sent (00000001), the other times it contains random values. The char that I've received is non the one I've sent!!!
I tryed with the "Hserin [ric]" command instead ric=RCREC, but it's the same.

I used the Usart port well without interrupt before, with the same speed (38400) and the received char was ALWAYS correct. I can't explain myself why now I've this problem!!
I took all the last night trying to solve this problem, without success.

[Bruce]

Are your data packets coming in *all together* or is there a delay between each 9-bit packet?

Are you 100% sure the transmitting device is sending 9-bit packets?

[Morpheus]

The device (pc) is sending 9-bit packet,
I am sure that it works because if I send a packet with the 9th bit =1, it interrupts, if the 9th bit is=0 it don't.

the device is sending just 1 byte for time. I just made a program that has a button. every click on this button sends a 9-bit packet to the serial port.
I can choose the byte sent, and I can choose if the 9th bit is set or nope.
I also tested it with an oscilloscope. And the 9 bits are correct.

[Bruce]

I have used 9-bit, but not for sending *all* of my packets as 9-bits.

The address is 9-bits. This issues a wake-up call to all slaves on a common serial bus by generating the hardware interrupt.

All slaves are interrupted, but only the one with the matching address responds.

The addressed slave then turns off 9-bit address detection (ADEN = 0), drops into a receive *data* routine, receives & buffers data until an EOM (end of message) marked is received.

All other slave leave 9-bit address detection ON so they will ignore all data being sent to the salve that was addressed.

Then the addressed slave re-sets back to 9-bit for auto address detection, and carries on until interrupted again.

Are you sending *all* of your data from the PC in 9-bit packets with a 1 in bit position 8? Or only the first byte, then clearing this position to 0 for the remainder of your packets?

If you are, are you clearing ADEN after the address to receive data?

[Morpheus]

Now I'm not interested on data packets. I'm just trying to address one slave, so the only thing that I'm doing is to send JUST ONE BYTE on the serial port.
This byte is the address byte. If the slave is addressed, he has to do something(to turn on a led?), otherwise he will resume.
I tried to do this, but he worked only in the 40% of the sent bytes.

So I wrote that code to save in the eeprom what char the pic was receiving. And I saw that the char was right only 40% of times.

For example:
-1st try
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0000 0001 (this is right)

-2nd try
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0110 0111 (????????? whi????)

-3rd try:
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0000 0001 (this is right)

-4th
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0100 1001 (????????? whi????)

-5th
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0011 0101 (????????? whi????)

-6th
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0111 0111 (????????? whi????)


....
and so on...
The idea of sending the data byte with only 8 bits is ok, but, for the moment I'm just testing the address detection..
But if I send 1 byte, and when I read it this is not the byte I sent, even if the ninth bit has generated the interrupt, the slave will not work because it thinks it's not addressed!!

The problem is that I'm expecting a byte in the RCREG and what I find is another one (random?). I don't know if this depends on the registers or what, but testing with an oscilloscope on the USART rx pin, the byte is right, and is just ONE! It's so strange he gives me a completely different value!

Is possible that when the pic saves the registers going in interrupt, he changes the value of the RCREG?