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

Re: [bluetooth-dev] BCSP part of the stack not endian-friendly : new status



Helo,

Thank you for your proposition. Of course you are right, I have to modify the function that recieve the response. I've no more messages like "hci_receive_bcsp: Not a GETRESP msg".

But as always with this module, when I modify something, there is something other that begin to have a strange behavior... Here the status :

1) When removing "hci_read_firmware_rev_info" function, the initialisation worked well, and the module was discoverable by other modules

2) Then I corrected "hci_read_firmware_rev_info" to invert bytes because I'm in big endian. I got of couse the error "hci_receive_bcsp: Not a GETRESP msg" because I didn't changed the hci_receive_bcsp funciton. But tue module worked well and was discoverable by other modules

3) Then I corrected hci_receive_bcsp() function. I invert the bytes using le16_to_cpu() function. OK, now I've an initialisation without errors (even without the hardware error that I always had). Here is the logs of initalization :

-- Logs --
BT SYS: Setting btdm_pid (37)
BT SYS: Initialising Bluetooth Stack
BT SYS: Current HW: CSR
BT SYS: Initialising BTMEM [2500 bytes]
BT SYS: Initializing BCSP
BT SYS: BCSP initialized and syncronized
HCI: csr_waitcmdnum
HCI: release_cmd_timer
HCI: process_event: COMMAND_STATUS
BT SYS: Initialising HCI
BT SYS: HCI emulator off
BT SYS: Initialising HCI inbuffers [800]
BT SYS: Reading buffer sizes in HW module
HCI: hci_read_buffer_size
HCI: process_event: COMMAND_COMPLETE
HCI: release_cmd_timer
HCI: process_return_param: READ_BUFFER_SIZE

HW module contains...
8 ACL buffers at 192 bytes
8 SCO buffers at 64 bytes

BT SYS: Reading firmware info in HW module
HCI: hci_read_firmware_rev_info [CSR] BuildID/ChipVer/ChipRev
HCI: release_cmd_timer
HCI: release_cmd_timer
HCI: release_cmd_timer
BT SYS: Host flow control not enabled
BT SYS: M/S switch disabled
BT SYS: Force M/S switch set to 0
BT SYS: Initialising L2CAP
HCI: hci_read_local_bd
HCI: process_event: COMMAND_COMPLETE
HCI: release_cmd_timer
HCI: process_return_param: READ_BD_ADDR
BT SYS: Local bd [00:07:61:00:12:83]
BT SYS: Initialising RFCOMM
BT SYS: Initialising SDP
BT SYS: Init SDP as server
BT SYS: Initialising TCS
BT SYS: Initialising TEST
HCI: hci_write_class_of_device: Service class 0x10, major:0x3, minor:0x0
HCI: hci_write_class_of_device: 2:3:0
HCI: process_event: COMMAND_COMPLETE
HCI: release_cmd_timer
HCI: process_return_param: WRITE_CLASS_OF_DEVICE
HCI: hci_change_local_name: New name: Remora
HCI: process_event: COMMAND_COMPLETE
HCI: release_cmd_timer
HCI: process_return_param: CHANGE_LOCAL_NAME
HCI: hci_write_scan_enable: enable 3
HCI: process_event: COMMAND_COMPLETE
HCI: release_cmd_timer
HCI: process_return_param: WRITE_SCAN_ENABLE
HCI: hci_write_pagescan_activity
HCI: process_event: COMMAND_COMPLETE
HCI: release_cmd_timer
HCI: process_return_param: WRITE_PAGESCAN_ACTIVITY
HCI: hci_set_event_filter
HCI: process_event: COMMAND_COMPLETE
HCI: release_cmd_timer
HCI: process_return_param: SET_EVENT_FILTER
HCI: hci_set_baudrate [CSR] (57600 baud)

-- End logs --

But now, the module can't discover other modules and is no more discoverable by other modules... Why does the behavior change so much when just add a correct firmware reading ?


Now I've something strange in the three cases I mention above. After the initialization ended, I always recieve the message :

"seq out-of-order [exp:3, got:0], send ack"

about every 5 seconds


Have someone already experienced all this problems ? Thank you for any advice that can allow me to go further with this CSR module.


On Fri, 22 Feb 2002 17:31:35 +0100
Peter Kjellerstedt <peter.kjellerstedt@xxxxxxx.com> wrote:

