nrf51822 random disconnection problem

RE: nrf51822 random disconnection problem

Hung Bui — Fri, 13 Jul 2018 13:33:07 GMT

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.

RE: nrf51822 random disconnection problem

alireza sadeghpour — Fri, 06 Jul 2018 16:24:58 GMT

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)devzone.nordicsemi.com/.../Decrypted_5F00_1.psd

thanks for your response

RE: nrf51822 random disconnection problem

Kenneth — Mon, 02 Jul 2018 14:38:28 GMT

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