mxs-auart gives data from previous run after close and reopen

mxs-auart gives data from previous run after close and reopen

[Stanislav Meduna]

Hi,

following scenario:

- a Freescale i.MX28 machine
- RS232 AUART looped back Rx - Tx or two different ports cross-connected
- a test program sending data in one thread and receiving in the other:
  thread A periodically sends "Quick brown fox jumps over the lazy dog",
  thread B receives
- stop the program using ctrl-C
- restart

=> sometimes the receiving thread gets "dogQuick", receiving
   characters from the previous transmission

The extra characters definitely come from the receiver - the transmission
is OK. This was verified by a scope.

My theory is that this behaviour is caused by mxs_auart_shutdown
function gating and mxs_auart_startup reenabling the clock instead
of doing a soft reset. If the clock is gated while the AUART already
has something in the FIFO, but did not generate the interrupt yet,
the internal state machine is frozen in this state. As soon as it
is reenabled, the characters are delivered to a new user.

I am using a 3.4.77 kernel, but the relevant code looks the same in
the recent kernels (when not using DMA). I also backported patches
waiting for the transmission FIFO to clear at mxs_auart_shutdown.

I did not find any possibility to fully clear the receiver - even
if one disables the AUART and reads everything from the FIFO,
the character currently in transmit might be still somewhere (the
reference manual states that disabling is effective after the
current character is received). Which might be 1 ms at 9600 and one
has no clue whether it is the case.

Also note that the function mxs_auart_reset is in fact not doing
a reset - it just makes sure that the AUART comes out of one after
the initialization. Maybe a full reset at startup is the solution...

Pleas Cc: me when answering.

Regards
-- 
                                Stano

mxs-auart gives data from previous run after close and reopen

[Stanislav Meduna]

Hi,

following scenario:

- a Freescale i.MX28 machine
- RS232 AUART looped back Rx - Tx or two different ports cross-connected
- a test program sending data in one thread and receiving in the other:
  thread A periodically sends "Quick brown fox jumps over the lazy dog",
  thread B receives
- stop the program using ctrl-C
- restart

=> sometimes the receiving thread gets "dogQuick", receiving
   characters from the previous transmission

The extra characters definitely come from the receiver - the transmission
is OK. This was verified by a scope.

My theory is that this behaviour is caused by mxs_auart_shutdown
function gating and mxs_auart_startup reenabling the clock instead
of doing a soft reset. If the clock is gated while the AUART already
has something in the FIFO, but did not generate the interrupt yet,
the internal state machine is frozen in this state. As soon as it
is reenabled, the characters are delivered to a new user.

I am using a 3.4.77 kernel, but the relevant code looks the same in
the recent kernels (when not using DMA). I also backported patches
waiting for the transmission FIFO to clear at mxs_auart_shutdown.

I did not find any possibility to fully clear the receiver - even
if one disables the AUART and reads everything from the FIFO,
the character currently in transmit might be still somewhere (the
reference manual states that disabling is effective after the
current character is received). Which might be 1 ms at 9600 and one
has no clue whether it is the case.

Also note that the function mxs_auart_reset is in fact not doing
a reset - it just makes sure that the AUART comes out of one after
the initialization. Maybe a full reset at startup is the solution...

Pleas Cc: me when answering.

Regards
-- 
                                Stano

Re: mxs-auart gives data from previous run after close and reopen

[Peter Hurley]

On 03/14/2014 04:11 PM, Stanislav Meduna wrote:
> Hi,
>
> following scenario:
>
> - a Freescale i.MX28 machine
> - RS232 AUART looped back Rx - Tx or two different ports cross-connected
> - a test program sending data in one thread and receiving in the other:
>    thread A periodically sends "Quick brown fox jumps over the lazy dog",
>    thread B receives
> - stop the program using ctrl-C
> - restart
>
> => sometimes the receiving thread gets "dogQuick", receiving
>     characters from the previous transmission
>
> The extra characters definitely come from the receiver - the transmission
> is OK. This was verified by a scope.
>
> My theory is that this behaviour is caused by mxs_auart_shutdown
> function gating and mxs_auart_startup reenabling the clock instead
> of doing a soft reset. If the clock is gated while the AUART already
> has something in the FIFO, but did not generate the interrupt yet,
> the internal state machine is frozen in this state. As soon as it
> is reenabled, the characters are delivered to a new user.
>
> I am using a 3.4.77 kernel, but the relevant code looks the same in
> the recent kernels (when not using DMA). I also backported patches
> waiting for the transmission FIFO to clear at mxs_auart_shutdown.
>
> I did not find any possibility to fully clear the receiver - even
> if one disables the AUART and reads everything from the FIFO,
> the character currently in transmit might be still somewhere (the
> reference manual states that disabling is effective after the
> current character is received). Which might be 1 ms at 9600 and one
> has no clue whether it is the case.
>
> Also note that the function mxs_auart_reset is in fact not doing
> a reset - it just makes sure that the AUART comes out of one after
> the initialization. Maybe a full reset at startup is the solution...
>
> Pleas Cc: me when answering.

Does disabling the fifo on shutdown clear the fifo?

mxs-auart gives data from previous run after close and reopen

[Peter Hurley]

