Maybe 0x0 is a hardware processed escape sequence. In that case
you'd have to find the sequence that escapes the escape. Just a idea.
-- K

2010/3/21 Harald Welte <laforge@gnumonks.org>
Just another intermediate update:

1) I've pushed my current debugging code to the uart-debug branch

  Simply run osmocon + layer23 and the hello_world.bin image.  layer23
  will send a 62 byte sized HLDC message every 10 seconds to the phone,
  and various instances of the code will print what they see.  The
  payload of the packet is supposed to be
       0a 00 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07
             00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07
             00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07
             00 01 02 03 04 05 06 07 00 01 02 03 04 05

  but what the firmware sees is:
       0a 00       02 03 04 05 06 07       02 03 04 05 06 07
                   02 03 04 05 06 07       02 03 04 05 06 07
                   02 03 04 05 06 07       02 03 04 05 06 07
                   02 03 04 05 06 07       02 03 04 05

  So as you can see, every '00 01' sequence has been chopped out,
  despite 10ms delays between the characters. If you change the
  payload to not include zero-bytes, all bytes are received fine.

2) Enabling various misc UART interrupt sources and checking for error
  conditions in LSR does not help

Regards,
       Harald
--
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                 (ETSI EN 300 175-7 Ch. A6)