Made Sticky for users that originally missed this code. I've noticed over the years that a lot of people struggle getting to grips with the timing of RS232 coms.

• Simple Serial Protocol
• Serial Interface Protocols

And as soon as a serial buffer is mentioned, a panic sets in because that means the dreaded 'Interrupts' need to be implemented. So here's a piece of code that may help overcome some of the problems. It replaces the compiler's HSERIN and HRSIN commands with an interrupt driven serial buffered version (with and without timeouts) that is, essentially, invisible to the user. Note that this code is for the 18F range of devices only.

The serial buffer is filled when bytes are received from the USART, so when the HSERIN or HRSIN command is issued, you're actually reading from the buffer and not the hardware USART. It works extremely well and I've used it many times in my projects. The buffer's size can be up to 255 bytes in length and is altered by changing the line of code:- RESERVERAM 100 Located at line 38 of the BUFFEREDHSERIN.INC file. I've also attached a demonstration program that shows the buffer's operation. A bit later I will add to the code, stuff like how much data is in the buffer and a wait for command so it only starts stuffing the buffer once the chars your looking for arrive.

Also will had indicate data in on X so it will say when a chr 13 has arrived etc. Whole point of the buffer is not having to wait in a loop for the data. Just check a couple of flags to say a whole packet waiting for you or else get on with the other jobs. One small possible niggle, Tim. If receiving binary data, 'Chr13' might occur at any point within the required data stream, and would therefor not be an end of data marker.

You might require some method of indicating whether data to be received is binary, or text (printable characters). Optional fixed length data packet, perhaps? Or just flag data is available, do with it what you will? Glad you liked the code. I know it will come in handy as it has for me on several occasions. The way it's laid out means that several extras can be easily added. One flavour I added for a project was to examine and remove characters from the serial stream before they could be placed in the buffer.

Which saved me parsing them out later. LF (Line Feed) and CR (Cariage Return). I removed the LF and also changed spaces to commas etc. Bill: The RESERVERAM text IS already a declare so it would be rather strange to add another declare changing an existing declare. You don't have to reserve RAM at the top of memory for the buffer, it's just more convenient that way.

With a slight change of code, the buffer could be a conventional byte array, but it should be placed, out of the way, at the end of the DIM list, because it is accessed indirectly, so doesn't need any RAM bank switches etc. Bill: The RESERVERAM text IS already a declare so it would be rather strange to add another declare changing an existing declare. You don't have to reserve RAM at the top of memory for the buffer, it's just more convenient that way.

With a slight change of code, the buffer could be a conventional byte array, but it should be placed, out of the way, at the end of the DIM list, because it is accessed indirectly, so doesn't need any RAM bank switches etc. Ok Les.I appreciate that RESERVERAM is a declaration, but for whatever reason, brain kept slipping a cog and went into a perpetual REPEAT loop on trying to work out how to use the include file for two different projects being worked on at the same time and which might require different amounts of reserved space for the routine, UNTIL Bobby, RGV, pointed out that the declaration could be taken outwith the inc file and used in the main program. Think I need a holiday. Thanks again Les. Bill I think you would have figured this out already but you would not enable a feature that was not want you wanted. You would only turn on the requirement if you wanted to wait for a chr13.

Like I said Tim. I'm definitely in need of a holiday.

Quick question. I tried to use the buffer code in an old program of my own.

I get the following error when I try to compile same. Symbol not previously defined(INSIDELOOPINTHH) Program compiles OK when include file not used. My program extensively uses PortB hardware interrupts, which are enabled and disabled throughout the program, sometimes using GIE to do so. Compiler is up to date, Pre-compiler is off, Optimisation level set to max, and appropriate declarations carried from sample program to my program.

Program code is way too long to post. However, can you, or Tim, or anyone else for that matter give me some indication of possible cause of the problem.

The only error report is the one given above. This is repeated about 4 times. Your example code compiles flawlessly. Hi Les: Thanks much for posting the serial port code.

When I read through it I was reminded of a question that keeps popping up for me, and that is what do certain directives do? For example (the last is from this code you posted), 1.

BYTEMATH ON/OFF 2. UNSIGNEDDWORDS ON/OFF 3. SMALLMICROMODEL (forum search today does not show anything, but a google search does reveal some forum entries that are helpful) I can guess about #1, #2 allows use of either signed or unsigned dwords, and #3 must product more compact code? As I see that you and other very experienced coders here in these forums sometimes uses directives like this (and others I have not listed), but I have not been able to find their definitions in the product documentation. Am I looking in the wrong place, or must I petition to join a Secret Coders Society to find out these and other secrets?

