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.

CC2340R5: BLE stack impacting UART

Part Number: CC2340R5

Tool/software:

Working with BLE stack and UART0 simultaneously on Zephyr. If I use just UART0 I can see the data BLE FW sends to outside. Once bt_enable() call is done I don't see any data from UART0. Does bt_enable() affect somehow the UART0?

After debugging I've identified the function that does affect the UART IO functionality.

This is BLE_ServicesInit() function that is a part of ble_controller.a or ble_peripheral_controller.a library.

Could you please investigate why it is affecting the UART?

  • Hello Brian,

    Thanks for reaching out.

    Are you using an out of the box example we can use as main reference to reproduce?

    Have you done modifications to the device tree or pins configuration?

    BR,

    David.

  • David,

    I am double checking the exact project that the customer is running - I believe it is a slightly modified version of our OOB but will confirm.

    We did do some early debugging and tried swapping the UART port to avoid possible resource conflict, but the issue persisted regardless of what pins the UART is muxed to.

    This is being run on a CC2340 launchpad.

  • David,

    The project in question is not a generic project. It is our FW Zephyr based sources. They developed it for another BLE dongle that is non-TI powered. But it works well.

    But in any cases scenario is:

    1. Initialize the UART
    2. Send the data over UART to PC - data received on PC
    3. Initialize the BLE stack with bt_enable() call.
    4. Send the data over UART to PC - data not received on PC
  • Hello Brian,

    We will try to reproduce this on our side, could you please specify what example they are basing of?

    BR,

    David.

  • David, they were able to reproduce the issue on the beacon app. 

    To get it 100% reproducible please comment out the uart_tx call in main() function and leave it uncommented in bt_ready() callback.

    Uart_tx stops working before callback is invoked by bt_enable().

    Logging works properly. If CONFIG_LOG is enabled.

    I can see the messages after bt_enable() is invoked.

    /* main.c - Application main entry point */

     

    /*

    * Copyright (c) 2015-2016 Intel Corporation

    *

    * SPDX-License-Identifier: Apache-2.0

    */

     

    #include <zephyr/types.h>

    #include <stddef.h>

    #include <zephyr/sys/printk.h>

    #include <zephyr/sys/util.h>

     

    #include <zephyr/bluetooth/bluetooth.h>

    #include <zephyr/bluetooth/hci.h>

     

    #include <zephyr/kernel.h>

    #include <zephyr/device.h>

    #include <zephyr/devicetree.h>

    #include <zephyr/drivers/uart.h>

     

    #define DT_DRV_COMPAT zephyr_bt_hci_entropy

     

    #define DEVICE_NAME CONFIG_BT_DEVICE_NAME

    #define DEVICE_NAME_LEN (sizeof(DEVICE_NAME) - 1)

     

    /*

    * Set Advertisement data. Based on the Eddystone specification:

    * https://github.com/google/eddystone/blob/master/protocol-specification.md

    * https://github.com/google/eddystone/tree/master/eddystone-url

    */

    static const struct bt_data ad[] = {

    BT_DATA_BYTES(BT_DATA_FLAGS, BT_LE_AD_NO_BREDR),

    BT_DATA_BYTES(BT_DATA_UUID16_ALL, 0xaa, 0xfe),

    BT_DATA_BYTES(BT_DATA_SVC_DATA16,

    0xaa, 0xfe, /* Eddystone UUID */

    0x10, /* Eddystone-URL frame type */

    0x00, /* Calibrated Tx power at 0m */

    0x00, /* URL Scheme Prefix http://www. */

    'z', 'e', 'p', 'h', 'y', 'r',

    'p', 'r', 'o', 'j', 'e', 'c', 't',

    0x08) /* .org */

    };

     

    /* Set Scan Response data */

    static const struct bt_data sd[] = {

    BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN),

    };

     

    #define GPSP_SERIAL_NODE DT_ALIAS(uart0)

    static const struct device* gpsp_serial = DEVICE_DT_GET(GPSP_SERIAL_NODE);

     

    static void bt_ready(int err)

    {

    char addr_s[BT_ADDR_LE_STR_LEN];

    bt_addr_le_t addr = {0};

    size_t count = 1;

     

    uart_tx(gpsp_serial, "Hello world#2\r\n", 15, SYS_FOREVER_US);

     

    if (err) {

    printk("Bluetooth init failed (err %d)\n", err);

    return;

    }

     

    printk("Bluetooth initialized\n");

     

    /* Start advertising */

    err = bt_le_adv_start(BT_LE_ADV_NCONN_IDENTITY, ad, ARRAY_SIZE(ad),

    sd, ARRAY_SIZE(sd));

    if (err) {

    printk("Advertising failed to start (err %d)\n", err);

    return;

    }

     

    /* For connectable advertising you would use

    * bt_le_oob_get_local(). For non-connectable non-identity

    * advertising an non-resolvable private address is used;

    * there is no API to retrieve that.

    */

     

    bt_id_get(&addr, &count);

    bt_addr_le_to_str(&addr, addr_s, sizeof(addr_s));

     

    printk("Beacon started, advertising as %s\n", addr_s);

     

    uart_tx(gpsp_serial, "Hello world#3\r\n", 15, SYS_FOREVER_US);

    printk("Hello world#3\n");

    }

     

    int main(void)

    {

    int err;

     

    const struct uart_config config = {

    .baudrate = 115200,

    .parity = UART_CFG_PARITY_NONE,

    .stop_bits = UART_CFG_STOP_BITS_1,

    .data_bits = UART_CFG_DATA_BITS_8,

    .flow_ctrl = UART_CFG_FLOW_CTRL_NONE

    };

     

    if (!device_is_ready(gpsp_serial)) {

    return false;

    }

     

    if (uart_configure(gpsp_serial,

    &config) != 0) {

    return false;

    }

     

    uart_tx(gpsp_serial, "Hello world#1\r\n", 15, SYS_FOREVER_US);

     

    printk("Starting Beacon Demo\n");

     

    /* Initialize the Bluetooth Subsystem */

    err = bt_enable(bt_ready);

    if (err) {

    printk("Bluetooth init failed (err %d)\n", err);

    }

    return 0;

    }

     

     

     

    Prj.cfg

    CONFIG_BT=y

    CONFIG_LOG=n

    CONFIG_CONSOLE=n

    CONFIG_UART_CONSOLE=n

    # CONFIG_BT_LL_SW_SPLIT=y

    CONFIG_BT_DEVICE_NAME="Test beacon"

    CONFIG_MAIN_STACK_SIZE=1536

    CONFIG_UART_ASYNC_API=y

    CONFIG_UART_INTERRUPT_DRIVEN=y

    CONFIG_UART_CC23X0_DMA_DRIVEN=y

    CONFIG_UART_EXCLUSIVE_API_CALLBACKS=n

    CONFIG_UART_USE_RUNTIME_CONFIGURE=y

  • Hello Brian,

    i will try this on my end and let you know!

    Best Regards,

    Tarek

  • Hello,

    I was able to replicate the issue on my end. I have reached out to R&D to comment. Moving this thread to email.

    Best Regards,

    Tarek