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

[bluetooth-dev] Problem writing a TTY under the stack.



Hello everyone,

I have a really strange problem while working with the stack, I hope that you may help...

I'm trying to develop a driver that I have to put UNDER the stack. This is the first step on the
long journey to build a virtual bleutooth driver that may be used with any tty based stack out
there...

That means that I'm writing a tty like driver which acts like /dev/ttySx and I connect the Axis stack to this driver.

It works almost fine in USER_MODE but I didn't implement yet to support the kernel mode, it is quite tricky
to support the IOCTL to register the bt stack discipline. If you have any suggestion on how to do that, I would
thank you a lot  but it's not my problem for tonight !

Here is the problem. When my driver has to send a message to the stack I use something like this:

tty->ldisc.receive_buf(tty, (u8 *) data, NULL, len)

If you don't understand this line, you probably can't help me. I'm calling the receive
function of the line discipline above me to send the buffer.

And this works fine. The only problem is that if the data buffer contains a byte with the
value 0x11, this byte is not received by the upper layer ??? I know this sounds crazy but
here is an execution exemple :
 
 

--------------- When it's working 100% correct  it outputs this :
 

[root@localhost]# btduser -m -u /dev/vd
Bluetooth Control Application
-----------------------------
Running as server
Running stack in user mode
Physdev /dev/vd, btdev (not used), speed 115200 baud
Init stack
Initiating read thread

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...
HCI: hci_read_buffer_size

send_cmd_queue,  (4)
   0x01 0x05 0x10 0x00

bt_write_lower_driver  (4)
   0x01 0x05 0x10 0x00    | Data is sent to my tty...
            | Processed, it's a hci_read_buffer_size
data rec :  (14)          | Here is the answer, as a valid event command_complete
   0x04 0x0e 0x0b 0x01 0x05 0x10 0x00 0xff 0x1f 0xff 0xff 0x1f 0x00 0x10

hci_receive_data,  (14)
   0x04 0x0e 0x0b 0x01 0x05 0x10 0x00 0xff 0x1f 0xff 0xff 0x1f 0x00 0x10
HCI: hci_receive_data, WAIT_FOR_PACKET_TYPE
HCI: hci_receive_data, WAIT_FOR_EVENT_TYPE
HCI: hci_receive_data, WAIT_FOR_EVENT_LENGTH

process_event (11)
   0x01 0x05 0x10 0x00 0xff 0x1f 0xff 0xff 0x1f 0x00 0x10
HCI: process_event, COMMAND_COMPLETE
HCI: process_return_param, READ_BUFFER_SIZE

HW module contains...
8191 ACL buffers at 8191 bytes
4096 SCO buffers at 255 bytes

BT SYS: hci_init, Reading firmware revision in the module...
.
.
.
continues without problems...

-----------------------------------------------------------------------------------

--------------- And here is the problem  :
--------------- Let's put 0x11ff ACL packet as the buffer size.
--------------- It means we have to put 0xff 0x11 in the event packet.
----------------------------------------------------------------------------------

[root@localhost vdriver]# btduser -m -u /dev/vd
Bluetooth Control Application
-----------------------------
Running as server
Running stack in user mode
Physdev /dev/vd, btdev (not used), speed 115200 baud
Init stack
Initiating read thread

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...
HCI: hci_read_buffer_size

send_cmd_queue,  (4)
   0x01 0x05 0x10 0x00

bt_write_lower_driver  (4)
   0x01 0x05 0x10 0x00

data rec :  (13) | Yep we only received 13 bytes
                                          here is the missing byte 0x11
                                          |
   0x04 0x0e 0x0b 0x01 0x05 0x10 0x00 0xff 0xff 0xff 0x1f 0x00 0x10

hci_receive_data,  (13)
   0x04 0x0e 0x0b 0x01 0x05 0x10 0x00 0xff 0xff 0xff 0x1f 0x00 0x10

HCI: hci_receive_data, WAIT_FOR_PACKET_TYPE
HCI: hci_receive_data, WAIT_FOR_EVENT_TYPE
HCI: hci_receive_data, WAIT_FOR_EVENT_LENGTH
HCI: hci_receive_data, WAIT_FOR_EVENT_PARAM

.
.
.
|since we are expecting 14 bytes, we wait for
 the last one... and we are stuck....
 

----------------------------------------------------------------------------------------------

The code to generate this event is :

 case READ_BUFFER_SIZE:
  {
 
    MYPRINTK("Read buffer size received.\n");

 
    event.pkt_type = EVENT_PKT;
    event.event_type = 0x0e;  //command complete event
    event.len = 11 ;
    event.data[0] = 0x01;
    event.data[1] = *((u8 *) &c_pkt.opcode);
    event.data[2] = *((u8 *) &c_pkt.opcode+1);
    event.data[3] = 0x00; //succeed
    event.data[4] = 0xff;
    event.data[5] = 0x11; <----------------------- 0x11 and the byte disapear !!
    event.data[6] = 0xff;
    event.data[7] = 0xff;
    event.data[8] = 0x1f;
    event.data[9] = 0x00;
    event.data[10]= 0x10;
 
    tty->ldisc.receive_buf(tty, (u8 *) &event, NULL,event.len + EVENT_HDR_LEN + HCI_HDR_LEN);
 
    break;
  }
 

-------------------------------------------------------------------------------------------------
 
 

My idea is that 0x11 which is b00010001 may be a special flag, a control character or something like that...
In fact as an ASCII character it is "device control 1", anyone know what that means ?
 

I have NO clue on what is going wrong, and since you played with those linde discipline/tty devices
as well, I hope that you have some ideas...

I'm running a 2.2.14 kernel.
I used the tar.gz stack, not the last one from the CVS, but I believe that the stack works fine,
otherwise all the guys with a hardware device would encounter the same problem...

Thanks for reading,

-Laurent