Reading the new version release notes sometimes documents things that are not otherwise found. Perhaps a 'Sticky note' at the top of the forum could be a repository for definitions/directives like these that are in the compiler but were not originally intended for public use, or directives that have been added.

Or, perhaps another sub forum could just be used to document compiler additions/features that are not in the help files, printed manual, or pdf manual. Just a thought.

Simple Serial Protocol

Rocky Thanks. I have added another command to Les's inc file. The command returns the number of BYTES currently held in the buffer - useful for checking to see if there is anything to read prior to calling HrsIn. The command is called 'HrsInBuffLen' usage is as follows: DIM numofcharsinbuffer as BYTE numofcharsinbuffer= HrsInBuffLen this is the first time I've done a macro - I used the Wizard - but I expect someone will be able to correct any mistakes I may have made. It seems to work fine for me though even with different buffer lengths. This is a reminder that some 18F chips have an issue with RETFIE FAST that is explained in their errata sheets. For example, the 18F8722 (dual comports) says: If any two-cycle instruction is used to modify the WREG, BSR or STATUS register, do not use the RETFIE FAST instruction to return from the interrupt.

Instead, save and then restore WREG, BSR and STATUS via software as shown: ISR @ 0x0008 CALL Foo, FAST; store current value of WREG, BSR, STATUS for a second time Foo: POP; clears return address of Foo call:; insert high priority ISR code here: RETFIE FAST Perhaps someone might want to comment further on this. Les, Aside from eliminating the interrupt priority (and reduced RAM size), is there any reason this won't work with 16F's?

Have you had the need to make a buffer on the other side, to buffer HRSOUT? That would allow the command to load the buffer and code to continue, instead of waiting for the usart. You can do this kind of stuff on a 16F device, but have you thought about maybe using an 18F part instead? The price difference is negligible and the 18F devices are so much easier to work with - especially if you want to access tables or blocks of data held within the code space. The method by which this has to be implemented on the 14-bit cores is a bit bananas and makes you wonder what the folks at Microchip were smoking that day.:rolleyes.

On top of that, there are numerous applications where you might not want your PIC as large as an 18 pin device. I think the most difficult thing about implementing an interrupt handler within Proton is making sure that you don't clobber any of its workspace. The obvious thing to do is to use assembly language, but then you have the problem of switching banks to access any required variables and arrays (this is pretty much irrelevant on the 18F parts because of the MOVFF and LFSR instructions.) Something tells me that there are macros which you can use in your asm to switch over to whatever bank a variable is located in, but I can't remember any details.:confused. Hi, I am using the invisible RS232 Serial buffering code in a data logger application together with SD/MMC card library.

In addition, besides running unattend (remote locations), the application is meant to run with a PC host program via RS232/RS422. The host program polls the data logger hardware every second for data sets. I am using a 18F6722, 20 MHz. The data logger uses the EEPROM for some internal tracking issues, i.e. Writes once a minute a byte and a dword to the EEPROM. When I started testing the setup for extended periods I've notized that after a couple of hours (12 - 24 h) the total EEPROM was overwriten (which in addition to the tracking variables holds some constants for calculating physical values from AD readings as well as a serial number and other house keeping data).

I've switched to the beta compiler for better interupt handling (especially saving of system variables). Since Friday the system runs flawless. What I did was to switch of interrupts (clearing GIE) at times when the PIC was writting the EEPROM. The 18F6722 manual states that its strongly recommended to switch of interrupts during EEPROM write operations. If I understand the assembler produced by the compiler right that is not happening (at least not in the EEPROM write routine).

I assume that an interrupt event during the EEPROM write routine leaves the PIC after the return sometimes (not always) in an undefined state (?). Any other idea would be appreciated. My other concern is: Are there other routines which require absolut hardware access which I did not find up to now (for example writting the MMC card)?

Greetings, Michael. Not fully correct in answer to your post but. You do need to think about interrupts and eeprom writting and I as a matter of cause I turn off interrupts before doing so.

However 5ms which is the average write time is a long time and you could miss chars coming in via USART. The solution is to time your eeprom writes in between the data packets. If your receiving set packets of data then set the eeprom write to occur when you see the whole packet has arrived. There are no other issues that I am aware of that are effected like the Eeprom in relation to being interrupted (hardware wise) One last thing writing to Eeprom every 5 mins will mean that you may have burned out the Eeprom in less than a year.

