UART Rx stops reading

[simon-sandtcontrols]

Hi All,

I wonder if someone could point me in the right direction with this please.

I am using a PIC18F45K42 specifically as it has 2 UART transceivers, I am using UART 1 to talk to a PC on pins C6 and C7 and then the one I am having problems with, UART 2 on pins Tx D2 and Rx D3, to talk to a couple of other PICs via a couple of transistors etc. I have it all working seamlessly most of the time, however I noticed very occasionally it would stop talking and the only way I can get it to work again is to reset the entire PIC. I have an oscilloscope attached to the Tx and Rx and I have noticed that it stops reading the receive at all. There are 2 Tx bytes being sent and instead of waiting for the read byte in between them they just get sent as one lump. I have identified the cause and that is if the Rx pin gets any corruption on it from an external source, eg. a finger to the 0V line!!! I would really like to be able to restart the receive without having to reset the entire thing. It's monitoring some equipment and reporting conditions.

I have read the U2FIFO register and when it's working normally I get a 0x2E or 46 and when it stops I get 0x2D or 45. The difference is 46, Read buffer empty, 45 Read buffer is full. I have tried writing to 0x2E to this register while it's in the fault situation, which the data sheet tends to indicate should clear the read buffer, but although it changes the situation and it looks like it starts reading again, the ReadNumber just brings back 0's. I am not using 0's in my code, so I know this is a comms error. I have tried using the initialise command in the UART component, and that doesn't have any effect at all.

I have very very limited knowledge of C++ hence I use Flowcode. This one has me stumped. The data sheet mentions using MOVWF but this is where my limited knowledge of C let me down.

If there are any ideas, I would be very grateful.

Thanks in advance.

Simon.

[simon-sandtcontrols]

Hi All,

After a load more research this afternoon, it might appear I am getting a Framing Error of an Overrun Error, which I am equating the the buffer full I found before. Looks like either of these lock up the UART receive until they are cleared, it would appear that this is usually achieved by clearing and setting the CREN or OERR, however I can not find any reference to these in the data sheet for this chip.

Does anyone have any idea of how I clear these errors on the PIC18F45K42 chip please?

Many Thanks.

Simon.

[chipfryer27]

Hi

I've not used that particular chip but it would help if you would share your code (or even just the parts pertaining to UARTs).

Does the issue follow the ports? By that I mean if you swap whatever is connected to UART1 with UART2 is the problem still UART2?

Regards

[simon-sandtcontrols]

Hi Chipfryer,

There is only a small bit of it that's looking at the UARTs and it's simply reading a value from one UART and sending it out of the other. I have taken a load out to try and get to the bottom of this. I am not sure if the same problem exists on UART 1 as it's not so easy to do. I designed a PCB for this, actually a different chip, thinking I had purchased one, only to find it was an LF and not an F, the F was on a 104 week lead time!!! UART 1 doesn't cover the same pins as UART 2, so I can't just swap it all over in software. I do know that the problem is caused by a glitch with the hardware, which I can do a few things to help prevent, it would now just be very nice to get the software to have a go at resolving it's self rather than having to power the whole thing down, if it does happen.

I think I may have made some more progress in the last half an hour, trawling the datasheet. That chip has a setting to cease receiving on overrun error, hence why I see the receive delay disappear from the scope trace, but according to the data sheet if you restart it it can loose its synchronising, so it would seem to me it's better to disable this function and let it run, if I then detect the overrun, I can just clear the FIFO buffer by initiating a receive number or string and dumping it's contents. It looks like the overrun error can be reset using U2RXBE

As I said I have done very little in C and hadn't cottoned on to how you read or write to a single bit of a register using the mnemonics. I have now worked that out, a bit slow on the uptake on that one, but is going to make this a lot easier. I have packed it all up for today, I will try re-flashing the code turning off the U2RUNOVF bit tomorrow morning and see what happens. I will post here with the results as this might help someone in the future.

Thanks for coming back to me, that's much appreciated.

Simon.

[simon-sandtcontrols]

Hi All,

Just for reference.

I have now solved this. By reading the 7 registers for the UART 2 out of the UART 1 connected to the PC I could then see the complete setup and the error interrupts status. I could see that all of the Error interrupts were turned off, however when the problem occurred, the interrupt U2RXOIF still set, indicating an FIFO receive overrun. I have now done a "ReceiveCharacter" 4 times and discarded the result, then run a C command:
U2RXBE=1;
U2TXBE=1;
U2RXFOIF=0;

This cures the problem and resets the UART transceiver and it continues to run as normal.

I don't know if all of the above code is required, (I expect the TXBE isn't, that was for good measure) it could be that it doesn't need all of it, but it works and having spent 4 days trying to resolve this I am going to leave it alone and move on!!!

Thanks to all who took the time to read all of this.

Simon.