[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: [bluetooth-dev] CSR kit and bug in axis stack??
it seems our e-mail system has had some problems during last night. Well, it
First question: Have you deactivated the bcsp, the synching and the parity
bit with the PSTOOLS? The axis stack works without parity on the serial
In the stack I had to deactivate the hci_reset() and the
read_ericsson_rev_info(). In init_phys() the baud-rate should be set to
115200 (with fd_setup()). Then leave the baud-rate untouched (with
ericsson-modules the rate is changed in init_stack(), too). It is good to
perform a write_pagescan_activity with parameters 0x20 and 0x20, maybe jut
before the write_scan_enable(). It makes the connection process much more
reliable. Also it is useful to specify a new hardware flag: -i csr for
example. But you have to set this hardware flag also in the hci.c. In
Kernel-Mode this has to be done with ioctl's. I'm working on a solution and
will send a patch to Axis, if it is working well with csr hardware. But
there are some problems.
First the problems with the beta-5 firmware. The inquiry_result_event has a
wrong parameter length field. In the next official version (beta-7) this
will be fixed. (It is also fixed id beta-6, but this is an unofficial
version). Also there could be an error in the number_of_completed_packets
event. Some times its telling me, 140 packets are completed, but the
hardware only has 8 buffers ... I'm not sure, if this as a firmware bug, I
still have to do some testing on it.
Also there is a very big problem with the Axis stack: the bt_buf queue
doesn't work well. The following error occurs with the csr kits and with USB
driver for ericsson kits:
If only one buffer is stored in the bt_buf queue and at least one acl-buffer
in the bluetooth-hardware is free, the acl packet is sent immediately
(that's ok). If the number_of_completed_packets event occurs in this moment,
before the one buffer in the queue is killed, this one buffer is sent twice,
because the event-handling tries to send all remaining buffers in the queue.
This behaviour causes the error message "negative cur_len". (Why has Axis
defined this error message? Is it a known problem ?)
Its quit an ugly error. I don't know a good solution. Maybe the check for
remaining packets can be moved to hci_send_data(). I have tested it, it
seems to work. But what happens, if hci_send_data() isn't called after the
completed_packets event occurs, but there are remaining packets in the
queue? I'm not sure, but in my tests this problem never occurred.
An additional flag for the buffer, which is set on the beginning of the
sending, could be a solution. The check for the remaining packets could
check these flag, too. I'll try to find out, what happens. Maybe one of the
Axis people has a tip for me :-).
I hope, this mail will help you a little bit. Also I hope, Axis has a
solution for the queue problem :-).
[mailto:email@example.com]Im Auftrag von Chervirala Srinivas
Gesendet: Freitag, 22. September 2000 10:04
Betreff: [bluetooth-dev] CSR
I tried to run the Axis Stack with CSR with firmware Beta -5. But when tried
to execute the ReadBD command it is showing
As I am able to run the Same command with Ericsson module and able to do
telnet and ftp over ppp, so I feel there is
nothing wrong in the my AXIS Stack setup.
After updateing the CSR firmware I also checked the functionality of CSR
module with Digianswer's Bluetooth HCI Terminal which is satisfactory.
I run the btd application on client with the following options..
./btd -u /dev/ttyS0 -b /dev/ttyBT0 -r client
Please let me know whether we have to change any code in the AXIS stack and
where I am wrong.
Thank you very much...