WL1831MOD: Bluetooth links get aborted very often.

Hello,

No this is not correct, in fact the WLAN-enable pin is NOT ACTIVE. 

This means the WL18xx  where I logged (all data on) has only Bluetooth enabled  (what also means , that no WLAN/Wifi software is active). !

Best Regards

Noel

Hello Noel,

I have went over the logs - and specifically the LSTO - in order to see how come we have a disconnection.

Usually i would expect the timeout counter to go down gradually until a timeout occurs and a disconnect.

i don't see it in this case.

I do have a couple of questions please.

what is the exact scenario? Is it a multiple connection scenario? 

Already have done several connect/disconnect?

How long does it take before it disconnects?

Thanks,

Chen

Hi Chen,

PART 1:
We use one MASTER ( Bluecore4 - CSR-chipset based) this (master ) on RFCOMM can handle up to 7 simultaneous slaves (TX-WL18xx based , or CSR Bluecore2 and / or Bluecore 4 based).

Means, One Master (Bluegiga WT41, CSR chipset based), Multiple Slaves (TI-WL1831 and/or other module type like, WT41/WT11/BT-2022 mix)
All connections with the MASTER are open for ever ( kept open, worst case we send a BT-message every 20 seconds, if nothing to send) .
So a client (Bluetooth slave), opens a connection to the master, and this connection is open , until it gets aborted., if a connection gets aborted ( whatever the reason is) we try to re-open that connection it ASAP !

For example I've opened a CSR bluecore-4 chipset based client connection (Bluetooth slave) , and a CSR-bluecore-2 (Bluetooth slave) based together with a Ti-WL1831MOD rfcomm (Bluetooth slave), connection to the master (CSR bluecore-4 ) at the same time 6 days a go.. both CSR-based connections are still open ( after 6 days) .. the TI-WL1831mod Bluetooth based connection has been aborted ( with low level error 8 translated to 110 - timeout ( on socket) for the application ) multiple times ( more than 200 times , I should count them exactly)

Hi Chen,

I've been logging one ABORTION as requested.

This is the same "Error-8" (on HCI / HCI-LL) and translated to 110-on socket level.

Took me all-most 4 hours to catch this one !  ( but this varies, sometimes less than 20 minutes, often 4 hours or more) .. 

{ just for info, the CSR Bluecore-based chipsets connected to the SAME master as this WL1831MOD, are connected since 2 weeks and did not disconnect or loose a single message, WL1831-MOD connected slaves did abort probably 1000 times or more }

NOTE I have the impression that,  this abortion 'occurs  more' if there is more 'indirect' ( not to this device) air traffic , bluetooth + wifi

I've been logging all I can imagine.

a) HCI-LL-serial bytes ( the bytes on the serial port ( both directions ) 

b) HCI-DUMP (HCI-commands linux logger)

c) TI-logger-tool log's

d) an Eventlog showing a dump-kernel level that shows you what happens on HCI-level.

Those files got quite BIG (even zipped) 

Best Regards

Noel

PS:Sending hardware, is possible but I guess, you will not be able to configure those tests very easily.. maybe a better (more easy) way to provide support is,  providing remote access to A PC that has all the tools installed and that has direct connectivity to one of the Linux-powerd WL18xx devices.

TI-09-05-2018.zip

Hi

Bump, any updates / progress ?

Thank you.

Noel

Hi Chen,

It won't be an easy task to provide you a full-setup/config ( would require multiple units, and lots of software from our side) and on the other hand you can't send random data on those-Bluetooth-links. ( data needs to be in a specific format, in order to be accepted, wat means that you would require lots of background information to get the setup going)

We use multiple MASTER-SLAVE bluetooth connections ( and the ones driven with an ti-18xx based chipset are causing abortion/disconnection issues)

But in order to simulatie / log this "faulty" behavior I have to include ( different pieces of code in different layers of the linux-Bluez-Stack .. etc etc).

Maybe we can provide remote "connection"  ( for example TEAMviewer) to a test-setup here, so you can check things yourself.

But getting more info, will require more code , because at this time , I even provided low-level ( serial logs's ) between the TI-WL18xx and the host CPU ( IMX53 based arm cpu) , I don't think I'm able to provide more 'detailed' info then those raw-logs ( at least at this time.)

Best Regards

Noel

Ps: i've included some pictures ( of one of our boards using a TI-WL18xx and one of our access point that uses WT41 based chipsets, access point can take up to 35 (=7*5) rfcommbased connections).

Pict.zip