On 03/14/2014 04:11 PM, Stanislav Meduna wrote:
> Hi,
>
> following scenario:
>
> - a Freescale i.MX28 machine
> - RS232 AUART looped back Rx - Tx or two different ports cross-connected
> - a test program sending data in one thread and receiving in the other:
>    thread A periodically sends "Quick brown fox jumps over the lazy dog",
>    thread B receives
> - stop the program using ctrl-C
> - restart
>
> => sometimes the receiving thread gets "dogQuick", receiving
>     characters from the previous transmission
>
> The extra characters definitely come from the receiver - the transmission
> is OK. This was verified by a scope.
>
> My theory is that this behaviour is caused by mxs_auart_shutdown
> function gating and mxs_auart_startup reenabling the clock instead
> of doing a soft reset. If the clock is gated while the AUART already
> has something in the FIFO, but did not generate the interrupt yet,
> the internal state machine is frozen in this state. As soon as it
> is reenabled, the characters are delivered to a new user.
>
> I am using a 3.4.77 kernel, but the relevant code looks the same in
> the recent kernels (when not using DMA). I also backported patches
> waiting for the transmission FIFO to clear at mxs_auart_shutdown.
>
> I did not find any possibility to fully clear the receiver - even
> if one disables the AUART and reads everything from the FIFO,
> the character currently in transmit might be still somewhere (the
> reference manual states that disabling is effective after the
> current character is received). Which might be 1 ms at 9600 and one
> has no clue whether it is the case.
>
> Also note that the function mxs_auart_reset is in fact not doing
> a reset - it just makes sure that the AUART comes out of one after
> the initialization. Maybe a full reset at startup is the solution...
>
> Pleas Cc: me when answering.

Does disabling the fifo on shutdown clear the fifo?

Re: mxs-auart gives data from previous run after close and reopen

[Stanislav Meduna]

On 21.03.2014 02:39, Peter Hurley wrote:

> Does disabling the fifo on shutdown clear the fifo?

I did not try this, but if my theory is correct, it would
not help, as all this does is reducing the FIFO length
to one character. So you'd still get up to two characters:
one in the "FIFO" - it could get there a microsecond after
you disable the FIFO before you gate the clock - and one
being received into the shift register (garbled by shutting
down the clock in the middle of the reception that was
resumed when clock was resumed on startup). Note that one
can get preempted here, so the instructions next to each
other can be milliseconds apart in reality.

IMHO we need a soft-reset here.

Regards
-- 
                                     Stano

mxs-auart gives data from previous run after close and reopen

[Stanislav Meduna]

On 21.03.2014 02:39, Peter Hurley wrote:

> Does disabling the fifo on shutdown clear the fifo?

I did not try this, but if my theory is correct, it would
not help, as all this does is reducing the FIFO length
to one character. So you'd still get up to two characters:
one in the "FIFO" - it could get there a microsecond after
you disable the FIFO before you gate the clock - and one
being received into the shift register (garbled by shutting
down the clock in the middle of the reception that was
resumed when clock was resumed on startup). Note that one
can get preempted here, so the instructions next to each
other can be milliseconds apart in reality.

IMHO we need a soft-reset here.

Regards
-- 
                                     Stano

Re: mxs-auart gives data from previous run after close and reopen

[Peter Hurley]

On 03/21/2014 04:21 AM, Stanislav Meduna wrote:
> On 21.03.2014 02:39, Peter Hurley wrote:
>
>> Does disabling the fifo on shutdown clear the fifo?
>
> I did not try this, but if my theory is correct, it would
> not help, as all this does is reducing the FIFO length
> to one character. So you'd still get up to two characters:
> one in the "FIFO" - it could get there a microsecond after
> you disable the FIFO before you gate the clock - and one
> being received into the shift register (garbled by shutting
> down the clock in the middle of the reception that was
> resumed when clock was resumed on startup). Note that one
> can get preempted here, so the instructions next to each
> other can be milliseconds apart in reality.
>
> IMHO we need a soft-reset here.

The reason why I asked about disabling the fifo is
because on other uarts, changing from non-fifo to fifo
mode clears the fifo. The idea being that, on shutdown,
if the uart is changed to non-fifo mode then, on startup,
the uart will be changed back to fifo mode, clearing the
fifo.

Unfortunately, the i.mx28 reference doesn't say what
happens to the data when the fifo is reconfigured this
way, and why I suggested the experiment.

Regards,
Peter Hurley

mxs-auart gives data from previous run after close and reopen

[Peter Hurley]

On 03/21/2014 04:21 AM, Stanislav Meduna wrote:
> On 21.03.2014 02:39, Peter Hurley wrote:
>
>> Does disabling the fifo on shutdown clear the fifo?
>
> I did not try this, but if my theory is correct, it would
> not help, as all this does is reducing the FIFO length
> to one character. So you'd still get up to two characters:
> one in the "FIFO" - it could get there a microsecond after
> you disable the FIFO before you gate the clock - and one
> being received into the shift register (garbled by shutting
> down the clock in the middle of the reception that was
> resumed when clock was resumed on startup). Note that one
> can get preempted here, so the instructions next to each
> other can be milliseconds apart in reality.
>
> IMHO we need a soft-reset here.

The reason why I asked about disabling the fifo is
because on other uarts, changing from non-fifo to fifo
mode clears the fifo. The idea being that, on shutdown,
if the uart is changed to non-fifo mode then, on startup,
the uart will be changed back to fifo mode, clearing the
fifo.

Unfortunately, the i.mx28 reference doesn't say what
happens to the data when the fifo is reconfigured this
way, and why I suggested the experiment.

Regards,
Peter Hurley