Bluetooth Serial Communication Problem with IMX6DL + WL1835

dannypickford · ‎02-18-2015

I've been working on integrating the freescale IMX6DL & bluetooth on the TI WL1835 WILINK8 card on our custom board for the last month or so, and have been running into issues. We have the 802.11 wireless working well but cannot bring up bluetooth.

Primary issue is that I can't seem to get the TI WL1835 to communicate back to the driver the information about the hardware so it can then load the firmware.

The second issue is that I cannot get ldisc to enumerate a 3,000,000 bluetooth speed (prior to loading the firmware) and I have working around this by setting it to 115200.

Working with our hardware engineer we've looped the serial interface all the way back to the input pins on the WL1835 chip itself to valid the pins in the hardware layout and believe we are correct in our device tree pin settings.

I'm working with a yocto project 3.10 & 3.14 kernel, with various TI supplied patches to add device tree support to shared transport, and are using the UIM mechanism to initialize the bluetooth hardware (apparently tested by TI on the imx6sl solo; we're working with the dualite). Our patches are primarily comprised from the work done by Iian Hunter and a few additional patches cherry picked from the ti-wilink kernel.

We're using 4 UARTS on the platform and are only having issues with UART2 currently; which is hooked up to the bluetooth interface on the WL1835.

cat /proc/tty/driver/IMX-uart
serinfo:1.0 driver revision:
0: uart:IMX mmio:0x02020000 irq:58 tx:41063 rx:647 RTS|DTR|DSR|CD
1: uart:IMX mmio:0x021E8000 irq:59 tx:0 rx:0 DSR|CD
2: uart:IMX mmio:0x021EC000 irq:60 tx:1 rx:2234 RTS|DTR|DSR|CD
3: uart:IMX mmio:0x021F0000 irq:61 tx:0 rx:0 CTS|DSR|CD

We're running UIM and are using the shared transport mechanism. Initializing bluetooth via bootup and hciconfig toggles the enable GPIO as expected, but we then receive this shared transport error.

I've included some relevant output below; if anyone has any suggestions it would be greatly appreciated.

GPIO Toggle:

GPIOs 64-95, platform/20a4000.gpio, 20a4000.gpio:
gpio-64 (sysfs ) out lo
gpio-83 (brcm_reg ) out hi
gpio-86 (usb_otg_vbus ) out lo
gpio-90 (kim ) out hi
gpio-95 (sysfs ) out hi

Shared Transport Failure Log:

(stc): st_tty_open (stk) :line discipline installed
(stk) : waiting for ver info- timed out (stk) :kim: failed to read local ver
(stk) :download firmware failed(stk) :ldisc_install = 0
(stc): st_tty_close Bluetooth: st_register failed -22
Can't init device hci0: Input/output error (5)

Relevant DTB snippets:

kim {
compatible = "kim";
nshutdown_gpio = <90>; // GPIO3_26
dev_name = "/dev/ttymxc1";
flow_cntrl = <1>;
baud_rate = <115200>; //<3000000>
//Ran into issues with ldisc connecting at 3M, reverted to chip default 115200.

};

btwilink {
compatible = "btwilink";
};

pinctrl_elarm_uart2: elarm-uart2 {
fsl,pins = <
MX6QDL_PAD_SD4_DAT5__UART2_CTS_B 0x1b0b1
MX6QDL_PAD_SD4_DAT6__UART2_RTS_B 0x1b0b1
MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA 0x1b0b1
MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA 0x1b0b1
>;
};

uart2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_elarm_uart2>;
fsl,uart-has-rtscts;
//fsl,dte-mode;
status = "okay";
};

This error appears to be related to the following code snippet which indicates the driver can't get the version information from the chip so it can send up the appropriate firmware to the device.

/drivers/misc/ti-st/st_kim.c

long st_kim_start(void *kim_data)
{
long err = 0;
long retry = POR_RETRY_COUNT;
struct ti_st_plat_data *pdata;
struct kim_data_s *kim_gdata = (struct kim_data_s *)kim_data;

pr_info(" %s", __func__);
if (kim_gdata->kim_pdev->dev.of_node) {
pr_debug("use device tree data");
pdata = dt_pdata;
} else {
pdata = kim_gdata->kim_pdev->dev.platform_data;
}

do {
/* platform specific enabling code here */
if (pdata->chip_enable)
pdata->chip_enable(kim_gdata);

/* Configure BT nShutdown to HIGH state */
gpio_set_value(kim_gdata->nshutdown, GPIO_LOW);
mdelay(5); /* FIXME: a proper toggle */
gpio_set_value(kim_gdata->nshutdown, GPIO_HIGH);
mdelay(100);
/* re-initialize the completion */
reinit_completion(&kim_gdata->ldisc_installed);
/* send notification to UIM */
kim_gdata->ldisc_install = 1;
pr_info("ldisc_install = 1");
sysfs_notify(&kim_gdata->kim_pdev->dev.kobj,
NULL, "install");
/* wait for ldisc to be installed */
err = wait_for_completion_interruptible_timeout(
&kim_gdata->ldisc_installed, msecs_to_jiffies(LDISC_TIME));
if (!err) {
/* ldisc installation timeout,
* flush uart, power cycle BT_EN */
pr_err("ldisc installation timeout");
err = st_kim_stop(kim_gdata);
continue;
} else {
/* ldisc installed now */
pr_info("line discipline installed");
err = download_firmware(kim_gdata);
if (err != 0) {
/* ldisc installed but fw download failed,
* flush uart & power cycle BT_EN */
pr_err("download firmware failed");
err = st_kim_stop(kim_gdata);
continue;
} else { /* on success don't retry */
break;
}
}
} while (retry--);
return err;
}

eduardgavin · ‎12-22-2015

Hello, we are working in a new module with imx6q using a wilink8 wifi and BT module. We have the same problem with BT.

We are using the 3.14.28 kernel from freescale git with the WiFi drivers from TI, following the steps in TI web:

WL18xx First Time Getting Started Guide (IMX6) - http://processors.wiki.ti.com/index.php/WL18xx_First_Time_Getting_Started_Guide_%28IMX6%29

Updated to R8.6

WiLink8 Release Notes/R8.6 - http://processors.wiki.ti.com/index.php/WiLink8_Release_Notes/R8.6

I have checked the configuration pins and DTS file.

The following error messages appeared after insert btwilink.ko kernel module "modprobe btwilink":

(stc): chnl_id list empty :4

(stk) : st_kim_startroot@imx6dlsabresd:~# (stk) :ldisc_install = 1uim:poll broke due to event 10(PRI:2/ERR:8)

uim:read 1 from in

stall

uim:@ st_uart_config

u(stc): st_tty_open im: signal received, opening /dev(stk) :line discipline installed/ttymxc0

uim:@ set_baud_rate

uim:set_baud_rate() done

uim:Installed N_TI_WL Line displine

uim:begin polling...

(stk) : waiting for ver info- timed out (stk) :kim: failed to read local ver

(stk) :download firmware failed(stk) :ldisc_install = 0uim:poll broke due to event 10(PRI:2/ERR:8)

uim:read 0 from install

uim:@ st_uart_config

(stc): st_tty_close uim:Un-Installed N_TI_WL Line displine

uim:begin polling...

(stk) :ldisc_install = 1uim:poll broke due to event 10(PRI:2/ERR:8)

uim:read 1 from in

stall

....

We are using /dev/ttymxc0 (aka UART1) and observe traffic, but with the errors above.

0: uart:IMX mmio:0x02020000 irq:58 tx:72 rx:42 CTS|DSR|CD

1: uart:IMX mmio:0x021E8000 irq:59 tx:7740 rx:487 RTS|DTR|DSR|CD

2: uart:IMX mmio:0x021EC000 irq:60 tx:0 rx:0 DSR|CD

Any clue or new about this issue?

Best Regards

Eduard

erezsteinberg · ‎05-27-2015

I'm facing the same issue (on 3.10.53)

Were you able to get it working?

dannypickford · ‎06-04-2015

I can get either bluetooth or wireless working individually, but cannot get them both working at the same time reliably. (ie: wireless card loads firmware but then is very unstable in operation).

ivannikolaenko · ‎07-03-2015

Dear Danny,

Could you please provide a step-by-step guide how to get wl18xx working?
We're facing the same issue (3.10.53).

erezsteinberg · ‎07-03-2015

Hi Ivan,

I just wrote a post on WL18xx bring-up -- maybe it will help.

Step-by-step: How to setup TI Wilink (WL18xx) with iMX6 Linux 3.10.53

Regards,

Erez

SergioSolis · ‎07-07-2015

Thank you for posting the information, it is very helpful!

youxinsu · ‎03-29-2015

Hi, Danny,

I have exactly same problem as you have. I use UART4 on IMX6 to connect with WL18xx. With BT only works when rate is set to 460800, the default 3000000 doesn't work.

Also with WLAN_EN enabled BT just doesn't work at all at any rate.

I am using kernel 3.16.0. And I spent sometime port all the patches eyal mentioned in last post to my kernel with device tree enabled for these devices, its still doesn't work.

Regards,

Youxin

eyalreizer · ‎03-30-2015

What is the platform being used here? how is the wilink8 module connected to it?

Especially, how is bt audio out pin connected? Need to make sure we are in the correct mode of operation:

Sense on Reset configuration pins[edit]

Wilink8 has several wake-up options that are entered through sense on reset by 3 IO's of the device(IRQ_WL, UART_DBG_BT, AUD_OUT_BT).
Once BT or WLAN enable bit is set to high the device is checking the state of the lines and wakeup in specific mode.
There are only 2 modes/configurations that are supported by the device - all the rest are prohibited and the end user must verify that there is no option on the system level to enter the prohibited modes.

The supported modes are:
1. Operational mode:

IRQ_WL = 0, UART_DBG_BT = 1, AUD_OUT_BT = 0

Operational mode is set by default using internal pull of WL18xx (90K typical).
2. Debug mode:
WLAN RS232 debug interface/Jtag interface are muxed out to the WL18XX IO's by default, nevertheless this mode is only for debug a 10K resistor pull up place holder on the IRQ line should be placed. It can be applied by the user only in case the debug mode is required:

IRQ_WL = 1, UART_DBG_BT = 1, AUD_OUT_BT = 0

In order to avoid an undefined state of the device the user must be extremely careful when level-shifting those three I/Os to ensure that only those one of the two supported configurations of the device are applied.

Note: For further details, it's strongly advised to review the level shoftin application note pointed by the wilink8 wiki:

WL18xx - Texas Instruments Wiki

Direct Link:

http://processors.wiki.ti.com/images/8/8c/SWRA448.pdf

Best Regards,

Eyal

youxinsu · ‎03-30-2015

Hi Eyal,

Thanks for your reply.

We use kernel mainline 3.16.0-rc7, ported all your patches on top of the TI drivers in this mainline.

Here is the connection settings;

#define MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B

0x29c 0x66c 0x000 0x3 0x0

#define MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B

0x298 0x668 0x934 0x3 0x0

#define MX6QDL_PAD_CSI0_DAT13__UART4_RX_DATA

0x28c 0x65c 0x938 0x3 0x3

#define MX6QDL_PAD_CSI0_DAT12__UART4_TX_DATA

0x288 0x658 0x000 0x3 0x0

pinctrl_uart4: uart4grp {
	fsl,pins = <
		MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B	0x13059
		MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B	0x13059
		MX6QDL_PAD_CSI0_DAT13__UART4_RX_DATA	0x13059
		MX6QDL_PAD_CSI0_DAT12__UART4_TX_DATA	0x13059
		MX6QDL_PAD_SD4_DAT7__GPIO2_IO15	0x13059 /* Snapper: BT_ENn */
	>;
};

IMX6 UART4_TX_DATA connected to UART_RX_WL18xx

IMX6 UART4_RX_DATA connected to UART_TX_WL18xx

IMX6 UART4_CTS connected to UART_CTS_WL18xx

IMX6 UART4_RTS connected to UART_RTS_WL18xx

3: uart:IMX mmio:0x021F0000 irq:61 tx:59246 rx:2643 fe:1 RTS|CTS|DTR|DSR|CD

UART_DBG_BT not connected, according to the document you attached it suppose to be internal pulled.

AUD_OUT_BT not connected

Checked with hardware gays, they believe there is no option on the system level to enter the prohibited modes in our case.

Thanks,

Youxin

eyalreizer · ‎04-01-2015

Hi,

Any chance you can share the host->wilink8 connection part of you target board schematics?

Best Regards,

Eyal

youxinsu · ‎04-01-2015

Hi Eyal, here is the part of wl18xx to host,

Anything missing?

Regards,

Youxin

eyalreizer · ‎04-02-2015

The schismatics look ok. One question regarding cts/rts as you seem to have baud rate issues.

do you have it enabled on the uart you use ("fsl,uart-has-rtscts" in your .dts file)?:

See below snippet from the sabres-sd device tree patch:

+&uart5 {

+ pinctrl-names = "default";

+ pinctrl-0 = <&pinctrl_uart5_1>;

+ status = "okay";

+ /* enable rts/cts usage on uart5 */

+ fsl,uart-has-rtscts;

+};

Best Regards,

Eyal

youxinsu · ‎04-08-2015

Hi Eyal,

We have fsl,uart-has-rtscts; enable in our device tree.

&uart4 {

pinctrl-names = "default";

pinctrl-0 = <&pinctrl_uart4>;

fsl,uart-has-rtscts;

status = "okay";

};

Regards,

Youxin

dannypickford · ‎03-30-2015

On our board the current configuration is the following:

The UART_DGB_BT is padded out to a test point but otherwise unconnected.

We believe the internal pullup on this pin should keep it at a logical 1.

The AUD_OUT_BT is not connected (as per datasheet for unused.)

Based on the internal pulldown, we believe this pin should be 0.

