Bluetooth UART connection timing out between iMX8M and 88W8987

[acosara]

We have a Murata 1ZM module (using the NXP88W8987) connected to an i.MX 8M. Running the recommended BT initialization code, we get timeouts after the first hci command:

root:~# hciattach ttymxc1 any 115200 flow

Setting TTY to N_HCI line discipline

Device setup complete

root:~# [ 125.961309] Bluetooth: hci0: command 0x1003 tx timeout

[ 127.977303] Bluetooth: hci0: command 0x1001 tx timeout

[ 129.993300] Bluetooth: hci0: command 0x1009 tx timeout

We found a brute force mechanism to keep the connection actives, but it's not a viable permanent solution. We can use this script to keep initializing the BT connection, otherwise the connection is lost after a while. The critical part to get even this to work is to add a 15 seconds delay between steps 3 and 4 below. If it's lower than 15 seconds, we still get failures pretty often. Here's the script we used:

#!/bin/bash
###
# This script is used for configuring the BT module

echo "*** Step 1 ***"
modprobe moal mod_para=nxp/wifi_mod_para.conf
echo "*** Step 2 ***"
ifconfig mlan0 up

echo "*** Step 3 ***"
hciattach /dev/ttymxc1 any 115200 flow

sleep 15

echo "*** Step 4 ***"
modprobe moal mod_para=nxp/wifi_mod_para.conf
echo "*** Step 5 ***"
ifconfig mlan0 up

echo "*** Step 6 ***"
hciattach /dev/ttymxc1 any 115200 flow

sleep 2

echo "*** Step 7 ***"
hciconfig hci0 up
echo "*** Step 8 ***"
hcitool -i hci0 cmd 0x3f 0x0009 0xc0 0xc6 0x2d 0x00
echo "*** Step 9 ***"
killall hciattach
echo "*** Step 10 ***"
hciattach /dev/ttymxc1 any -s 3000000 3000000 flow

echo "*** Step 11 ***"
hciconfig hci0 up
echo "*** Step 12 ***"
hciconfig hci0 piscan
echo "*** Step 13 ***"
hciconfig hci0 noencrypt

I have attached the schematic for how the i.MX8 is connected to the 1ZM as well as Wireshark logs of the connection failures. WiFi is working fine. There's also a scope capture of the CTS (blue) and RTS (red) signals on the UART that indicate the 88W8987 is responding to initialization. The scope capture was taken from U-boot, through Linux boot and then running the script with no delay between steps 3 and 4.

Any insight into what might be causing the connection to drop and what we can do to prevent the drop from happening?

[acosara · Accepted solution]

We just managed to figure it out in the meantime. 

While attempting to debug/recover I noticed the following process running:

 663 root      2344 S    /sbin/agetty -8 -L ttymxc1 115200 linux

Port ttymxc1 is the one we’re trying to use for the Bluetooth module, but it also seems to be set up for Linux.  This happens to be the one used for the console on the NXP EVK.  It shows up even when the Bluetooth initialization works, but perhaps it is benign most of the time.

  672 root      2344 S    /sbin/agetty -8 -L ttymxc1 115200 linux

  691 root      2384 S    hciattach /dev/ttymxc1 any -s 3000000 3000000 flow

If we disable the conflicting service, like this, BT works as it should:

>root@spencer-gen2:~# systemctl disable serial-getty@ttymxc1.service
root@spencer-gen2:~#
root@spencer-gen2:~# systemctl status serial-getty@ttymxc1.service
* serial-getty@ttymxc1.service - Serial Getty on ttymxc1
     Loaded: loaded (/lib/systemd/system/serial-getty@.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
http://0pointer.de/blog/projects/serial-console.html
root@spencer-gen2:~#

[ocourson]

Dear @acosara 

Could you please provide the following details on your setup ?

1/ which i.MX8 variant are you using ? (8MQ, 8Mmini, 8Mnano, etc)

2/ which SW version are you using ? (uname -a command output)

3/ Are you using the M.2 board from Embedded Artists for Murata 1ZM module ?

4/ How are you connecting the 1ZM SDIO and UART signals to the i.MX board ?

Regards,

Olivier