Something to think about. Hi Tim, thanks for the answer. To clarify things: first of all, the host program requests are coming asynchronous and not predictable. For example: 'Send me data', 'Send me your current RTC time' etc. In between, the host program user might request something. So, no way in predicting whats and when requests are coming. For writing the EEPROM: I am not writing the same cells every minute but instead use a range from $200 - $3FF.

Where I change cells every minute. What I've meant with potential other issues: The SD/MMC card library uses either the hardwaer SPI port or a software SPI solution. Thats something which might be affected. The other one is the second RS232 in the 18F6722.

I am using that to listen to the output of a GPS modul and determine time, date and position. Is that affected? Greetings, Michael. Hi senacharim, so, what you are saying is to switch off interrupt handling all together? The implementation right now is in a way that the host program sends the requests and the hidden buffer system the PIC handles the outside requests when its idle.

Tim: I agree with what you are saying about SPI. I guess the same holds for I2C, cause its also clock driven. Greetings, Michael If you're using an 18 series pic, it has a 2byte deep hardware fifo buffer. The interrupt flags are queryable, so as long as you regularly query the bit indicating whether or not the uart buffer is empty, you should have no need of interrupts for what you've described. Hi Tim Can I disable interrupt in the main code then enable it again as follows? From Les INITUSARTINTERRUPT MACRO INTCON =%11000000 ' Enable global and peripheral interrupts Data Recieve From Main Code INTCON =%00000000 ' Disable global and peripheral interrupts Do something From Main Code INTCON =%11000000 ' Enable global and peripheral interrupts Again wait for data Hi rcurl Yes that was a good advice. I googled the net and I found a circuit for autodirection.

It use a transistor and a few resistor. The second one use a 555IC configured as monostable. Hi yes you can However with the 485 coms set to output only then no interrupts should occur any case. I think I got your point. If 485 is set to output then incoming data is block. In that way the pic is free for any task. Is that correct?

Another question. I setup another rs communication on another pin for the serial GLCD. ' USART DECLARE Declare HSERIALBAUD = 115200 ' Set baud rate to 9600,00 Declare HSERIALRCSTA =%10010000 ' Enable serial port and continuous receive Declare HSERIALTXSTA =%00100100 ' Enable transmit and asynchronous mode Declare HSERIALCLEAR = On ' Enable Error clearing on received characters ' GLCD Printing Declare RSOUTPIN PORTB.4 Declare RSOUTMODE 0 Declare SERIALBAUD 9600 Declare RSOUTPACE 200. USART PIN for 18f2620 TX portc.6 RX portc.7 Speed 115200 RSOUT PIN PORTB.4 Speed 9600 Yes TIM I am aware about the critical time of bit banged coms, it happened to me in one of my project. That is why I want to disable the interup while sending data to GLCD.

As you said when the 485 is set to output no interrupt should occur, then that time I can send data to the GLCD. Or I can just tied the GLCD to tx (RC6) and set the address and set the baud of 485. Anyway I have to send only 1 character to GLCD. If 1 sent to GLCD = GLCD will print a logo 2 = GLCD will make animation 3 = GLCD will print 'Hello WORLD' 4. All the printing will be done by the onboad PIC of the GLCD. I think that is the best way and I can free 1 precious pin.

Hi everyone, i'm using Les's serial buffer for debbuging and it works great! But like dolci i'd like to be able to use this code with the max485 drivers,i tried to thing about toggling port RB0 on the 18f1320 for example (a 10mhz 19200bds) i'll try to do some coding after i make the board and see what's happening when i just put something like: high portb.0 HRSOut Bytein low portb.0 etc. Hope that works, i'm really not familiar with interrups i've done only one soft with it. Anyways thank you for your great code!

Has anyone tried porting Les' code to a 18F6720? I have it working fine on an 18F4610, but it crashes on the 6720. It appears that everything is working except the interrupt isn't being recognized. I tried adding the 1 suffix to denote USART #1 but that either doesn't compile or doesn't work.

I also tried changing the PIE1 to PIE3 and the IPR1 to IPR3 thinking it might be that I was actually using USART #2. This has no effect either. I am truly confused where to go from here after reading both data sheets to see what may be different. I have an LED trap in the 'USARTHIGHPRIORINTERRUPT' routine to see whether the interrupt is actually calling the routine. It appears that the interrupt is not being called at all. I hate calling out for help without thinking I exhausted my ability, but I feel that this is a simple error that I can't see; you know the old 'Forest for the Trees' adage.

