18F4685 USART IRQ Problem

[JamesW, Kent, England]

Hi Folks,

Why do I always get the weird problems??

I have a 18F4685 that is communicating with a wireless receiver device (also by co-incidence a PIC).

Basically I lower a wake pin on the processor, send a command to the device and receive either

<ACK> or <NAK>

so simple it's untrue!

However after 2 days of head scratching I've got to ask for help.

I have another pc monitoring the receive line via a max232 so I can verify that the processor is getting the data OK.

Using the standard CCS int_rda example I do not receive all the data from the wireless device, my usart buffer contains the first 2 characters and nothing else.


This code does not work

/* TURN ON INTERRUPTS */
enable_interrupts(GLOBAL);
enable_interrupts(INT_RDA);


for(;;)
{

if (COM1_kbhit)
{
printf(lcd_putc,"%c", COM1_bgetc());

}

}

I get about 2 characters

However - if I do not use interrupts. I can receive the entire message

This example works fine..

for(;;)

if (bit_test(USART_PIR1, 5))
{
Response[ResponsePosition++] = getc();
if (ResponsePosition == 5)
{
goto ExitLoop2;
}
}
ExitLoop2

This has got me completely perplexed, I've been thumbing through the microchip datasheet and got the above example working.

Using the ICD-2 debugger I can examine the registers and strangely some do not agree with what I think they should from the datasheet.

(I am running at 20MHZ and need a 9600 baud)

TXSTA = 0xA6
RCSTA = 0x90
BAUDCON = 0x00
SPBRG = 0 (This seems strange!)

Compiler version 4.073



I know that the receive interrupt code example dates back to the 16C74 days, is there something else I should be doing

Thanks

James

[FvM]

I'm unable to recognize what's valid code in your post. Your enabling INT_RDA, but there's no #INT_RDA interrupt service routine. Please post a complete example to make the problem understandable.

[dyeatman]

And also use the CODE button for your code to make it readable...

Offhand it sounds like a buffer overrun to me. When we see the code it will be clearer.

[asmallri]

[Guest]

Ahh - that code button, I've been looking for how do to that!!!!

[dyeatman]

At first glance your Int_RDA and handling buffer routines look basically OK .

The entire COM1_Initialize routine can be replaced with this line at the beginning of your program:

[JamesW, Kent, England]

Cheers for the pointers.

I normally use the #USE RS232 line, but when I encountered the problems I started clutching at straws thinking that maybe the initialisation routines were playing up.

The memset is there purely to make it easier to use the debugger to find any data located in the buffer.

I've been delving a little deeper in this.

I have written the routine above that "works" into the code using a counter coming off the timer interrupt to exit the loop. - but this should really be working as an IRQ and seems like a complete bodge.

I have come to the following hypotheses.

1) The usart itself is working fine, as by polling the PIR register for the "I have a character in the RX buffer! I see data and a complete packet.
2) The first interrupt works fine, it is interrupts later on in the data stream that are causing problems or being missed. This at least proves that the compiler is locating the interrupt handler in the right place, and off the right interrupt.

Therefore I "think" that there must be something that needs clearing/reseting in the IRQ service routine that is preventing it handling things correctly. I would normally assume that this is being done automatically by the compiler, but maybe not for the 18F processor.

I've been using the #USE_RS232 and the above interrupt service routine on various processors since about 1997 without a problem.
(Well nothing like this anyway!)

This may well link in with my other post about receive issues when using an 18F device in i2C slave mode.

What should be cleared when servicing an RS232 receive interrupt?

Thanks in advance

James

[Ttelmah]

I'd try changing your buffer size.
I have warned in the past about this.
You buffer size should _either_ be a 'binary' value (16, 32, 64 bytes), or you should re-code the ISR as:

[FvM]

I think, the %40 operation, although time consuming, shouldn't be an issue at 9600 baud. I rather expect, that some considerably long interrupt disable occurs during lcd_putc(). But both assumptions should be checked.

[JamesW, Kent, England]

I will give the buffer size change a try tomorrow morning.

The lcd_putc was put there purely for debug purposes. The original routine consisted of using kbhit to dump the characters in an array until a '>' (end of packet) character was found or a timeout occurred.

I've been reading from the microchip datasheet again. Does the interrupt priority have any effect on this (not that there are any other interrupts enabled at the moment)???

According to the datasheet, reading from the usart clears the IRQ automatically (it seems to be read only)- I'll check that this is clear as well and get back to you.

Cheers

James

[dyeatman]

Using either getc() or reading the UART recv register directly clears the interrupt. Since you are using just one interrupt the priority makes no difference.

The inclusion of the ERRORS at the end of the #USE_RS232 line is designed to take care of any overrun errors that are encountered and is the likely culprit in my opinion. If the data source is slightly off baud rate wise it will definitely cause a problem.

[JamesW, Kent, England]

Well I'll damned!

Changing the buffer size to 64 and removing the ERRORS declaration has made it work!

Looking at the datasheet a baud rate of 9600 at 20MHz gives an error of about 1.7%

THANKS CHAPS!!!!!

One more small question, now I am not using the ERRORS directive - should I be checking any bits of the usart for errors?

Thanks again

James

[Ttelmah]

If you want to clear errors, use: