UART RX interrupt triggered even though nothing on RX line

Hi,

I have a problem with my RX interrupt triggering even though there's
nothing on the RX line. Subsequently the RX buffer is 0, and that gets
inserted into my FIFO, resulting in incorrect data.

This happens only when I reinitialize the UART. What I'm doing is
initializing my UART once I detect a device has been connected. When
the device is disconnected, I disable my UART simply by disabling the
RX/TX interrupts. Then, if the device is detected again, I will
initialize the UART again, including setting all the SFRs(baudrate,
etc) and enabling the RX/TX interrupt.

I have no problem with the first time the device is detected and the
UART is initialized. All transfers are perfectly normal. However, on
the 2nd time, right after I initialize my UART again, very soon after
the RX ISR gets called(almost always twice in succession, and hence 2
0x00s are inserted into the FIFO.

I've traced this on a logic analyzer and there's no data on the RX line
at all, so I'm not sure why the RX interrupt is triggered, why it's
triggered twice, and why it's triggered only on the 2nd time.

Any ideas?

galapogos wrote:
> Hi,
>
> I have a problem with my RX interrupt triggering even though there's
> nothing on the RX line. Subsequently the RX buffer is 0, and that gets
> inserted into my FIFO, resulting in incorrect data.
>
> This happens only when I reinitialize the UART. What I'm doing is
> initializing my UART once I detect a device has been connected. When
> the device is disconnected, I disable my UART simply by disabling the
> RX/TX interrupts. Then, if the device is detected again, I will
> initialize the UART again, including setting all the SFRs(baudrate,
> etc) and enabling the RX/TX interrupt.
>
> I have no problem with the first time the device is detected and the
> UART is initialized. All transfers are perfectly normal. However, on
> the 2nd time, right after I initialize my UART again, very soon after
> the RX ISR gets called(almost always twice in succession, and hence 2
> 0x00s are inserted into the FIFO.
>
> I've traced this on a logic analyzer and there's no data on the RX line
> at all, so I'm not sure why the RX interrupt is triggered, why it's
> triggered twice, and why it's triggered only on the 2nd time.
>
> Any ideas?


I would suggest to write down all ISRs related to UART while providing
empty body for unused ISR.

ali

Ali wrote:
> galapogos wrote:
> > Hi,
> >
> > I have a problem with my RX interrupt triggering even though there's
> > nothing on the RX line. Subsequently the RX buffer is 0, and that gets
> > inserted into my FIFO, resulting in incorrect data.
> >
> > This happens only when I reinitialize the UART. What I'm doing is
> > initializing my UART once I detect a device has been connected. When
> > the device is disconnected, I disable my UART simply by disabling the
> > RX/TX interrupts. Then, if the device is detected again, I will
> > initialize the UART again, including setting all the SFRs(baudrate,
> > etc) and enabling the RX/TX interrupt.
> >
> > I have no problem with the first time the device is detected and the
> > UART is initialized. All transfers are perfectly normal. However, on
> > the 2nd time, right after I initialize my UART again, very soon after
> > the RX ISR gets called(almost always twice in succession, and hence 2
> > 0x00s are inserted into the FIFO.
> >
> > I've traced this on a logic analyzer and there's no data on the RX line
> > at all, so I'm not sure why the RX interrupt is triggered, why it's
> > triggered twice, and why it's triggered only on the 2nd time.
> >
> > Any ideas?
>
>
> I would suggest to write down all ISRs related to UART while providing
> empty body for unused ISR.

What do you mean write down all ISRs related to UART? I have 2 ISRs
that are UART related - the RX and the TX ISR. One is called when
there's something in the RX buffer and the other's called when there's
something in the TX buffer.

After some more debugging, I realize that I can nullify the effect of
the blip by initializing the UART, waiting for a short period of time,
then initializing the UART again. Since my UART initializing function
also resets the FIFO buffer index and clears the contents, the 2 extra
bytes will not affect my later data transfers. It's a hack but it
works. I'd still like to find out why there even are the 2 extra bytes
though...

galapogos wrote:
> Hi,
> 
> I have a problem with my RX interrupt triggering even though there's
> nothing on the RX line. Subsequently the RX buffer is 0, and that gets
> inserted into my FIFO, resulting in incorrect data.
> 
> This happens only when I reinitialize the UART. What I'm doing is
> initializing my UART once I detect a device has been connected. When
> the device is disconnected, I disable my UART simply by disabling the
> RX/TX interrupts. Then, if the device is detected again, I will
> initialize the UART again, including setting all the SFRs(baudrate,
> etc) and enabling the RX/TX interrupt.
> 
> I have no problem with the first time the device is detected and the
> UART is initialized. All transfers are perfectly normal. However, on
> the 2nd time, right after I initialize my UART again, very soon after
> the RX ISR gets called(almost always twice in succession, and hence 2
> 0x00s are inserted into the FIFO.
> 
> I've traced this on a logic analyzer and there's no data on the RX line
> at all, so I'm not sure why the RX interrupt is triggered, why it's
> triggered twice, and why it's triggered only on the 2nd time.
> 
> Any ideas?

Processor ?
How do you detect/decide it is connected / removed  ?

On disconnect noise, watch for flags being set, and waiting until
you re-enable. As part of your init, it is safe practice to
also clear any flags that may be pending, prior to enable
of INT.

-jg

galapogos wrote:
> Ali wrote:
> > galapogos wrote:
> > > Hi,
> > >
> > > I have a problem with my RX interrupt triggering even though there's
> > > nothing on the RX line. Subsequently the RX buffer is 0, and that gets
> > > inserted into my FIFO, resulting in incorrect data.
> > >
> > > This happens only when I reinitialize the UART. What I'm doing is
> > > initializing my UART once I detect a device has been connected. When
> > > the device is disconnected, I disable my UART simply by disabling the
> > > RX/TX interrupts. Then, if the device is detected again, I will
> > > initialize the UART again, including setting all the SFRs(baudrate,
> > > etc) and enabling the RX/TX interrupt.
> > >
> > > I have no problem with the first time the device is detected and the
> > > UART is initialized. All transfers are perfectly normal. However, on
> > > the 2nd time, right after I initialize my UART again, very soon after
> > > the RX ISR gets called(almost always twice in succession, and hence 2
> > > 0x00s are inserted into the FIFO.
> > >
> > > I've traced this on a logic analyzer and there's no data on the RX line
> > > at all, so I'm not sure why the RX interrupt is triggered, why it's
> > > triggered twice, and why it's triggered only on the 2nd time.
> > >
> > > Any ideas?
> >
> >
> > I would suggest to write down all ISRs related to UART while providing
> > empty body for unused ISR.
>
> What do you mean write down all ISRs related to UART? I have 2 ISRs
> that are UART related - the RX and the TX ISR. One is called when
> there's something in the RX buffer and the other's called when there's
> something in the TX buffer.
>
> After some more debugging, I realize that I can nullify the effect of
> the blip by initializing the UART, waiting for a short period of time,
> then initializing the UART again. Since my UART initializing function
> also resets the FIFO buffer index and clears the contents, the 2 extra
> bytes will not affect my later data transfers. It's a hack but it
> works. I'd still like to find out why there even are the 2 extra bytes
> though...


Like this!

SIGNAL(SIG_OVERFLOW0){ }
SIGNAL(SIG_OVERFLOW1) { }
SIGNAL(SIG_INTERRUPT0){ }
SIGNAL(SIG_UART_RECV) {}
SIGNAL(SIG_UART_SEND) {}

> What do you mean write down all ISRs related to UART?

Kind of typo error, You should write all the ISR for used peripherals
(not only uart) or make it more even while writing all the ISRs of your
device with empty bodies.

I did examine the same problem and got this *workable* advice from a
soul. Maybe someone here would explain this ;-)

ali

Jim Granville wrote:
> galapogos wrote:
> > Hi,
> >
> > I have a problem with my RX interrupt triggering even though there's
> > nothing on the RX line. Subsequently the RX buffer is 0, and that gets
> > inserted into my FIFO, resulting in incorrect data.
> >
> > This happens only when I reinitialize the UART. What I'm doing is
> > initializing my UART once I detect a device has been connected. When
> > the device is disconnected, I disable my UART simply by disabling the
> > RX/TX interrupts. Then, if the device is detected again, I will
> > initialize the UART again, including setting all the SFRs(baudrate,
> > etc) and enabling the RX/TX interrupt.
> >
> > I have no problem with the first time the device is detected and the
> > UART is initialized. All transfers are perfectly normal. However, on
> > the 2nd time, right after I initialize my UART again, very soon after
> > the RX ISR gets called(almost always twice in succession, and hence 2
> > 0x00s are inserted into the FIFO.
> >
> > I've traced this on a logic analyzer and there's no data on the RX line
> > at all, so I'm not sure why the RX interrupt is triggered, why it's
> > triggered twice, and why it's triggered only on the 2nd time.
> >
> > Any ideas?
>
> Processor ?
Toshiba TMP91FY7 16bit MCU

> How do you detect/decide it is connected / removed  ?
I have a timer interrupt that triggers every 20ms, and then checks the
state of the device by polling an input pin, and sets the global status
variable based on current state and pin level. It also debounces the
contact, and is hence a 20ms state machine.

> On disconnect noise, watch for flags being set, and waiting until
> you re-enable. As part of your init, it is safe practice to
> also clear any flags that may be pending, prior to enable
> of INT.
So you think it's an issue with disconnection rather than reconnection.
I was kinda suspecting the latter.

"galapogos" <goister@gmail.com> wrote in message
news:1166003074.092524.280660@16g2000cwy.googlegroups.com...
> So you think it's an issue with disconnection rather than reconnection.
> I was kinda suspecting the latter.

It can be both.
Both actions can produce transients on the data and handshake lines, so the
only way to deal with this is when you detect a connection again, clear all
data and status regs and flags and only then enable the ints again. And even
then your protocol  should be able to handle spurious data in the initial
bytes. It is a bit like hitting your return key once or twice when you have
connected to a modem, in order to see the "OK" message before sending real
commands.

Meindert

Meindert Sprang wrote:
> "galapogos" <goister@gmail.com> wrote in message
> news:1166003074.092524.280660@16g2000cwy.googlegroups.com...
> > So you think it's an issue with disconnection rather than reconnection.
> > I was kinda suspecting the latter.
>
> It can be both.
> Both actions can produce transients on the data and handshake lines, so the
> only way to deal with this is when you detect a connection again, clear all
> data and status regs and flags and only then enable the ints again. And even
> then your protocol  should be able to handle spurious data in the initial
> bytes. It is a bit like hitting your return key once or twice when you have
> connected to a modem, in order to see the "OK" message before sending real
> commands.

Right now I'm clearing the flags in the uart initialization function.
At the end of the function, I enable the rx/tx interrupts. However, it
seems like the enabling of the interrupts is causing spurious data. How
would I handle spurious data in the initial bytes? Right now I'm doing
it by calling the init function, delaying for 1ms for the spurious data
to occur, then calling the init function again(hence clearing the
flags). Does this seem like a good idea? 1ms seem to work now but god
knows if some time in the future there's be spurious data happening
after 1ms after the init function.
I'm also curious as to why only the 2nd init function call causes this
rather consistent spike in the interrupt(almost always 2 interrupts),
and not the 1st or 3rd time.

Meindert Sprang wrote:
> "galapogos" <goister@gmail.com> wrote in message
> news:1166003074.092524.280660@16g2000cwy.googlegroups.com...
> > So you think it's an issue with disconnection rather than reconnection.
> > I was kinda suspecting the latter.
>
> It can be both.
> Both actions can produce transients on the data and handshake lines, so the
> only way to deal with this is when you detect a connection again, clear all
> data and status regs and flags and only then enable the ints again. And even
> then your protocol  should be able to handle spurious data in the initial
> bytes. It is a bit like hitting your return key once or twice when you have
> connected to a modem, in order to see the "OK" message before sending real
> commands.
>
> Meindert

I found out that those 2 extra interrupts actually also trigger one of
the 3 error status bits that I thought I was checking but actually
negated for debugging purposes earlier. They are the buffer overrun,
parity and framing error bits. Now I'm actually doing the checking and
handling the errors, i.e. not copying them into my FIFO so that sorta
handles it. Still not sure why I'm even getting those 2 interrupts
though but at least they're taken care of. I tried clearing those
status bits on disconnect and also on reconnect, but they still appear.
I guess it's a good thing since otherwise, it might get pushed into the
FIFO.

galapogos wrote:
> Meindert Sprang wrote:
> 
>>"galapogos" <goister@gmail.com> wrote in message
>>news:1166003074.092524.280660@16g2000cwy.googlegroups.com...
>>
>>>So you think it's an issue with disconnection rather than reconnection.
>>>I was kinda suspecting the latter.
>>
>>It can be both.
>>Both actions can produce transients on the data and handshake lines, so the
>>only way to deal with this is when you detect a connection again, clear all
>>data and status regs and flags and only then enable the ints again. And even
>>then your protocol  should be able to handle spurious data in the initial
>>bytes. It is a bit like hitting your return key once or twice when you have
>>connected to a modem, in order to see the "OK" message before sending real
>>commands.
>>
>>Meindert
> 
> 
> I found out that those 2 extra interrupts actually also trigger one of
> the 3 error status bits that I thought I was checking but actually
> negated for debugging purposes earlier. They are the buffer overrun,
> parity and framing error bits. Now I'm actually doing the checking and
> handling the errors, i.e. not copying them into my FIFO so that sorta
> handles it. Still not sure why I'm even getting those 2 interrupts
> though but at least they're taken care of. I tried clearing those
> status bits on disconnect and also on reconnect, but they still appear.
> I guess it's a good thing since otherwise, it might get pushed into the
> FIFO.

 From your comments on the 20ms pin-polling (DSR?) scheme, it sounds like
there is potential there to slice RX data.
If you are sure there are enough margins so that RX activity change
occur (well) after the polling has seen the handshake line, then that
suggests a chip artifact.
Even when disabled, is there _any_ RXD activity ?
I've seen uarts before that did not cross the baud-configure boundary 
very well.

-jg