Joe Giardina.I am truly confused where to go from here after reading both data sheets to see what may be different. Joe, open up both datasheets. Take the code with the working PIC, and read every datasheet section of it that discusses every register setting, until you understand what the settings do. Ask here for verification if you are unsure-but as a last resort. (Otherwise you may not learn.) Then look at the new pic ds. Find the section that covers the same topic, and find where that setting is made.

It is simple. But sometimes it is not easy. Many times a hobbyist is intimidated by reading the ds, but this just limits their capabilities. As a broad generalization, it's what separates the engineers from the wannabees. (But that doesn't mean an engineer will grasp it without a little assistance occasionally!). Joe, open up both datasheets.

Take the code with the working PIC, and read every datasheet section of it that discusses every register setting, until you understand what the settings do. Ask here for verification if you are unsure-but as a last resort. (Otherwise you may not learn.) Then look at the new pic ds. Find the section that covers the same topic, and find where that setting is made. It is simple. But sometimes it is not easy.

Many times a hobbyist is intimidated by reading the ds, but this just limits their capabilities. As a broad generalization, it's what separates the engineers from the wannabees. (But that doesn't mean an engineer will grasp it without a little assistance occasionally!) I already reviewed both data sheets with no luck egro my call for help. After a break and reading eveyone's posts, I decided to start from the beginning and check everything.

Turns out the Rx and Tx lines were reversed, changed them and all works fine. Thanks for all the assistance. Tim / Les referring to 'A bit later I will add to the code, stuff like how much data is in the buffer and a wait for command so it only starts stuffing the buffer once the chars your looking for arrive. Also will had indicate data in on X so it will say when a chr 13 has arrived etc. Whole point of the buffer is not having to wait in a loop for the data.' Does this exist yet? If not, how can I read the current buffer pointer in my program.

It seemed like a simple task, but I am not getting sensible results. Thanks for the code to date. I'm using an 18F4550 running flat out at 48MHz. The PIC seems to be losing bytes, but this is quite a complex system and one part of the project is fixed at this speed, so I can't just slow everything down and test at different speeds to see if this is a speed problem or something else, so I'm looking for sections of the project to rule out as causing issues.

As long as I don't overflow the buffer (currently set at 100 bytes), do people think that it should be capable of managing the serial interface at 115200 baud without dropping bytes? I've used this code is many slower speed projects and it's been faultless. Post your code so we can see I've never used an include file before, so it is possible there is a simple syntax type error. Symbol IPEN = RCON.7 ' Interrupt Priority Enable bit Symbol TMR1IP = IPR1.0 ' TMR1 Overflow Interrupt Priority bit Symbol TMR1IF = PIR1.0 ' TMR1 Overflow Interrupt Flag bit Symbol TMR1IE = PIE1.0 ' TMR1 Overflow Interrupt Enable Symbol GIEL = INTCON.6 ' Peripheral Interrupt Enable bit Initialisation for low priority interrupt: IPEN = 1 ' Enable priority interrupts. TMR1IP = 0 ' Set Timer1 as a low priority interrupt source TMR1IF = 0 ' Clear the Timer1 interrupt flag TMR1IE = 1 ' Enable Timer1 interrupts TMR1ON = 1 IntsOn Read the manual over and over and with the Proton help too, Thanks Tim.

Any reply on the other query regarding the peeking into the serial buffer? It would seem I have a problem.at first I thought everything was ok, but then I started getting lock ups or what appeared to be lock ups. I seem to be missing the first byte of data transmitted and this seems to be quite repeatable.

I have checked the PC transmitting the data by connecting to another PC and verifyig that the data is indeed being sent. I am using a high priority interrupt for the serial comms and a low priority interrupt for a MS timer. I've modified the macros IntsOff and IntsOn to disable both interrupts and enable both: $define IntsOff While GIEL = 1: GIEL = 0: Wend: While GIEH = 1: GIEH = 0: Wend $define IntsOn GIEH = 1: GIEL = 1 In my main program loop I do the following: MAIN: ' Disable interrupts IntsOff ' How many bytes in the serial buffer?

