Homemade string compare randomly fails [Solved]

[temtronic]

Hmm.. RS-232, CTS...
I've looked back at all the posts and can't find what 'RS-232' interface chip/device you're using. Does your PC actually have a DE-9 connector and a real RS-232 comport or are you using some type of USB<>serial module ?
All real UARTs will have a 16 or 64 byte buffer ,as Mr. T points out. As for a USB<>serial module,it could have 16 to 1024 byte buffer ? Will need to lookup the actual part.There's a possible 'evil issue' that the module is a counterfeit part.
Using CTS for flow control. Simple test, comment out the CTS code and see if the problem goes away. I've used CCS ex_sisr code at 115k200 through both UARTS in the 18F46K22 in series(PC->uart1->uart2->PC) and never missed a character

[PCM programmer]

This thread has gone on and on with no resolution. It's difficult to solve your
problem when we get little tidbits of information from time to time.

I would like to get a full compilable program that fails. Strip it down to essentials.

Also give a detailed description of the incoming data to the PIC.
Give the data, the baudrate, and the intervals that the messages come in at.

With that, we can either solve the problem by inspection or by setting up
a test apparatus with a 2nd PIC supplying the data to the first PIC.

[Ttelmah]

The point is that the standard way CTS works is to tell the UART driver
to stop loading characters. However characters that are already in the
hardware buffer will still transmit after this is set. UART's originally had
two characters of buffering. Later versions raised this to 16 characters,
while as Jay says some of the USB versions may have hundreds of
characters.
For myself, I'd be looking at having a serial buffer that is large enough to
cover the entire time spent processing a received sequence.(64 chars?),
Then have a counter incremented in the interrupt when a LF is received
and as soon as this increments start processing. Do not use CTS at all.
Design the code to be able to handle the worst case without stopping the
data.

[temtronic]

Found this on one of three FTDI devices.... I downloaded spec sheets for..

128 byte receive buffer and 256 byte transmit buffer utilising buffer smoothing technology to allow for high data throughput.
....

[PrinceNai]

How many commands do you need to process and how long are they? I like to parse them directly in RS232 ISR and just set up flags for the main. And fill and later clear the buffer, fill to be able to see what I have with ICD and clear later to be sure fresh data is in the buffer every time. If the behavior was the opposite (getting a false on a good string), I'd say that something was overwriting the string while you process it, but getting a true is indeed strange. I know it is a patch, not a real solution, but what would happen if you copied the string to parse somewhere else and re-test every "true" twice before you accept it?

[temtronic]

The 'Prince' brings up a great point ! In the 'dinosaur days' it was common to send just one byte as a command,which could be any of 254 commands.memory was expensive, clocks were slow(<10MHz),and Teletypes were 300 baud
When you asked to 'turn on relay4' from the 'host', it'd lookup that command in a table, say it's '41',and send that byte to the 'slave'. When the 'slave' gets the byte, it decodes what to do. With a PIC and C, you'd use the 'SWITCH' statement. You can group similar commands into 10s. '10' turns off relay1, '11' turns on relay1, '21' turns on relay2, etc.
I still use this technique to send 'on-off time information'. 24hrs can be represented in 7 bits, each is 15 minutes. Times are 8:00,8:15,8:30,9:00. This works very well for alarm systems,greenhouse controllers,etc.

[julienm]

End of the story: I received a new batch of PICs, replaced them and the failure is gone! Looks like brokers got us a batch of bad pics

[newguy]

Did you do a read of the PIC's ID and revision? Curious if the originals were an initial revision.