<?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>Intermittent Watchdog Reset on nRF52832 (NCS v3.1.0) in Dual-Role BLE Device – Suspected BLE Subsystem Deadlock (NCSDK-31528 / NCSDK-30959)</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/127491/intermittent-watchdog-reset-on-nrf52832-ncs-v3-1-0-in-dual-role-ble-device-suspected-ble-subsystem-deadlock-ncsdk-31528-ncsdk-30959</link><description>Background: 
 
 Platform : nRF52832 with nRF Connect SDK (NCS) v3.1.0 
 BLE Roles : The device operates simultaneously as: 
 
 A BLE Central (NUS Client) , connecting to an external peripheral 
 A BLE Peripheral (NUS Server) , being connected by an external</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 18 Mar 2026 13:17:50 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/127491/intermittent-watchdog-reset-on-nrf52832-ncs-v3-1-0-in-dual-role-ble-device-suspected-ble-subsystem-deadlock-ncsdk-31528-ncsdk-30959" /><item><title>RE: Intermittent Watchdog Reset on nRF52832 (NCS v3.1.0) in Dual-Role BLE Device – Suspected BLE Subsystem Deadlock (NCSDK-31528 / NCSDK-30959)</title><link>https://devzone.nordicsemi.com/thread/563570?ContentTypeID=1</link><pubDate>Wed, 18 Mar 2026 13:17:50 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1545d75a-d549-4e09-ae26-2aa15f7e1098</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;1. It is possible to log to noinit RAM and read that RAM after reset. RAM is never explicitly erased, so most likely the RAM content will be valid after the watchdog reset. However, you should add a checksum to verify that the data is intact. You can for instance do this in the watchdog interrupt handler, which gives you a bit of time to copy data to RAM (but not enough time to write to flash).&lt;/p&gt;
&lt;p&gt;2. I would not say it is known to have stability issues. However, there are some corner cases which can lead do deadlocks, as you have referred to. One potential solution worth testing is to enable&amp;nbsp;&lt;code&gt;CONFIG_BT_HCI_ACL_FLOW_CONTROL=y&lt;/code&gt;. You will likely get build warnings with this and need to also adjust up some buffer sizes (as specified by the warnings). It is also a good idea to try increasing&amp;nbsp;&lt;code&gt;CONFIG_BT_BUF_EVT_RX_COUNT&lt;/code&gt;.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>