cause UART to crash by transmit data continuously

RE: cause UART to crash by transmit data continuously

baptiste — Mon, 07 Nov 2016 12:04:02 GMT

Hi Leif, I suppose to have the same problem with my uart on NRF51822 after a time (between 30 and 1H30), the nrf51 stop to receive frame on rx (without any error reported by the driver), the frame is sent every 5 minutes. The only way is to reset the chip by the STM32. I would like to know how you resolve your issue ?, because at current time, i've no idea what is the problem, thank you for your help.

RE: cause UART to crash by transmit data continuously

Susheel Nuguru — Mon, 23 Nov 2015 09:03:46 GMT

Hi Leif,

please let us know what and how you fixed it. This thread will be complete when others are able to read what the actual problem was and the solution for it. Thanks for your patience.

RE: cause UART to crash by transmit data continuously

leif — Mon, 23 Nov 2015 02:28:57 GMT

Anyway, still thank you for your reply. The issue have be fixed.

RE: cause UART to crash by transmit data continuously

RK — Sat, 21 Nov 2015 08:32:44 GMT

The UART doesn't crash, it's a piece of hardware. And your last sentence doesn't really make any sense, you can't over-interrupt. The UART demonstrably works for a long time at high baud rates, the Nordic BLE sniffer for instance pumps data out at that kind of baud rate and runs for hours or days at a time.

So you have a software issue and you need to go looking for it. Is APP_ERROR_HANDLER being called? I can't tell from what you wrote whether it is or whether it isn't. If it is, what's the error code, that will tall you what the error is.

RE: cause UART to crash by transmit data continuously

leif — Sat, 21 Nov 2015 08:24:24 GMT

Thanks for your reply. we use SDK8.1.0 ble_app_uart to develop our application. According to RK'advice. we add hardware flow control with baud rate 57600. but UART still crash.when it happened. we can't find no error in ERRORSRC register and if happen error uart_event_handle function will call APP_ERROR_HANDLER function to reset it and it will disconnect .but in fact it not reset and still connect APP all the time. if we change baud rate 9600 from 57600. it is ok by transmiting 20Min data more. but we can't accept it that will take long time to SPP data to APP. i suspect that UART interrupt over often cause the problem when using high baud rate.

RE: cause UART to crash by transmit data continuously

Susheel Nuguru — Thu, 19 Nov 2015 06:17:20 GMT

Not sure if my reply would fit as an answer so i am putting it as a comment. I am assuming that you are using SDK9.0 ble_app_uart as an template. In that example main.c uart_event_handle function is called whenever serial data is received. This function will send a notification by calling ble_nus_string_send. If your UART is receiving data too fast then it is possible that TX buffers are full and your app should handle the error BLE_ERROR_NO_TX_BUFFERS returned by sd_ble_gatts_hvx (ble_nus_string_send).

I also agree with RK, that even without flow control, UART hardware should keep on working, ERRORSRC will be set accordingly and internal buffers will be overwritten, but hardware should not crash as it is tested to be still in valid working state.

app_uart.c library handles all errors by just clearing ERRORSRC register in hardware and calling the registered uart event handler with error code APP_UART_COMMUNICATION_ERROR

RE: cause UART to crash by transmit data continuously

RK — Thu, 19 Nov 2015 06:09:24 GMT

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.

RE: cause UART to crash by transmit data continuously

leif — Thu, 19 Nov 2015 05:08:57 GMT

Thanks for your reply. we set 1S timeout to re-initialize UART. if receiving STM32 UART data it will reset 1S timeout. if not receiving STM32 UART data after 1S time out we will re-initialize UART every 1S. the code as below: function check_reset_uart_time is called in main loop.

void check_reset_uart_time(void) { uint32_t err_code; if((reset_uart_data.reset_uart_state == RESET_RUN) &&(reset_uart_data.reset_uart_timeout == 0) ) {

	reset_uart_data.reset_uart_state = RESET_RUN;
	reset_uart_data.reset_uart_timeout = RESET_UART_TIME_NUM;
    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
    };
	  buffers.rx_buf      = rx_buf;                                                              
      buffers.rx_buf_size = sizeof (rx_buf);                                                    
      buffers.tx_buf      = tx_buf;                                                              
      buffers.tx_buf_size = sizeof (tx_buf);                                                    
      err_code = app_uart_init(&comm_params, &buffers, uart_event_handle, APP_IRQ_PRIORITY_LOW, &APP_UART_UID);   
	  
     APP_ERROR_CHECK(err_code);
     
     Send_Data_Status.Flag.F_SendUploadNextPkt = true;
 nrf_delay_ms(500);

}

} variable APP_UART_UID is the value which first initial UART set . pls check if there was an outstanding error. Thanks.

RE: cause UART to crash by transmit data continuously

RK — Thu, 19 Nov 2015 01:53:23 GMT

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.