Facing issue with BLE and UART (NRF5340)

Hi,

I have tested my BLE code and UART code separately, and both worked correctly during individual testing.

However, when integrating both, I encountered an issue with UART. Specifically, when I try to enable UART RX, it triggers the callback for UART RX STOP. Following this, UART RX STOP is called, and then UART RX DISABLING is triggered.

Here is the UART setup code for reference:


    int err = device_is_ready(uart2_dev);
    if (err) {
        LOG_ERR("Device is ready: %d", err);
    }
    
    err = uart_callback_set(uart2_dev, uart_cb, NULL);
    if (err) {
        LOG_ERR("Failed to set UART callback: %d", err);
        return;
        
    }
    
    LOG_INF("uart callback ser %d", err);
    // k_msleep(1000);
    LOG_INF("before uart rx enable");
    err = uart_rx_enable(uart2_dev, rx_buf, sizeof(rx_buf), UART_FIFO_TIMEOUT_MS);
    if (err) {
        LOG_ERR("Failed to enable UART RX: %d", err);
        return;
    }
    LOG_INF("after enbale uart rx");
    LOG_INF("uart rx enable %d", err);
 


This are the LOG.

Advertising successfully started
E: Device is ready: 1
I: uart callback ser 0
I: before uart rx enable
II: UART_RX_STOPPED
I: UART_RX_STOPPED
I: UART_RX_DISABLED
I: UART_RX_STOPPED
: after enbale uart rx
I: uart rx enable 0



For testing, I used the BLE LBS example.

Could you please assist me in resolving this issue?

Thank you.







  • Hello,

    The UART_RX_STOPPED event indicates that an UART error condition was triggered (OVERRUN, FRAMING errorr, etc). You can check the uart_rx_stop_reason to find the exact error condition. That said, I'm not sure why you only experience this with BLE enabled. Are you using any of these pins for UARTE1? https://github.com/nrfconnect/sdk-zephyr/blob/7f8d857bf1f57b07e832d52263beaa23c91fef24/boards/nordic/nrf5340dk/nrf5340_cpuapp_common.dtsi#L45  

    Please try to re-enable UART RX from the UART_RX_DISABLED event to see if the error condition gets triggered over and over again.

  • HI,
    Vidar Berg.

    this are my pin configuration.

    &uart1 {
    	status = "okay";
    	current-speed = <57600>;
    };
    
    &uart0_default {
    	group1 {
    		psels = <NRF_PSEL(UART_TX, 0, 20)>;
    	};
    
    	group2 {
    		psels = <NRF_PSEL(UART_RX, 0, 22)>;
    	};
    };
    
    &uart0_sleep {
    	group1 {
    		psels = <NRF_PSEL(UART_TX, 0, 20)>, <NRF_PSEL(UART_RX, 0, 22)>;
    	};
    };
    
    &uart1_sleep {
    	group1 {
    		psels = <NRF_PSEL(UART_TX, 1, 1)>, <NRF_PSEL(UART_RX, 1, 0)>;
    	};
    };
    
    &uart1_default {
    	group1 {
    		psels = <NRF_PSEL(UART_TX, 1, 1)>;
    	};
    
    	group2 {
    		psels = <NRF_PSEL(UART_RX, 1, 0)>;
    	};
    };


    yes I am using the same pins for UART.


    this is the reenabling code.

        case UART_RX_BUF_REQUEST:
            err = uart_rx_buf_rsp(uart2_dev, rx_buf, sizeof(rx_buf));
            if (err) {
                LOG_ERR("Failed to provide new RX buffer: %d", err);
            }
            break;
        case UART_RX_BUF_RELEASED:
            // LOG_INF("UART_RX_BUF_RELEASED");
            break;
        case UART_RX_DISABLED:
            // k_sleep(K_MSEC(10));
            // k_msleep(10);
            LOG_INF("UART_RX_DISABLED");
            err = uart_rx_enable(uart2_dev, rx_buf, sizeof(rx_buf), UART_FIFO_TIMEOUT_MS);
            if (err) {
            LOG_ERR("Failed to enable UART RX: %d", err);
    
            }
            break;
    case UART_RX_STOPPED:
        enum uart_rx_stop_reason reason = evt->data.rx_stop.reason;
        switch (reason) {
            case UART_ERROR_OVERRUN:
                LOG_INF("UART RX stopped: Overrun error");
                break;
            case UART_ERROR_PARITY:
                LOG_INF("UART RX stopped: Parity error");
                break;
            case UART_ERROR_FRAMING:
                LOG_INF("UART RX stopped: Framing error");
                break;
            case UART_BREAK:
                LOG_INF("UART RX stopped: Break interrupt");
                break;
            case UART_ERROR_COLLISION:
                LOG_INF("UART RX stopped: Collision error");
                break;
            case UART_ERROR_NOISE:
                LOG_INF("UART RX stopped: Noise error");
                break;
            default:
                LOG_INF("UART RX stopped: Unknown reason");
                break;
        }
        break;
        default:
            // LOG_INF("Unknown UART event: %d", evt->type);
            break;
        }



    i am using the UAER1 but named it as uart2 please note this!!
    #define UART2_NODE DT_NODELABEL(uart1)
    static const struct device *const uart2_dev = DEVICE_DT_GET(UART2_NODE);
    



    and I tried to enable the uart_rx_enable in call back and UART_RX_DISABLED triggering continuedly.

    and this are the logs..

     UART RX stopped: Framing error
    I: UART_RX_DISABLED
    I: UART RX stopped: Framing error
    I: UART RX stopped: Framing error
    I: UART RX stopped: Framing error
    I: UART_RX_DISABLED
    I: UART RX stopped: Framing error
    I: UART RX stopped: Framing error
    I: UART RX stopped: Framing error
    I: UART_RX_DISABLED
    I: UART RX stopped: Framing error
    I: UART RX stopped: Framing error
    I: UART RX stopped: Framing error
    I: UART_RX_DISABLED
    I: UART RX stopped: Framing error
    I: UART RX stopped: Framing error
    I: UART RX stopped: Framing error
    I: UART_RX_DISABLED
    I: UART RX stopped: Framing error
    I: UART RX stopped: Framing error
    I: UART RX stopped: Framing error
    I: UART_RX_DISABLED
    I: UART RX stopped: Framing error
    I: UART RX stopped: Framing error




    Please help me to resolve this, I am in final stage of the development.







  • Hi,

    So it seems like you have overlapping pin assignments. The "uart" pins here will be assigned to the network core when the netcore is enabled (enabled automatically when CONFIG_BT is selected). See my answer in this post for how you can remove forwarding of these pins and make them accessible to the appcore instead: RE: nrf5340 Gpio forwarder availibility  

  • Thank you so much for your input. It’s working fine now.

    This isn’t going to interfere with FOTA, is it?

Related