[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] Trashed UART and how to solve it??
"Johan Magnusson (QIC)" wrote:
> Hi Again!
> The two of the most common UART problems we have had are:
> 1. Bad UART baud rate or trashed data...... (And the waiting forever....)
> 2. Stack just hangs without any error messages
> The first problem must be caused by a lost or corrupt "packet type" byte. The second is probably caused by a lost or corrupt byte anywhere else in the HCI
> packet header, e.g. "data length".
The stack can hang without error messages if the lost byte is in the HCI length field. So these may both be the same problem.
> Could not this problem be solved if HCI checks the header for corrupt commands (e.g. not EVENT or any other) and checks the HCI "data length" with the actual
> data length before sending it to the next layer.
HCI has no way of knowing the "actual length" -- that's what its length field is for (the chunks of data it gets from the lower layer are not gauranteed to be on
any kind of packet boundary. And since there are no CRC checks below RFCOMM it can't check for corruption (personally, I think this is an oversite in the spec).
As I've noted in a different email the best defense against corruption is for HCI to give data right away to the upper layers and give them a chance to detect
errors as early as possible in the byte stream.
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to email@example.com