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