I wish I knew a Microchip rep...

[newguy]

...so that I could shove this 18F4610 right up his you know what.

I have a device I'm developing. Very complicated, lots of code, can't post it here either. Uses an 18F4610.

My tried & true interrupt driven USART code (can be found here: http://www.ccsinfo.com/forum/viewtopic.php?t=22221&highlight=intrda) works for receive on this pile of crap processor. The transmit doesn't. By the way, if I try the same code on an 18F452, it works flawlessly. Unfortunately, I can't use an 18F452 because I need the extra memory of the 4610.

Anyway, it does work for a very short period of time, then it gives up the ghost and stops transmitting. I've read the errata sheets for the 4610, and they acknowledge a problem when using the EUSART in 9 bit mode, but I'm not using that mode, only the regular old 8 bit.

It's like it works for a few bytes, but if I transmit many in rapid succession, phht. It just stops.

The errata sheets say something about this problem in 9 bit mode screwing up the baud rate generator. I know this isn't the case because the thing keeps receiving long after the transmit is lost, so it seems that maybe this is a new problem.

Argh. Anyone know what my next move should be? Do I contact Microchip or CCS or both?

I hate spending 12+ hours chasing a problem not of my own making.

[asmallri]

Your code modifies the same variables both inside and ouside of the interrupt handlers. When doing this you need to disable the corresponding interrupt in the mainline. Remember that the PIC can be interrupted inside a single c statement as the statement may produce mutiple assembler instructions. The same applies, abeit to a lesser extent, when testing variables that are modified in the interrupt handler. For this reason your code has race conditions that could cause the effects you are observing.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[PCM programmer]

I looked at the code in your link. I see a problem with the receive
interrupt routine. You're setting a flag if you receive one character.
Then in your main loop, you poll this flag and increment a counter.
But this defeats the whole purpose of an interrrupt-driven receive fifo.
You are forced to poll this flag at a rate faster than 960 Hz, or you'll
miss characters. Suppose 5 bytes come in rapid fire. Suppose you
can't poll your flag in the main loop for a while, because you're
sending chars to your LCD routine which has delays in it, or for
some other reason. Then
your main loop will increment your count by 1, but you really have
5 bytes in the buffer.
Ideally, you should have a counter inside the isr, or do it the way CCS
does it and only fetch chars if the head and tail indexes don't match.

I think you should take out those routines from your current code,
and substitute the CCS code from EX_SISR.C and EX_STISR.C.
I know you said it runs on an 18F452. I would try it anyway.

[ckielstra]

Andrew is right about the race conditions in the transmit functions, especially the manipulation of tx_counter in both the isr and bputc() is very dangerous.

Why do you disable the Tx interrupt when you are finished sending all data? Enable it once at program startup and leave it like that and your code will become smaller, faster and you remove one of the race conditions in doing so.

[Mark]

[Neutone]

[Mark]

Beat ya to it

[ckielstra]

Thanks Mark and Neutone!
My current RS-232 routines only use the Rx interrupt, good to know the Tx is different in this respect.

[newguy]

[asmallri]

[newguy]