Disconnection error code 0x3E

[User1321]

A multiperipheral connection to a central, all with custom nordic devices (nRF52840) has been stablished. Comunication and connection work just fine, but after a synchronization method via BLE was added to the system (broadcast timer transmitted from central to all peripherals)  the initial stage of the connection generates the 0x3E error.

It connects and inmediately disconnects again with this error. If at least one peripheral is connected, and a new peripheral wants to connect again, this error does not appear. Only in the first connection to a peripheral. 

I don't believe this is a HW problem because the error appears when the synchronization method was added! 

Is it possible that some parameter needs to be adjusted on central side?

Thanks in advance for your attention. 

[bjorn-spockeli]

Hi User1321, 

the 0x3E disconnect error corresponds to BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED: The Connection Failed to be Established error code indicates that the LLinitiated a connection but the connection has failed to be established

So since you did not have any issues prior to connecting before the synchronization method via BLE was added, then I think its highly likely that there is something in this code that causes the SD to assert or prevents it from finishing the connection establishment.  Does the new synchronization method via BLE handle any BLE_GAP_EVTS or BLE_GATTS_EVTS events ?

Best regards

Bjørn

[User1321]

Hi Nordic,

I'm back into this issue again. Indeed a RADIO event is being used for capturing the time stamp when an event has been received. The synchronization is actually taken from: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/wireless-timer-synchronization-among-nrf5-devices

When no synchronization is running, the connections occur without issue but when the synchronization is enabled, lots (random number) connection/ disconnection events occur before is successful.

You can see the sniffer pictures, between the packets 25819 and 27570, the peripheral is initially transmitting until it is manually restarted, there we can see the attempts for connections until a few seconds later, the connections occurs.

Can you recommend something based on the images shown?

[bjorn-spockeli]

Ok, looking at the sniffer traces it looks to me as the SoftDevice or the application is asserting, triggering a reset. The devices then start advertising/scanning and the cycle repeats.  Are you running the synchronization code in a Timeslot as its done in the blog post?

[User1321]

yes, the implementation of the synchronization is the same as in the blog_post.

[bjorn-spockeli]

Ok, can you debug the application and place a breakpoint in app_error_fault_handler() in app_error_weak.c. We need to find out if the SoftDevice or application is asserting. 

Also make sure that you add DEBUG to your preprocessor definitions. 

Any log output from the application would also be helpful.

Best regards

Bjørn