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:48:36 UTC 2010


Ingo Albrecht wrote:
> Harald Welte wrote:
>> Hi!
>>
> 
> 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.

To clarify: "reversed bytes" means that "004000" becomes "400000".

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