We're loosing serial bytes from PC to phone

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Ingo Albrecht prom at berlin.ccc.de
Sun Mar 21 22:42:50 UTC 2010


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. So I
believed that this was caused by specific data patterns, which trigger a
frequency response in the audio frontend. However, the fact that you
have been able to reproduce this with long inter-word delays suggests
that this is probably not true.

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.

> I think I've seen this at some point in the past, but now I'm seeing it
> constantly.
> 
> Let's assume we're trying to send the following sequence of bytes from
> the PC side to the phone in one of the HLDC connections:
>> send_to_phone(dlci=5): 0a 00 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
>> 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
>> 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 
> 
> what we actually get from the sercomm callback on the phone is:
> 
>> l1a_l23_rx_cb: 0a 00 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12
>> 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a
>> 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 
> 
> as you can see, there is a '00 01' missing between the '00' and the '02'.
> 
> Interestingly, putting a usleep(10000) after every serial write does not
> solve the problem, so it is not timing related.  We don't get any UART
> overflows on the calypso, either.
> 
> If I change the data pattern, then the first bytes are transmitted fine,
> but as soon as there is one 00 bytes, two characters are missing from
> the stream.
> 
> If I strace osmocon, it is clear that we write every character,
> including the null-bytes, and all of the writes are successfully.
> 
> I've again looked at (and played with) the termios settings, but could
> not find any problem (nor solution).
> 
> It's also not the sercomm layer that is loosing bytes, as I the
> characters appear already lost when printing them from within the
> calypso UART driver, as you can see here:
> 
> getchar_nb(1) = 7e	// flag character
> getchar_nb(1) = 05	// hdlc
> getchar_nb(1) = 03	// hdlc
> getchar_nb(1) = 0a	// l1ctl_hdr (undefined msg_type 10)
> getchar_nb(1) = 00	// padding
> getchar_nb(1) = 02	// here should be 00, 01, 02...
> getchar_nb(1) = 03
> getchar_nb(1) = 04
> getchar_nb(1) = 05
> [...]
> 
> Any ideas? It's really strange and I don't really know what else to do.
> I'm quite sure our binaries contain multiple successive null-bytes and
> their download is working great...
> 
> Regards,
> 	Harald





More information about the baseband-devel mailing list