I've fixed it, but I've no idea why? I put some debug info inside the loop that calls HSRIn, and found that with the Print At statements in the loop, it always works and never misses the start byte. So I removed the debug print statements and sure enough the fault was back, so I changed the code to: While USARTINDEXIN USARTINDEXOUT ' Transfer everything buffered from the serial port into our packet buffer HRSIn bytChar aryBufferbytNextIdx = bytChar ' No idea why, but without this we miss the first character DelayMS 1 Inc bytNextIdx If bytNextIdx = SINBUFFERSIZE Then Clear aryBuffer bytNextIdx = 0 EndIf Set bitCheckBuffer Wend With the 1 ms delay it works everytime, without the delay it always misses the first character.

I am using 57600 baud. I've fixed it, but I've no idea why? I put some debug info inside the loop that calls HSRIn, and found that with the Print At statements in the loop, it always works and never misses the start byte.

With the 1 ms delay it works everytime, without the delay it always misses the first character. I am using 57600 baud.

Your post was while I was on vacation so I didn't see it until now - That is very interesting, I regularly loose the first two bytes - fortunately always the same chars - and I'm running at 115,000 baud. I just created a routine to try and simulate the WAIT modifier, but I am unable to catch the String I am searching for. Problem is that my Serial Input is a dump from another device and it's a whole page of data (more than 100 lines), and I am trying to catch some data and read it which is in the early part of the dump. But the early data in the buffer is being overwritten by the data received later, and I do not want to create a very large buffer as I only read this once during the bootup sequence and am only interested in about 15 characters in total, in fact I am trying to grab the device's IP address from the page dump. I am able to catch the data I need using the normal Hserin command, however I need the buffer elsewhere in the program and I believe that you cannot switch between the normal hserin and the buffer hserin? So as I cannot store the entire page into a buffer, I need to try and read it in real time, and every time I see a Carriage Return I clear the buffer and read in that line before the buffer fills up.

Hello Pete, Have try to count the UART Frame or Overrun? You can sincronyze the buffer inside the interrupt routine with a semafor flag and a temp Variable.

If there is not a StarChr in the UART the buffer do not start. I write an example, I don't text it. I've fixed it, but I've no idea why? With the 1 ms delay it works everytime, without the delay it always misses the first character. I am using 57600 baud.

I could use some insight. I have a bug that seams identical to Sy's except that it is always the first two bytes that are corrupted after I transmit out using HRSout. The first received byte is always the same as the last transmitted byte and the second byte seams to always be a '7B' see below 6 7B 1 2 3 4 5 6. I understand why the Received bytes get corrupted, or rather how to prevent it. I was setting up the EUSART registers every time I entered my RS232 Transmit subroutine. If I move those lines to the start of the program the problem is gone. That is strange behavior.

There is a tiny bug in the BUFFEREDUSART.inc file: Under the error handling section inside the interrupt, it traps on two errors but only handles one of them. Movlw 6 ' Yes. So Mask out unwanted bits andwf RCSTA,W ' Check for errors bnz UARTERROR ' Was either error status bit set?

Bit 2 FERR: Framing Error bit 1 = Framing error (can be updated by reading RCREG register and receiving next valid byte) 0 = No framing error bit 1 OERR: Overrun Error bit 1 = Overrun error (can be cleared by clearing bit CREN) 0 = No overrun error Adding a ‘movf RCREG” inside the error handling section will clear the framing if necessary UARTERROR: movf RCREG ' Clear Framing error by reading RCREG Clear RCSTA.4 ' Clear receiver status Set RCSTA.4 retfie Fast Alan R. Still hoping for some help on the timeout value.;) But a new issue came up. We're using a 512 byte boot loader now, using RCREG commands for input to save space.

The boot loader works great. But is there a way to use the buffered HSRIN for the main program without using it for the boot loader? It takes too much space for the boot loader. I'm using a modified version of the serial buffer modified by Tim for the buffer. Attached find it for convenience. This great transparent buffer works really well.

I'm using it at 115,200bps on a 18F550 and never misses a character. Thanks Les & Tim. Now I have a problem; if I introduce into the program an RB0 interrupt section, the program no longer works.

Of course the program that handles the interrupt RB0, without transparent serial buffer, works perfectly. Follow the non working RB0 interrupt, with transparent buffer. Hi I am new to the forum, but reasonable at the PIC and Proton basic. The project is a 4-digit multiplexed LED display that is updated asyncronously (a button on the transmitter sends up to six bytes, ending in CR). I have the LEDs working, displaying data from a (fixed) buffer. I have tried the hardware without the LED display using HSerin and HSerout in a loop to prove the hardware, and that is fine, what comes in goes out (displayed on a PC). Serial HSERIN in the main loop is not an option because of the multiplexing of the LEDs, but I am not having much luck in the interrupt department.

