• State Not Answered
  • Replies 3 replies
  • Subscribers 25 subscribers
  • Views 107 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 289842
Options

ble_app_uart peripheral Error 8 (0x8): GATT CONN TIMEOUT

user108225

Hello everyone,

I'm testing the example ble peripheral "UART/Serial Port Emulation over BLE" with SoftDevice S112 nRF5 SDK  v17.1.0. My board is MBN52832DK and i'm using the nRF Connect for Mobile app.

I made a change in the function (uart_event_handle) that handles the data received over UART to use a Python Script that send multiples messages. Now data is relayed to the BLE peer using the Nordic UART Service when the size of the string is 22 bytes.

My objective is to use a Baudrate of 460800 bauds. I started using a slower baudrate (115200) and the communication works well, but when I increase the number of messages or decrease the time inter messages it gets disconnected.

NRF_LOG RTT backend saids:
UARTE: Function: nrfx_uarte_rx, error code:pim NRF_SUCCESS.
<error> app: Fatal error

nRF Connect LOG saids:
Error 8 (0x8): GATT CONN TIMEOUT

What could be the problem? How do i get a better NRF_LOG?

Thanks in advance,

Fernando.

Parents
  • 0

    Hi Fernando,

    The first step should be to add more logging. If you make a debug build you will get the file name, line number and error code printed instead of just "Fatal error". If you are using a SES example project that has "Debug" as a build configuration, just select that. If not, you need to add "DEBUG and "DEBUG_NRF" as defines in your project or Makefile, and test again. What does the log say then? Which function call returns which error code?

    Einar

  • 0 in reply to user7377

    Thank Einar,

    NRF log saids:

    <info> app_timer: RTC: initialized.
<info> app: Debug logging for UART over RTT started.
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<info> app: Connected
<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
<info> app: Data len is set to 0xF4(244)
<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7
<debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 517 bytes.
<debug> nrf_ble_gatt: Updating ATT MTU to 247 bytes (desired: 247) on connection 0x0.
<info> app: Data len is set to 0xF4(244)
<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7
<debug> app: Ready to send data over BLE NUS
<debug> app:  38 39 31 37 36 36 37 30|89176670
<debug> app:  35 33 36 39 39 31 38 38|53699188
<debug> app:  39 31 34 35 34 33      |914543  
<debug> app: Ready to send data over BLE NUS
<debug> app:  30 39 35 33 38 36 39 30|09538690
<debug> app:  39 35 32 30 31 30 34 30|95201040
<debug> app:  39 35 36 39 38 30      |956980  
<debug> app: Ready to send data over BLE NUS
<debug> app:  30 30 30 31 32 39 39 32|00012992
<debug> app:  39 31 35 38 36 33 33 30|91586330
<debug> app:  33 33 32 39 31 33      |332913  
<debug> app: Ready to send data over BLE NUS
<debug> app:  30 30 30 32 39 38 30 38|00029808
<debug> app:  38 34 31 38 33 38 39 31|84183891
<debug> app:  35 36 38 33 32 34      |568324  
<debug> app: Ready to send data over BLE NUS
<debug> app:  30 30 30 33 37 39 34 37|00037947
<debug> app:  31 32 39 32 33 36 32 30|12923620
<debug> app:  34 31 34 35 31 39      |414519  
<debug> app: Ready to send data over BLE NUS
<debug> app:  30 30 30 34 39 32 31 30|00049210
<debug> app:  33 31 35 33 36 38 36 34|31536864
<debug> app:  30 32 35 39 36 35      |025965  
<error> app: ERROR 1 [NRF_ERROR_SVC_HANDLER_MISSING] at /home/proko/nRF5_SDK/nRF5_SDK_17.1.0/examples/MisProgs/ble_app_uart/main.c:540
PC at: 0x00022C2D
<error> app: End of error report

    line main:540 is

    case APP_UART_COMMUNICATION_ERROR:
    APP_ERROR_HANDLER(p_event->data.error_communication);
    break;

  • 0 in reply to user108225

    Hi,

    Thanks, this provides a lot of info. There is an error in the UART transaction, and the error_communication holds the value of the ERRORSRC register. NRF_ERROR_SVC_HANDLER_MISSING is not the right name here, but this maps to 1, which in ERRORSRC is OVERRUN. So there has been an OVERRUN error on the UART, meaning that "A start bit is received while the previous data still lies in RXD. (Previous data is lost.)". So data is coming in faster than it can be processed. The first thing I would consider is using flow control.

Reply
  • 0 in reply to user108225

    Hi,

    Thanks, this provides a lot of info. There is an error in the UART transaction, and the error_communication holds the value of the ERRORSRC register. NRF_ERROR_SVC_HANDLER_MISSING is not the right name here, but this maps to 1, which in ERRORSRC is OVERRUN. So there has been an OVERRUN error on the UART, meaning that "A start bit is received while the previous data still lies in RXD. (Previous data is lost.)". So data is coming in faster than it can be processed. The first thing I would consider is using flow control.

Children
No Data
Related
Terms of service