[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bluetooth-dev] Trashed UART and how to solve it??

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

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. If an error is found then the whole HCI in-buffer is cleaned and HCI starts scanning for the beginning of a new 
HCI packet.

This means that the whole HCI packet, and maybe the next packet will be lost every time there is an UART error, but that must be better than a stalling stack??
If higher layers can handle error checking and re-sending (as in our case TCP/IP) this would not any longer be a problem, or would it?

Am I right? Have I understood anything at all?? Would this work??????

Well, well... merry christmas to you all
Johan & Alexander
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com