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

Re: [bluetooth-dev] Ericsson RF Band Seems to Fail

> Hello all:
> I am using the November 2000 bt stack on a NET+ARM (40Mhz) processor.  I
> keep running into problems with my Ericsson development boards from Comtec
> Sigma (http://www.comtec.sigma.se/).
> A successfull HCI connection is made and reported up to the application
> layer (/proc/bt_status reports one connection, with the correct BD_ADDR,
> as
> ACTIVE on both machines...).  But it would seem that the RF communcation
> unceremoniously dies:
> *	Subsequent L2CAP communication fails by timing out
> *	An INQUIRY command from BTD returns AMAZINGLY fast, without any
> reported BDs (INQUIRY worked before we established the connection)
> *	We have used a serial line analyzer to inspect the
> computer<->bluetooth module communication, all seems to be as it should
> be:
> *	The server machine (I am using vocabularly from
> l2cap.c:process_event()) waits for an connect_ind() packet
> *	The client machine keeps sending connect_req()'s, and in fact the
> bluetooth module still communicates HCI NCP data correctly, without any
> apparent malfunction
> Resetting the bluetooth module simply means we have to reestablish the
> communication, and the vicious cycle starts again...
> I have tested the software (previously) between two desktop machines, and
> it
> has worked OK
> The platform where these errors are occurring is a NET+ARM 40MHz embedded
> development board (32MRAM, Linux 2.0.38, RS232 interface to bluetooth
> modules)
> I have turned the necessary debugging messges in l2cap.c and hci.c.  The
> interface does propagate two suspicious messages:  either that the
> REMOTE_NAME query has timed out (LMP timeout) or that there has been an
> Page Timeout (I do not know what this means...).  My understanding is that
> the LMP layer actually resides on the ericsson chipset as firmware; does
> anyone one know if:
> *	There is a way to alter the timeout metric via HCI
> *	If the ericsson chipsets decide to ignore BDs that fail a
> REMOTE_NAME query or other LMP message reponse (this would be long shot,
> but
> it would account for all the symptoms)
> The biggest difference between the two platforms is easily speed (40MHz vs
> 733MHz!); does anyone have experience with the Axis stack on slower
> processors?
> Any suggestions would be appreciated...
> As a final word (if you get this far...):  kudos to the developers
> responsible for the linux bluetooth stack.  For all the sifting I have
> done
> through the code, at best I have found small copy&paste typo errors in
> debug
> messages; although it is a little less reliable on desktops, it certainly
> is
> adequate for getting development work done.
> /*  EMAIL_BEGIN_SIGNATURE ***********************************/
> Keith E. Hellman                             khellman@xxxxxxx.com
> Software Engineer                    Voice: 303.530.8288 x3106
> Penguin Development Team                   
> -
> To unsubscribe from this list: send the line "unsubscribe bluetooth-dev"
> in
> the body of a message to majordomo@xxxxxxx.com

Sent through GMX FreeMail - http://www.gmx.net
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com