Serial port text corruption

[Joakim Tjernlund]

> I would look at the SMC1 buffering and handling of caches (either snooping, not caching the buffers, or flushing before
> transmitting).

The 8xx uses its internal memory as buffers and this is uncached memory, so this should not be a problem.

>
> Another possiblility is sending data that is stored on the stack in a subroutine which subsequently returns before the
> data is actually transmitted -- when you are lucky, the data hasn't changed when the Tx occurs, when you are unlucky, a
> call sequence has overwritten the string on the stack.  Since this is (presumably) standard linux and that sort of a
> problem would have been found and fixed loooong ago in the linux core code, I would concentrate on your low level code.

OK, I will have a look at this.

>
> Just to eliminate variables, you should hook a logic analyzer or 'scope to the board's Tx line and verify the baud rate
> hasn't changed when you get the garbage characters.  If the baud rate has changed, it will be a clocking problem.

I will see what I can do.

 Jocke

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/