We're loosing serial bytes from PC to phone
laforge at gnumonks.org
Mon Mar 22 00:24:21 UTC 2010
On Sun, Mar 21, 2010 at 11:42:50PM +0100, Ingo Albrecht wrote:
> Harald Welte wrote:
> > Hi!
> > It seems we're loosing serial characters on their way from the (Linux)
> > PC to the phone.
> I had problems with this during bootloader development and did some
> research, as did you. I came to similar conclusions (not seeing the loss
> in sercomm or other software but in between the two uart drivers).
> One thing that I noticed while checking the datasheets is that the audio
> frontend for the headphone jack is never detached from the port.
There are SPDT (single-pole dual-throw) switches between the audio jack
and the audio port of the calypso. Using those switches
(NLASB3157DFT2), controlled by Calypso IO2, the headphone jack is
exclusively used by either the UART or the audio part, so I don't
understand your observation.
The only part that seems permanently connected is the HSMICBIAS from
Iota. Maybe we should double-check that we don't apply a bias voltage
> I must note though that I have not only been getting lost bytes but also
> reversed bytes. We spent a while discussing this in IRC. steve-m could
> reproduce this perfectly, as could I. The problem seems to be
> data-dependend though, as sending the same frame twice (with the
> bootloader tool) yields the same garbling.
this is even weirder. However, as you indicated in your previous mail,
the trigger pattern in this case also includes a number of zero-bytes...
One of my idaes was BREAK-detection, as BREAK is nothing but a
longer-than-a-byte zero level on RS232. So in theory, two successive
zero bytes without the line going high in between should be recognized
as break. However, the Calypso UART does not indicate any BREAK interrupt
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
More information about the baseband-devel