> 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/
