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

Re: [bluetooth-dev] btduser: hci receive error with 115200 !



Matthias Fuchs wrote:

> Hi,
>
> I noticed the following problem with the current cvs version of the bt
> stack in usermode:
>
> When I use btduser with 57600 baud I do not get any problems !!!
> Everything up to ppp works very fine ... for hours with high (!)
> traffic.
>
> But when I call btduser like this (with 115200 baud):
>
>  ./btduser --server -R -s 115200 -u /dev/ttyS0 -d 192.168.6.2 -D
> 192.168.6.3 -m -e 0
>
> I got problems while receiving data from my Ericsson module (P9A
> firmware).
>
> Bluetooth Control Application
> -----------------------------
> Please reset HW board within 5 seconds <- Is done by hand !
> Running as server
> Running stack in user mode
> Physdev /dev/ttyS0, btdev (not used), speed 115200 baud
> fd_setup speed=57600, flow=1            <- I put this output in fd_setup !!!
> Init stack
> Initiating read thread
> BT SYS: ERROR :hci_receive_data, Bad UART baud rate or trashed data on
> the uart
> BT SYS: ERROR :hci_receive_data, Try reducing uart speed or change IRQ
> setting (PC)
> BT SYS: hci_receive_data, Resetting state machine and trying to resync
> BT SYS: ERROR :hci_receive_data, Bad UART baud rate or trashed data on
> the uart
> BT SYS: ERROR :hci_receive_data, Try reducing uart speed or change IRQ
> setting (PC)
> BT SYS: Initialising Bluetooth Stack
> BT SYS: hci_init, Initialising HCI
> BT SYS: HCI emulator off
> BT SYS: hci_init, Initialising HCI inbuffers [800]
> BT SYS: hci_init, Reading buffer sizes in the module...
> BT SYS: ERROR :hci_receive_data, Discarding 1 bytes and waiting
> forever...
>
> I think this has something to do with flushing the serial port when
> changing the port speed!
> Has anybody a work around ? The error occurs really every time I start
> the application.

One suggestion: If you're using a release tarball make sure the P9A macro is
defined properly. If you're using CVS this macro has been changed to be
CONFIG_BLUETOOTH_SET_BAUDRATE_BLOCKING.

Another suggestion: this is related to my recent email about syncing. If you
modify hci.c hci_receive_data() to simply return when it gets bad uart data
then your stack might successfully resync on the next buffer from the uart &
proceed ok from there after a command timeout.

--gmcnutt


-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com