The IRQ_WL is routed through a TXB0108 TI Level Shifter ( http://www.ti.com/lit/ds/symlink/txb0108.pdf ) to the i.MX6 and is under driver control.

We believe this should match the Operational Mode; IRQ_WL=0, UART_DBG_BT=1, AUD_OUT_BT=0.

Are we missing something here?

dannypickford · ‎02-19-2015

I spent the day porting the kernel to the latest freescale linaro kernel and firmware (3.10.53) to see if it would resolve the issue (i.e.: a bug in the imx serial drivers etc.) and this had no effect either. I'm beginning to wonder if the IMX6 IOMUX is not setup correctly.

An additional troubleshooting note is that the kernel driver communicating with the uart does change it to RTS/CTS when hciconfig hci up triggers the gpio enable.

1: uart:IMX mmio:0x021E8000 irq:59 tx:0 rx:0 RTS|DTR|DSR|CD

I dug into the device tree pinctl definitions and they match up.

imx6dl-pinfunc.h

#define MX6QDL_PAD_SD4_DAT5__UART2_CTS_B 0x354 0x73c 0x000 0x2 0x0

#define MX6QDL_PAD_SD4_DAT6__UART2_RTS_B 0x358 0x740 0x900 0x2 0x5

#define MX6QDL_PAD_SD4_DAT7__UART2_RX_DATA 0x35c 0x744 0x904 0x2 0x7

#define MX6QDL_PAD_SD4_DAT4__UART2_TX_DATA 0x350 0x738 0x000 0x2 0x0

These matchup with the freescale board documentation fortunately.

UART2_CTS_B SD4_DAT6 IOMUXC_UART2_UART_RTS_B_SELECT_INPUT

UART2_RTS_B SD4_DAT5 IOMUXC_UART2_UART_RTS_B_SELECT_INPUT

UART2_RX_DATA SD4_DAT7 IOMUXC_UART2_UART_RX_DATA_SELECT_INPUT

UART2_TX_DATA SD4_DAT4 IOMUXC_UART2_UART_RX_DATA_SELECT_INPUT

Which gives us the following with the reversed TI/FS nomenclature.

CTS — UART2_CTS_B SD4_DATA6

RTS — UART2_RTS_B SD4_DAT5

TX_DATA — UART2_TX_DATA SD4_DAT4 —> Reversed TI / FS nomenclature

RX_DATA — UART2_RX_DATA SD4_DAT7 —> Reversed TI / FS nomenclature

Here is some additional information about how the BT card is connected to the imx6 board.

X6QDL_PAD_EIM_D26__GPIO3_IO26 0x40013059/* BT_EN (TI) */

(This pin is connected to i.MX6 pad E24 through a level shifter and into WL1835MOD pin 41)

...

>;

};

pinctrl_elarm_uart2: elarm-uart2 {

fsl,pins = <

MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA 0x1b0b1

(This pin is connected to i.MX6 pad D19 through a level shifter and into WL1835MOD pin 53)

MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA 0x1b0b1

(This pin is connected to i.MX6 pad E18 through a level shifter and into WL1835MOD pin 52)

MX6QDL_PAD_SD4_DAT5__UART2_CTS_B 0x1b0b1

(This pin is connected to i.MX6 pad C19 through a level shifter and into WL1835MOD pin 51)

MX6QDL_PAD_SD4_DAT6__UART2_RTS_B 0x1b0b1

(This pin is connected to i.MX6 pad B20 through a level shifter and into WL1835MOD pin 50)

>;

};

If you have any suggestions on what to try next it would be appreciated.

johnwesley · ‎02-26-2015

Dear Danny,

Did you get that Bluetooth working?

I am also facing same problem but I am using IMX6SL processor where I have connected our hardware as below:

BT_HCI_TX(52)of WL1835 is connected to UART4_RX_DATA
BT_HCI_RX(53)of WL1835 is connected to UART4_TX_DATA
BT_HCI_CTS(51)of WL1835 is connected to UART4_CTS_B
BT_HCI_RTS(50)of WL1835 is connected to UART4_RTS_B

May I also know the hardware is correct ?

But I can't able to get any data could you please help me.

Thanks in advance,
John Wesley.

dannypickford · ‎02-27-2015

John,

I have not yet gotten bluetooth working with the TI chip yet.

The only additional gotcha that might be worth mentioning is that apparently need to be very specific in the order of the enumeration of the GPIO pins, as certain settings reset other gpio pins that you may have already set. I believe the big one is that the CTS pin will reset the RTS pin, so you'll want to ensure the RTS pin is set last when you initialize the serial port.

Check out the last comment in this forum post:

how to configure UART4 with RTSCTS mode on iMX6 ?

Good luck - if I solve this problem I'll do a detailed write up with the patches applied etc.