Bluetooth using RSocket - sending data

[VigenIssahhanjan]

Hello,

I use the following function for sending data over Bluetooth: void Send(const TDesC8& aDesc,TUint someFlags,TRequestStatus& aStatus,TSockXfrLength& aLen);

It works just fine: aLen always have the sent length (but you should not delete the aDesc until the RunL is called), except the situations when I try sending 100 times 10 kB buffers very fast. Then on some point the Bluetooth is simply stuck - no event comes that the data is sent. And on recieving side one can see, that data was sent only partially. And nothing happens. Interesting is that when I disconnect from the recieving side, phone does recieve the Disconnect event! :-| This is a complete mistery now: when I put a 100 ms timeout with User::After(100), then I can send this data - but this is not a good solution.

What I think is there buffer overflow appears in bluetooth controller on the phone. And bluetooth transmitter stops workin, or something like that. And RunL function is being called before the data was physically sent - this is not good at all!!!

So, how can I avoid this kind of behaviour? Are there any HCI or some low-level protocol commands to verify is transmitting buffer empty or not?

Thank you in advance,
Vigen

[skornel]

I have seen the same behavior on two different phone models, both from the same manufacturer (I won't give their name). The only solution I found was the same as yours: User::After(). However, I was able to get by with a wait of only 20 milliseconds instead of 100.

During my debugging, the problem seemed to be that once BT encountered the problem (in the Send()), it never changed the I/O status; it was always reported as "pending" and it never completed. I believe that you found the same behavior.

That's all I can add.

[VigenIssahhanjan]

Nokia has officialy responded in one post on this forum, that there's a problem with RFCOMM protocol on 6600 and 6630 phones (or on Series 60 - not sure, but theses phones are for sure). The problem is that RFCOMM cannot send over 512 bytes at a time on these phones (I guess, they were talking about RSocket::Write(...) function), and he adviced using L2CAP.

Now I use L2CAP and I can send 672 bytes at a time, but this amount comes from here:
iSocket.GetOpt(KL2CAPGetOutboundMTU, KSolBtL2CAP, KMaxTransmitMtu); //iSocket must be connected over L2CAP protocol to some device
After call KMaxTransmitMtu = 672 bytes. And after every Write(...) call, when I get the iStatus (in RunL or after User::WaitForRequest), I can be sure, that I've sent 672 bytes of data.

Good luck.
Vigen

[simo.salminen]

This bug seems to be related to RFCOMM credit based flow control. When one uses Socket.Write when credits are low, the low level bluetooth driver seems to get stuck. This can be fixed by monitoring the credit count, and only send when there are "plenty" credits left.

This problems occurs at least in 6630 and 7610.

Following work-around seems to fix the prob:

	while (1)
		{
		TInt credit;
		iSocket.GetOpt(KRFCOMMGetTransmitCredit,  KSolBtRFCOMM, credit);
		if (credit > 10)
			{
			break;			
			}
		User::After(200);
		}
        iSocket.Write(aData, iStatus);

[simo.salminen]

followup: this bug seems to be triggered when using big buffer in Write (over 6kb seems to cause buggage). 2-4 kb should be ok.

[william_j]

No, this have happened also with small buffers too.