> Probably you need to do use le16_to_cpu() in the hci_receive_bcsp()
> function to get the result in CPU order too.
> 
> //Peter
> 
> > -----Original Message-----
> > From: Alain Paschoud [mailto:alain.paschoud@xxxxxxx.ch]
> > Sent: 22 February 2002 17:28
> > To: Bluetooth-dev
> > Subject: [bluetooth-dev] BCSP part of the stack not endian-friendly ?
> > 
> > 
> > Hi all,
> > 
> > I send an e-mail some days ago saying that after some 
> > commands, the CSR module didn't respond any more. I notice 
> > that this happen only on my embedded device, and not if I use 
> > the module from the PC.
> > After having thought about it, I suspect that the problem is 
> > that the embedded device is in big endian...
> > 
> > An exemple of a command that crashes the module is to read 
> > the firmware version (function hci_read_firmware_rev_info()). 
> > The record that is sent is composed of several 16 bits long 
> > values. And I don't see any management of endian in this function.
> > So I tested to put the function cpu_to_le16 (which swap words 
> > in case of a bid endian system) before I set every field of 
> > the record of type "csr_bccmd". So the part of the function I 
> > modified look like that :
> > 
> >         /* General msg header */
> > 	CSR_SET_LAST(msg, 1); /* first and last segment */
> > 	CSR_SET_FIRST(msg, 1);
> > 	CSR_SET_CH_ID(msg, CSR_CH_ID_BCCMD);
> > 
> > 	/* BCCMD type */
> > 	cmd->type = cpu_to_le16(CSR_MSGTYPE_GETREQ);
> > 	cmd->len = cpu_to_le16(5 + 6);
> > 	cmd->seq = cpu_to_le16(csr_count++);
> > 	cmd->var_id = cpu_to_le16(CSR_CMD_BUILD_ID);
> > 	cmd->status = cpu_to_le16(CSR_STATUS_OK); /* always OK 
> > in GETREQ */
> > 	memset(cmd->payload, 0, 6*sizeof(u16));
> > 
> > 	tmp = send_cmd_block((u8*) &c_pkt, c_pkt.len + 
> > CMD_HDR_LEN + HCI_HDR_LEN, DEFAULT_TIMEOUT);
> > 	if (tmp < 0)
> > 		return tmp;
> > 
> > 
> > Result : The module doesn't crash any more, but sends I get 
> > next thing :
> > 
> > 
> > 
> > BT SYS: Reading firmware info in HW module
> > HCI: hci_read_firmware_rev_info [CSR] BuildID/ChipVer/ChipRev
> > HCI: release_cmd_timer
> > BT SYS: hci_receive_bcsp: Not a GETRESP msg
> > 
> > hci_receive_bcsp (22):
> > 0x01 0x00 0x0b 0x00 0x00 0x00 0x19 0x28 0x00 0x00 0xbc 0x00 
> > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
> > HCI: release_cmd_timer
> > BT SYS: hci_receive_bcsp: Not a GETRESP msg
> > 
> > hci_receive_bcsp (22):
> > 0x01 0x00 0x0b 0x00 0x01 0x00 0x1a 0x28 0x00 0x00 0x01 0x00 
> > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
> > HCI: release_cmd_timer
> > BT SYS: hci_receive_bcsp: Not a GETRESP msg
> > 
> > hci_receive_bcsp (22):
> > 0x01 0x00 0x0b 0x00 0x02 0x00 0x1b 0x28 0x00 0x00 0x65 0x00 
> > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
> > 
> > 
> > 
> > Conclusion : it's now better, the module can respond 
> > something and doesn't crash any more. But it doesn't seem to 
> > have understood my request.
> > 
> > Is there something else that I should swap before to send my 
> > request ? Does someone already use BCSP with a big endian system ?
> > 
> > Any comment will be appreciated.
> > 
> > -- 
> > Alain Paschoud                      SMARTDATA SA
> > alain.paschoud@xxxxxxx.ch         PSE-A
> > http://www.smartdata.ch             1015 Lausanne
> > Phone +41-21-693'84'98              
> > Fax   +41-27-693'84'91              
> > -
> > To unsubscribe from this list: send the line "unsubscribe 
> > bluetooth-dev" in
> > the body of a message to majordomo@xxxxxxx.com
> > 
> 


-- 
Alain Paschoud                      SMARTDATA SA
alain.paschoud@xxxxxxx.ch         PSE-A
http://www.smartdata.ch             1015 Lausanne
Phone +41-21-693'84'98              
Fax   +41-27-693'84'91              
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com