Hi prom,
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 here.
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 either :(
Regards, Harald