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

nrf51822 random disconnection problem

Hi to all,

i am working on a project that in it i want use nrf51822 as a peripheral device. i implemented a code but i have a problem, central(cc2540) and peripheral(nrf51822) randomly disconnect sometime and i do not have any idea to why this problem can occur, can any one that had faced with this problem and solved that share his experience with me to solve this problem??, can the disconnection problem happen because of below reasons:

1- my clock setting is as below: 

#define NRF_CLOCK_LFCLKSRC      {.source        = NRF_CLOCK_LF_SRC_XTAL,            \
                                 .rc_ctiv       = 0,                                \
                                 .rc_temp_ctiv  = 0,                                \
                                 .xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM}
, can clock setting related to disconnection problem and if yes how can i change this part of code to solve the problem.

2- when i receive BLE_EVT_USER_MEM_REQUEST event from below stack i response with this code

case BLE_EVT_USER_MEM_REQUEST:
    err_code = sd_ble_user_mem_reply(m_conn_handle, NULL);
    APP_ERROR_CHECK(err_code);
, as you can see i send null when i receive BLE_EVT_USER_MEM_REQUEST request, can disconnection problem occur because of this part of code??

3-somewhere in the code i use nrf_malloc and nrf_free to allocate memory dynamically and mem_manger module setting is as :

#define MEMORY_MANAGER_SMALL_BLOCK_COUNT 4
#define MEMORY_MANAGER_SMALL_BLOCK_SIZE 32

#define MEMORY_MANAGER_MEDIUM_BLOCK_COUNT 2
#define MEMORY_MANAGER_MEDIUM_BLOCK_SIZE 256
and this setting setted in sdk_config.h, and because lack of memory i did not changed these default values. is soft device use mem_module to allocate memory also?? and can disconnection problem occur because i am using from this resource with softdevice??

the above items was my guesses about disconnection problem.

thanks

Parents
  • Hi,

    Typically you should be able to define DEBUG in your project, and you may be able to set a breakpoint in the assert handler to find if there is any assert. Have you checked if that occurs here?

    What is the disconnect reason? Typically you can find that by checking p_ble_evt->evt.gap_evt.params.disconnected.reason on BLE_GAP_EVT_DISCONNECTED (see ble_hci.h for various codes).

    1. You may try to increase xtal_accuracy to 250ppm in case there is a timing issue on the central side.

    2. Using NULL should not be a problem.

    3. The softdevice does not use heap to allocate memory, I don't think this is the problem. 

    Best regards,
    Kenneth

     

  • thanks for your response, i disabled the encryption to see the packets in the cc2540 based sniffer, see the below screen shot:

    as you can see in the above picture the slave(nrf51822 as peripheral) try to send some thing on the notification char, but the master(cc2540 as central) did not ack the packets and this loop continue for 9sec (configured supervision timeout) and after that both central and peripheral report a disconnection event. the reason could not be signal power and crc check problem because after that disconnection happen peripheral start to advertise and then tow device reconnect to each other. 

    i do not have any idea about this disconnection reason, may be it was because timing problem. can you give me a advice to solve this timeout problem??

    i also attached the ble dump between central and peripheral(you can open it with ti sniffer app)Decrypted_1.psd

    thanks for your response

  • Hi Alireza, 

     

    Kenneth is on vacation so I will take over the case. From your trace, it looked like the central (CC2540) didn't receive the packets from the peripheral after the ATT_ERROR_RESPONSE. I suspect there could be an assert on the central, causing the stack to crash or unable to process more packet, as it kept sending pacets with NESN = 0 , SN = 0 until a timeout. 

    You may need to check the TI chip's code, maybe do some debug or get some more logging from the device. 

Reply
  • Hi Alireza, 

     

    Kenneth is on vacation so I will take over the case. From your trace, it looked like the central (CC2540) didn't receive the packets from the peripheral after the ATT_ERROR_RESPONSE. I suspect there could be an assert on the central, causing the stack to crash or unable to process more packet, as it kept sending pacets with NESN = 0 , SN = 0 until a timeout. 

    You may need to check the TI chip's code, maybe do some debug or get some more logging from the device. 

Children
No Data
Related