UARTs RCIDL stuck low (receiver active)

[RossJ]

Hi all,

I've encountered a problem where the RCIDL flag (BAUDCON) remains stuck in a cleared state after having worked correctly for some period of time. All received bytes have been read and there were no errors (FERR and OERR are both clear). The UART is enabled and CREN is set. I've verified that the transmitter is working correctly whilst in this state. I'm not certain whether the receiver is still working whilst in this state (i.e. that it's just the flag that's stuck). The problem is resolved by clearing and resetting CREN (i.e. the same action taken to recover from an OERR).

Does anyone have any idea as to what might lead to this situation? The behavior doesn't make much sense to me, nor can I see anything in the errata or on this or the Microchip forum.

I am checking RCIDL for a reason, but may have to either find another solution and avoid using this flag or detect when it gets stuck and reset the receiver.

I'm using a PIC18F87J11 and the latest PCH version.

Cheers, Ross

[Ttelmah]

Are you using Auto Baud Detect anywhere in the code?.
This can happen if you set the ABDEN, and there is still a byte in the
transmit buffer to send.
I've seen a system where the programmer was using auto baud detect
and did not verify that the transmit had stopped before setting the bit
(he was actually sending a byte to trigger the other system to send a
sequence for the baud detect, but had not verified the transmit had
completed before setting ABDEN), give exactly this behaviour (different
chip though). It puts the UART into an indeterminate state...

[temtronic]

arrgh... man how can Mr. T have any hair left...
ABD locks up the UART....grrrrr.

Could that bit be enabled by the compiler as a hidden 'default' ?

THAT would 'upset' me , especially if the new compiler version did and the old didn't...

Jay

[Ttelmah]

It's only if you transmit anything while it is in the ABD state. You
have to verify that not only the transmit buffer is empty, but that the
transmit shift register has emptied. This was what was wrong in the
code I met, He 'sent' the trigger sequence for the other system, but
had not checked TRMT to verify the transmission had completed. Then
enabled ABD. Result complete disaster...

It's worth perhaps 'realising', how this is done. When you switch to this
state, it stops using the oscillator to clock the UART, and instead clocks
it off the external RX line, using an internal counter to time the interval
between these clocks. So trying to complete a transmission while this
is happening, is impossible.

In fact interestingly, the data sheet for the chip involved here does have
a warning about this (the other chip where I met this didn't):

[RossJ]

Hi Ttelmah,

Thanks for the suggestion. I am not intentionally using ABD... just hard coded 115200. I've checked over the LST file and the only access to the BAUDCON register is to set BRG16 (by set_uart_speed()) and read RCIDL. But it's always interesting to hear about the quirks (when other people encounter them :-).

I have since observed the RCIDL being correctly set on a debugger breakpoint, but then becoming reset (and remaining that way) following a few steps. This behavior is inconsistent though. My suspicion now is that this is perhaps a quirk of the debugger, possibly combined the arrival of data whilst stopped or during the steps.

Importantly I've found another more likely cause for my original problem, which is good because it occurred without the debugger being used.

Cheers, Ross