Scanning the forum showed up the Invisible RS232 from the wiki, and tried inserting this into my project, but I have some problems: a) how do I call the modules - e.g InitUSART: b) how do I know a string/character is available? C) how do I get the string/character into my display buffer? Sorry about all the questions, but I have tried all the obvious routes (except the one that works, of course) Cheers Tony.

I have my PROTON+ forgetted in the toolbox. As somebody in this forum knows i'm a hobbist. My last project developed with Proton+ was this: It read a data stream from PC and uses the powerfull BUFFEREDHSERIN.INC.

If anybody is interested in proton's code i can post it, and if anybody wants to write a wiki article in correct english i can try to write my special english version. Regards Mario Lester. Can you fix this post. I don't know what happened. It appears the first and i guess that it must appears the last:).

The SIM is RFactor and the PC Software used is PD Display 2.0. To connect with RFactor, this program uses the RFactorPlugin. (I guess that last version of PDDisplay support RS232 comunication. This program read some telemetry data from Sim and send it throught a RS232 port. I'm in work now and i don't remember, but if it is in your interest, i would post the data format later.

I am Pflanzgarten in YouTube and the video that i posted in the previous message is a video of the finished version of this One thing about this: Don't care. To me is perfect, but i think that this publication in PicBasic.org would be better in english. A message in spanish don't match in a english Web. I tell you before. I can try to write it in english, but i need somebody that rewrite it in correct english. Some pics of my display: (((http://img405.imageshack.us/i/displayrs232.png/). I think what is a framing error or similar.

I had this issue with a large test-bed that randomly cut power the the units under test. Sometimes this was while there were sending RS232 data and my pic would hang. See below for the solution.

(From this topic, one year ago) There is a tiny bug in the BUFFEREDUSART.inc file: Under the error handling section inside the interrupt, it traps on two errors but only handles one of them. Movlw 6 ' Yes. So Mask out unwanted bits andwf RCSTA,W ' Check for errors bnz UARTERROR ' Was either error status bit set?

Jan 28, 2015 - Jmp 10 full version download crackedjmp crackdownload of JMP with crackjmp pro 10 windowsjmp pro 10 licensejmp pro 10 crackjmp free download for Jmp software free download crack. RarSAS JMP Pro v 10 Jmp 11 Full Version, jmp 11 Cracks, jmp 11 Serials, jmp 11 Keygens PRO II V9. Jmp version 10.

Bit 2 FERR: Framing Error bit 1 = Framing error (can be updated by reading RCREG register and receiving next valid byte) 0 = No framing error bit 1 OERR: Overrun Error bit 1 = Overrun error (can be cleared by clearing bit CREN) 0 = No overrun error Adding a ‘movf RCREG” inside the error handling section will clear the framing if necessary UARTERROR: movf RCREG ' Clear Framing error by reading RCREG Clear RCSTA.4 ' Clear receiver status Set RCSTA.4 retfie Fast Alan R. Thanks for this TIP Alan, I was having problems with lockups using this routine.

Serial Interface Protocols

By adding the 'movf RCREG' as you suggested, my lockups seem to have totally vanished (touch wood:cheerful:) Your hint seems to have totally fixed my problem. I think what is a framing error or similar. I had this issue with a large test-bed that randomly cut power the the units under test. Sometimes this was while there were sending RS232 data and my pic would hang. See below for the solution. (From this topic, one year ago) There is a tiny bug in the BUFFEREDUSART.inc file: Under the error handling section inside the interrupt, it traps on two errors but only handles one of them.

Movlw 6 ' Yes. So Mask out unwanted bits andwf RCSTA,W ' Check for errors bnz UARTERROR ' Was either error status bit set? Bit 2 FERR: Framing Error bit 1 = Framing error (can be updated by reading RCREG register and receiving next valid byte) 0 = No framing error bit 1 OERR: Overrun Error bit 1 = Overrun error (can be cleared by clearing bit CREN) 0 = No overrun error Adding a ‘movf RCREG” inside the error handling section will clear the framing if necessary UARTERROR: movf RCREG ' Clear Framing error by reading RCREG Clear RCSTA.4 ' Clear receiver status Set RCSTA.4 retfie Fast Alan R.