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