<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>How to debug BLE timeout (reason = 0x08)</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/92657/how-to-debug-ble-timeout-reason-0x08</link><description>Short description: After establishing a BLE connection between two nRF52840 based boards (both running Zephyr) and starting data transmission (one transfer about every 500 ms), the connection disconnects with reason 0x08 (timeout) 
 
 More detail: 
 System</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 07 Oct 2022 12:38:49 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/92657/how-to-debug-ble-timeout-reason-0x08" /><item><title>RE: How to debug BLE timeout (reason = 0x08)</title><link>https://devzone.nordicsemi.com/thread/389829?ContentTypeID=1</link><pubDate>Fri, 07 Oct 2022 12:38:49 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5de34da6-0834-4ee5-a66e-484858a776cb</guid><dc:creator>Vidar Berg</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;It sounds like you have understood the error correctly. Error 8, or&amp;nbsp;BT_HCI_ERR_CONN_TIMEOUT, is raised by the lower layer of the Bluetooth stack if it stops receiving packets from a connected device for longer than the supervision timeout. And this is the disconnect reason you can expect to see if one of the devices is moved out of range, for instance.&lt;/p&gt;
&lt;p&gt;From other posts you may have seen that excessive drift on the 32 KHz can lead to intermittent connection problems like this. An easy way you can rule out this as a possible root cause is to repeat the test with the &lt;span&gt;&lt;a title="32.768 kHz synthesized from HFCLK (LFSYNT)" href="https://infocenter.nordicsemi.com/topic/ps_nrf52840/clock.html?cp=4_0_0_4_3_1_4#concept_zhp_4vy_2q"&gt;LFSYNT&amp;nbsp;&lt;/a&gt;&lt;/span&gt; clock instead&lt;span&gt; (selected through CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH - you will want to select this on both the repeater and sensor board for this test).&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;/span&gt;&lt;/p&gt;
[quote user=""]&lt;p&gt;The following image shows the SoftDevice log entry from Zephyr when it starts:&lt;/p&gt;
&lt;p&gt;&lt;img style="max-height:240px;max-width:320px;cursor:zoom-in;" alt=" " src="https://devzone.nordicsemi.com/resized-image/__size/640x480/__key/communityserver-discussions-components-files/4/5277.SoftDevice.JPG" /&gt;&lt;/p&gt;[/quote]
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Do you have logging from both boards? I&amp;#39;m basically wondering if you will detect if one of the boards is reset while connected due to an error, etc.. This will almost always lead to a BT_HCI_ERR_CONN_TIMEOUT on the other side of the connection. &lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Best regards,&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Vidar&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>