This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/WL1805MOD: hciattach fails often (often means 1 out of 2) when WiFi is active !

Part Number: WL18xxMOD

Tool/software: Linux

Hello,

We are experiencing a strange issue, when we enable WiFi+Bluetooth ( at the same time)

WiFi operation alone , works , Bluetooth alone works fine. 

BUT When we are using Wifi and we enable Bluetooth (by means of enabling hardware enable pin and attach Bluez via hciattach, after that WiFi is already running and actively connected ! )  at that time hciattach bails out ( literally 1 on 2 hciattach operations works ) 

/usr/sbin/hciattach /dev/ttymxc3 texas -s 115200

hcInitialization timed out.

 

When looking at the serial lines ( with logger , when ever haci attach fails I don't get the '0x04' byte where read_hci_event is waiting on !

COM30 [0004]:  01 01 10 00

Timeout !!!!!

Nothing is rxd from the WL18xx module !

 

At the second hciattach .. all is working fine !

/usr/sbin/hciattach /dev/ttymxc3 texas -s 115200

Found a Texas Instruments' chip!
Firmware file : /lib/firmware/TIInit_11.8.32.bts
Loaded BTS script version 1
texas: changing baud rate to 3000000, flow control to 1

COM30 [0001]: 01
COM30 [0003]: 01 10 00
COM31 [0001]: 04
COM30 [0018]: A5 AA 5A 01 01 10 00 01 36 FF 04 C0 C6 2D 00 FC EC 24
COM31 [0021]: 0E 0C 01 01 10 00 06 00 00 06 0D 00 20 AC 04 0E 04 01 36 FF 00
COM30 [0001]: 84

all working fine!.

At the 3third hciattach it will fail gain , 4th will work , 5th will fail  .. etc etc..

When adding debug code and looking at the logger output in the serial lines ( i must come to the same conclusion 0x04 on the read_hci_event is missing, what should come from the WL18xx module)

REMARK : This is only seen when WiFi is active !!!

Any idea , why this is going wrong in 50% of the cases !

I want to remark ( once more) ,in Bluetooth only operation it always works, and thus never fails !   

Regards

Noel

  • How are resetting and re-initializing for each hciattach?
    Can, you try resetting the BT_EN i.e toggle the BT_EN GPIO two times, with a delay in between them around 10 secs or so, before you try a new hciattach.

    Thanks
  • Hello

    I'm resetting and re-initializing by driving BT_EN ( to disabled) ( kill / abort hciattach, wait 3 seconds) and drive BT_EN (to ENABLE) launch a new hciattach.

    { PS: i've set the hciattach timeout to 3 seconds iso default 10 seconds }

    all works from the first time if wifi is disabled, if wifi is enabled I have to do this TWICE.

    I've tried the 10 second scenario , and for some reason it sometimes works from the first time , and sometimes it does not !

  • Do, you mean it the delay is long between the 2 resets , it did not work?

    We, tried with the below script and it worked fine on AM437x EVM, with WiFi running and pinging a remote device..

    #!/bin/bash
    echo 3 > /sys/class/gpio/export
    echo out > /sys/class/gpio/gpio3/direction
    echo 0 > /sys/class/gpio/gpio3/value
    sleep 1
    echo 1 > /sys/class/gpio/gpio3/value
    for i in {1..10}
    do
    set -x #echo on
    hciconfig hci0 down
    kill -9 `pgrep hciattach`
    kill -9 `pgrep bluetoothd`
    rmmod hci_uart
    rmmod bluetooth
    rmmod serdev
    echo 0 > /sys/class/gpio/gpio3/value
    usleep 1000
    echo 1 > /sys/class/gpio/gpio3/value
    usleep 5000
    echo 0 > /sys/class/gpio/gpio3/value
    usleep 1000
    echo 1 > /sys/class/gpio/gpio3/value
    usleep 5000
    hciattach /dev/ttyS1 texas 3000000
    hcitool scan
    echo "----------------------"
    echo "---iteration:$i Done--"
    echo "----------------------"
    set +x #echo off
    done
  • Yes, it is recommended to reset the BT EN twice, as the above script depicts... I hope this solved your issue..

    Thanks