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