This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

cause UART to crash by transmit data continuously

Our project use 51822 and another MCU stm32 to transmit heart rate data by uart. then 51822 SPP heart rate to smart phone APP. Now, We meet a issue that 51822 UART will crash if coninuously transmit data over several minutes (i.e over 5 minutes) between STM32 and 51822. STM32 UART can send data to 51822 but 51822 UART can't receive it and send ACK to STM32. Even through we re-initialization 51822 UART but it take no effect. if transmit data time less than 3 Minutes the UART seem ok. we call your callback to init UART as below:

 const app_uart_comm_params_t comm_params =
    {
        RX_PIN_NUMBER,
        TX_PIN_NUMBER,
        RTS_PIN_NUMBER,
        CTS_PIN_NUMBER,
        APP_UART_FLOW_CONTROL_DISABLED, //APP_UART_FLOW_CONTROL_ENABLED
        false,
        UART_BAUDRATE_BAUDRATE_Baud57600  
    };
APP_UART_FIFO_INIT( &comm_params,
                       256,     
                       256,     
                       uart_event_handle,
                       APP_IRQ_PRIORITY_LOW,
                       err_code);
 We try to  decrease to  baud rate 38400 from 57600 but it still not fixed it. Another, i find if increase connection interval by modfiy min and max interval range that can delay UART crash time as below:
#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(8, UNIT_1_25_MS)
/*< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(10, UNIT_1_25_MS)

what cause 51822 UART crash?

Parents
  • You're probably overrunning the UART since you don't have flow control on and are using a high bitrate, eventually the softdevice interrupts for long enough the buffer fills, an error is flagged and depending on what the code does when there's an error (look at the code and see) the UART may appear to stop working. Have you checked the ERRORSRC register in the UART when you have this issue to see if any bits are set?

    I doubt the UART has 'crashed', I'm sure it's still working away, but it's in an error condition the code you're using to drive it is not recovering from.

    If you completely re-initialize the UART it should start receiving again, so it rather depends what you mean by 'even though we re-initialize .. ' and what the code you're using does on init if there was an outstanding error.

    High baudrates + no flow control + softdevice isn't a recipe for success. STM32 MCUs support flow control, why don't you use it and make all your problems go away.

  • so have you looked to see if there is an error on the UART when your timeout times out? If so, what is it, have you overrun? Does that code clear any outstanding error, like overrun? Why are you delaying 1/2 a second at the end of the reset as well? Depending on what other things you're doing you may just instantly overrun the buffer again.

    you need to understand what error is on the uart peripheral, whether you're clearing it and you need to look at the uart code to see what it does on overrun to understand why you stop getting data.

Reply
  • so have you looked to see if there is an error on the UART when your timeout times out? If so, what is it, have you overrun? Does that code clear any outstanding error, like overrun? Why are you delaying 1/2 a second at the end of the reset as well? Depending on what other things you're doing you may just instantly overrun the buffer again.

    you need to understand what error is on the uart peripheral, whether you're clearing it and you need to look at the uart code to see what it does on overrun to understand why you stop getting data.

Children
No Data
Related