This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf52832 Uart SDK14

Context : I am using a nrf52832 to communicate via UART to a STM32 on a custom board. I've based my work on the Ble nus service example. Main change from the DK is that i don't have an external 32khz so i enabled NRF_CLOCK_LF_SRC_RC

I recently updated the nrf52832 code from SDK12/s132 version 3.0 to SDK14 /s132 version 5.0 because i had issues with some Android devices.

Problem : The BLE part is doing fine now with all the devices that were causing trouble (advertisement, connection, characteristic reading/writing) but the UART part is now unstable.

Hardware flow control is enabled UART_DEFAULT_CONFIG_HWFC, baudrate is set to 115200. On the SDK14, i've tried UART_EASY_DMA_SUPPORT but it's not working, so i switched to using UART_LEGACY_SUPPORT.

At first, uart communication is good at transmitting / receiving but after a while, the connexion hang and i have to reset the whole board. The uart_event_handle doesn't seems to have a APP_UART_COMMUNICATION_ERROR or APP_UART_FIFO_ERROR event but what happen is a high state on the CTS pin of the nrf52. Also, UART_RX_BUF_SIZE value seems to change the delay/latency after which i have this problem.

After debugging i did get those two info from the uart :

EVENTS_CTS 1 EVENTS_NCTS 1 EVENTS_ERROR 0 ERRORSRC 0

Can someone give me hints on what to look after ?

(already saw devzone.nordicsemi.com/.../ and checked the pinout)

EDIT: the high state is on the RTS pin of the nrf52 not the CTS (blue line is RTS, yellow is RX)

image description

  • The nRF5x RTS pin is set high when the nRF5x is unable to receive more bytes, i.e. when buffers are full, and want to stop the sending device sending until you've read the data which already came in so you don't lose it. Are you reading the data which comes in?

    Since you are basing your code on ble_app_uart(BLE NUS example), are you calling app_uart_get()when you get the APP_UART_DATA_READY event ?

  • Yes, i do call app_uart_get in the uart_event_handle fonction that i initialized in :

    const app_uart_comm_params_t comm_params =
    {
        RX_PIN_NUMBER,
        TX_PIN_NUMBER,
        RTS_PIN_NUMBER,
        CTS_PIN_NUMBER,
    APP_UART_FLOW_CONTROL_ENABLED, 
        false,
    UART_BAUDRATE_BAUDRATE_Baud115200
    };
    
    APP_UART_FIFO_INIT( &comm_params,
                       UART_RX_BUF_SIZE,
                       UART_TX_BUF_SIZE,
                       uart_event_handle,
    		APP_IRQ_PRIORITY_LOW,
                       err_code);
    

    and in the uart_event_handle :

    void uart_event_handle(app_uart_evt_t * p_event)
    {
    	uint8_t serial_char;
    	uint16_t i;
    
        switch (p_event->evt_type)
        {
        case APP_UART_DATA_READY:
    
    			if(app_uart_get(&serial_char) == NRF_SUCCESS)
    			{
    ...
    
  • What pins are you using for UART?

    Does it make any difference if you set the priority to APP_IRQ_PRIORITY_HIGH ?

    Do you have UART0_CONFIG_USE_EASY_DMA set to 1 in sdk_config.h ?

    Did you have this issue when you used "SDK12/s132 version 3.0" ?

    Does it make any difference if you turn off the nrf_log module ? I.e. set NRF_LOG_ENABLED to 0 in sdk_config.h ?

    Have you done the migration for the nrf_log ? See here.

  • What pins are you using for UART?

    #define RX_PIN_NUMBER  6
    #define TX_PIN_NUMBER  5
    #define CTS_PIN_NUMBER 7
    #define RTS_PIN_NUMBER 8
    #define HWFC           true
    

    Does it make any difference if you set the priority to APP_IRQ_PRIORITY_HIGH ? No difference

    Do you have UART0_CONFIG_USE_EASY_DMA set to 1 in sdk_config.h ? No, it's set to 0

    Did you have this issue when you used "SDK12/s132 version 3.0" ? No i didn't have the problem. The main change i've done for the migration from the sdk 12 of the program concern BLE functions.

    Does it make any difference if you turn off the nrf_log module ? I.e. set NRF_LOG_ENABLED to 0 in sdk_config.h ? NRF_LOG_ENABLED is already set to 0

    Have you done the migration for the nrf_log ? No i didn't (i will look to it)

  • I'm still struggling with this problem and could really use some guidance on the topic :-(

Related