• State Answer Suggested
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 42 subscribers
  • Views 129 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3351MOD: integrating CC3351module with NXP processor does not support UART signals derived from USB-UART bridge CP2102

MK
Intellectual 1710 points
Part Number: CC3351MOD
Other Parts Discussed in Thread: TUSB8041

Tool/software:

Hi Team,

Observation:

  • The btti_uart driverprovided by TI appears to be tightly coupled with the native UART interface (directly from the SOM) and is unlikely to work with a UART interface extended via a USB-to-UART converter.
  • The driver expects a corresponding node in the device tree and retrieves configuration details from this node during enumeration. However, since a USB-to-UART serial port is dynamically assigned, it cannot be preconfigured in the device tree. As a result, the binding between the Bluetooth controller and the host controller will not occur with the current implementation.

Experiments Performed:

  1. CC33xx BLE over a USB‑to‑UART link by attaching the serial port to BlueZ from user space (e.g., btattach / hciattach) after enabling BLE on the CC33xx (which is triggered via a Wi‑Fi-side command).

 

The schematics are in the email thread, let me know if you need it.

Best Regards,

Madhurya 

  • 0
    Expert 1391 points

    Correct. The btti driver relies on serdev, which isn't possible to configure with a USB based UART.

    You will need to use btattach, which does work. Note that hciattach/hciconfig are for old versions of the Bluez stack. You should use btattach/bluetoothctl now.

    btattach -B /dev/ttyUSB0 -P h4 &

    bluetoothctl

    There was a bug in this firmware (maybe still exists) that caused another problem with UARTs that do not respond instantly to flow control. I've seen it happen with FTDI based USB/UARTs. The work around was to disable autonomous mode before any BT activity.

    echo "0" > /sys/kernel/debug/ieee80211/wlan0/cc33xx/sleep_auth

    IMHO, this is a firmware bug because it can't handle even one byte after being flowed off even though the datasheet says the UART can handle 16 bytes.

  • 0
    Prodigy 10 points

    performed the below btattach command still getting similar errors


    medos64:/home/devuser#
    medos64:/home/devuser#
    medos64:/home/devuser#
    medos64:/home/devuser# lsusb
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 001 Device 002: ID 0451:8142 Texas Instruments, Inc. TUSB8041 4-Port Hub
    Bus 001 Device 003: ID 0451:8242 Texas Instruments, Inc.
    Bus 001 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 002 Device 002: ID 0451:8140 Texas Instruments, Inc. TUSB8041 4-Port Hub
    medos64:/home/devuser# dmesg | grep tty
    [ 0.512732] 30860000.serial: ttymxc0 at MMIO 0x30860000 (irq = 211, base_baud = 1500000) is a IMX
    [ 0.514332] 30880000.serial: ttymxc2 at MMIO 0x30880000 (irq = 212, base_baud = 5000000) is a IMX
    [ 0.514458] serial serial0: tty port ttymxc2 registered
    [ 0.515158] 30890000.serial: ttymxc1 at MMIO 0x30890000 (irq = 213, base_baud = 1500000) is a IMX
    [ 0.736482] printk: console [ttymxc1] enabled
    [ 3.960641] systemd[1]: Created slice Slice /system/getty.
    [ 3.982766] systemd[1]: Created slice Slice /system/serial-getty.
    [ 5.062214] usb 1-1.2.2: cp210x converter now attached to ttyUSB0
    [ 6.224074] audit: type=1300 audit(1755004382.568:2): arch=c00000b7 syscall=206 success=yes exit=60 a0=3 a1=ffffef9c17b0 a2=3c a3=0 items=0 ppid=541 pid=560 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="auditctl" exe="/usr/sbin/auditctl" subj=unconfined key=(null)
    [ 6.283025] audit: type=1300 audit(1755004382.568:3): arch=c00000b7 syscall=206 success=yes exit=60 a0=3 a1=ffffef9c17b0 a2=3c a3=0 items=0 ppid=541 pid=560 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="auditctl" exe="/usr/sbin/auditctl" subj=unconfined key=(null)
    [ 6.338221] audit: type=1300 audit(1755004382.568:4): arch=c00000b7 syscall=206 success=yes exit=60 a0=3 a1=ffffef9c17b0 a2=3c a3=0 items=0 ppid=541 pid=560 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="auditctl" exe="/usr/sbin/auditctl" subj=unconfined key=(null)
    medos64:/home/devuser# btattach -B /dev/ttyUSB0 -P h4 &
    [1] 715
    medos64:/home/devuser# Attaching Primary controller to /dev/ttyUSB0

    medos64:/home/devuser# hciconfig
    hci0: Type: Primary Bus: UART
    BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
    DOWN
    RX bytes:0 acl:0 sco:0 events:0 errors:0
    TX bytes:8 acl:0 sco:0 commands:2 errors:0

    medos64:/home/devuser# bluetoothctl
    Agent registeredct to bluetoothd...
    [bluetooth]# power on
    No default controller available
    [bluetooth]# scan on
    No default controller available
    [bluetooth]#

  • 0 in reply to Gabriel Searles
    Expert 1391 points

    Yes.

    As I mentioned, if you are using an ftdi USB-UART then you must disable autonomous mode before doing any bluetooth activity.

    Steps required, which must be in this order:
    1) disable autonomous mode by writing 0  to the sleep_auth parameter

    2) Enable Bluetooth by writing 1 to ble_enable parameter

    3) Start the bluetooth stack with btattach