RS232 Receive Problem on UART

levdev · Joined: 19 May 2010 Posts: 36 Location: UK

I am having a problem with receiving a serial input. It works 99.9% of the time, but around 1 in a thousand it misreads two bytes as one. The full program has a fairly complex interface protocol and command set, but I have simplified it down to the bare minimum to demonstrate the problem. Complier version is PCWH 4.119.

temtronic · Posted: Mon Jun 27, 2011 7:33 am

quick comments

Is the serial data going through a USB<-> RS232 interface ?

Any proof it's -not- a 'Windows /PC' related problem ?

Either of these can cause a 'random glitch'.

Ttelmah · Joined: 11 Mar 2010 Posts: 19332

I disagree with what you think is happening.....

Thing to remember is that there is a start bit (a '0') in front of each byte sent, and a stop bit (a '1') after each byte. The UART does not start clocking in data, till a start bit is seen.
You are getting an extra start bit. Almost certainly from electrical noise, being seen as a '0'. This then starts the clocking in process, and so the serial line (which is sitting 'high' between the bytes), is clocked in, giving you the 'FF'.
Your problem is hardware. Something is generating a low 'spike' on the serial line into the PIC. Now, remember the serial itself is inverted, so a 'high' spike on the RS232. The spike interval, is short enough, so that at lower baud rates it is not seen as a complete bit (remember the UART performs double sampling on later chips like this).
Then the bit pattern you are seeing received, is:

2 8 3 8
00001010010011000011

The bit pattern being sent, is:

0001100001010000001

Now the '1's at the end of the byte (stop bits), are not sampled as part of the byte, so the receive, is missing the first block of 3 zeros (start, and two zero bits), and recording the next 0 as it's start bit. You will get a framing error, since when the second byte completes, the next bit is not a '1', because the receive is out of sync.

Now, missing the start bit, could be a sign that your hardware is not correctly handing the slew rate for the higher baud rates (you are aware of the cable length recommendations for these higher rates - at 56Kbaud for example, the maximum recommended cable length drops to just 10'....).
Also, is your transceiver capable of driving the slew rates needed for these speeds? - A truly RS232 compliant transceiver, _will not_ be able to handle these rates, since the RS232 limit of 30V/uSec on slew rate, has to be exceeded to work this fast....
However this would not explain the extra start bit being seen, which suggests an electrical noise problem.

Best Wishes

levdev · Joined: 19 May 2010 Posts: 36 Location: UK

Thanks for your replies. The PC output is from a comms port embedded on the motherboard not via a USB converter so I don't think this is the issue.

The 0xFF bytes are put in by me in the code, just to make the issue easier to see on the screen when it occurrs. These are not part of the error.

levdev · Joined: 19 May 2010 Posts: 36 Location: UK

Has anyone got any other ideas, I still can't get past this problem.

temtronic · Posted: Thu Jun 30, 2011 8:10 am

I see you're using the internal oscillator. Any chance you can try with a real crystal ? I know the odds are slim considering the PIC works at other , even higher baud rates, but perhaps there's an 'issue' with the internal osc and baud rate combinations ??

If the problem magically goes away...you know what to do if not...hmm..more head scratching !

Your test of PC to PC being OK is great, but those have real crystals for clocks.

'try and reply', the more info the more 'options' we might think of.

RF_Developer · Joined: 07 Feb 2011 Posts: 839

It looks likely that you are suffering from a lack of interrupt locking/critical sections :-(

When you receive characters you fill up your interrupt routine. That's great. BUT you have to make sure that when you read characters from the buffer, or most other buffer operations in main code, you ensure that the routines are atomic, in other words that they cannot be interrupted. The problem is that interrupts can happen at any time, INCLUDING right at a vital moment in your buffer reading code. The interrupt then changes the buffer pointers/counters/whatever, and your reading code gets confused. Reading the same character twice would be quite likely, or simply missing one or more out altogether.

The same happens when sending via buffers filled in main code and emptied in a transmit ISR. In that case characters can get out of order, or not be sent at all. In some cases its possible to deadlock the whole transmission process, with nothing going out at all.

To make a routine atomic, i.e. to "interrupt lock" it aka making it a critical section. You need to disable the relevant interrupt on entry, i.e. before you start using the buffer itself, and re-enable it on exit, i.e. once you've finished all buffer operations. Be careful if you're passing back a pointer to the buffer rather than a copy of the character/s. That's because you've got no guarantee that the data will still be in the buffer once you're out of the routine. Better to copy while interrupts are off, then you can turn them back on and the copy is safe from being messed with. You can turn off all interrupts, but that's a sledgehammer solution, its better to turn off only the relevant interrupt, i.e. INT_RDA for RS232 receive. Temporarily disabling the interrupts like this delays the ISR, you wont lose interrupts. BUT its important the critical section is as short as practical. Just read the buffer and re-enable interrupts asap.

Another possibility is that you are using the internal oscillator, which has relatively poor accuracy compared to a crystal. This will be adding to the inaccuracy of the baud rate and may be causing it to go out of the +/-3% rs232c spec. Baudrate with lower inherent error will work better...