https://devzone.nordicsemi.com/f/nordic-q-a/38460/thread-dynamic-multiprotocol---assertion-at-radioreceiveWhile testing and debugging our current state of development, sometimes our devices go totally offline (thread visible via mqtt-sn last will, no ble advertising). I found out that the assert after RadioReceive in Openthreads mac.cpp -&gt; Mac::BeginTransmiten-USTelligent Community 13Tue, 04 Dec 2018 17:18:59 GMThttps://devzone.nordicsemi.com/thread/160258?ContentTypeID=1Tue, 04 Dec 2018 17:18:59 GMT137ad170-7792-4731-bb38-c0d22fbe4515:e2b9edc0-865a-430c-975b-fbe2c72fa9b6Marco Sterbik<p>Hello Lukasz,</p> <p>sorry for the very late answer, but I wasn&#39;t able to test this for a while (and the workaround did really well).</p> <p>But finally I can say - this solves it as well for us!</p> <p>Thank you very much for your efforts!</p> <p>Cheers</p> <p>Marco</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/154575?ContentTypeID=1Thu, 25 Oct 2018 20:08:39 GMT137ad170-7792-4731-bb38-c0d22fbe4515:5437cf2f-864f-4ef6-9d42-758e4fc344b6Lukasz Duda<p>Hello Marco,</p> <p>Can you please try the current master branch? <a href="https://github.com/openthread/openthread/pull/3203">Fix</a> has been just merged there.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/151037?ContentTypeID=1Mon, 01 Oct 2018 16:08:50 GMT137ad170-7792-4731-bb38-c0d22fbe4515:4e66c424-730a-41b1-a623-81f5f45d60a0Marco Sterbik<p>Hello Lukasz,</p> <p>thank you very much for the workaround - I will test it asap (the time hanging in there won&#39;t be a problem for now).</p> <p>And glad to hear that I found a *real* bug ;-)</p> <p></p> <p>Should I keep this open until the final fix is available?</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/151005?ContentTypeID=1Mon, 01 Oct 2018 14:04:06 GMT137ad170-7792-4731-bb38-c0d22fbe4515:ddae17d5-ce95-4b9e-994d-5db647d05e2fLukasz Duda<p>Hello Marco, congratulation, it seems you have found a bug!</p> <p>Unfortunately our long stress tests did not cover this. We are going to work on final fix which will be contributed to nRF IEEE 802.15.4 radio driver soon, and most likely released soon in minor version of SDK.</p> <p>In meanwhile i have a request to you to test a temporary workaround. Could you please modify this line:</p> <p><a href="https://github.com/openthread/openthread/blob/master/examples/platforms/nrf52840/radio.c#L329">https://github.com/openthread/openthread/blob/master/examples/platforms/nrf52840/radio.c#L329</a></p> <p>to something like that:</p> <p><pre class="ui-code" data-mode="c_cpp">// Change this: result = nrf_802154_receive(); // With this: while ((result = nrf_802154_receive()) != true);</pre></p> <p>The idea of workaround is to try to call nrf_802154_receive() function until it succeeds. The downside of this solution is that once/twice per day MCU will need to hang for maximum of 2-5ms.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/150954?ContentTypeID=1Mon, 01 Oct 2018 12:11:02 GMT137ad170-7792-4731-bb38-c0d22fbe4515:d3b3aff8-5917-4c74-905b-eb9eda042581Marco Sterbik<p>Hello Lukasz,</p> <p>sorry, the commit mentioned above was from our internal fork (we changed the MAX_CHILD property to 32 for our tests). The &#39;real&#39; opentread commit id is&nbsp;<strong>c4f44ae0cae10fb09990435a7e74024b9717dd4b</strong></p> <p>Sorry for the confusion and thank you for your efforts.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/150943?ContentTypeID=1Mon, 01 Oct 2018 11:47:31 GMT137ad170-7792-4731-bb38-c0d22fbe4515:c846ae93-6032-4b65-8c99-0e5403813375Lukasz Duda<p>Hello Marco,</p> <p>Thank you for detailed answer. We are currently looking at this problem. Unfortunately i cannot find OpenThread commit which you listed above.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/150360?ContentTypeID=1Wed, 26 Sep 2018 04:59:45 GMT137ad170-7792-4731-bb38-c0d22fbe4515:09e8aeed-4c9d-4793-bd72-8ba97157e1eeMarco Sterbik<p>Helo Lukasz,</p> <p>thanks for the hint with the new sdk - I will definitely try it asap (hopefully next week or so).</p> <p>To the problem at hand (openthread commit I&#39;m looking at is&nbsp;71e873e2e43ee08a01547839698c602abd3973e6):</p> <p>The assertion happens in in <strong>mac.cpp</strong> of openthread in the Function <strong>BeginTransmit</strong> at line 1229 after the call to&nbsp;<strong>RadioReceive</strong>.</p> <p>When digging deeper and deeper into RadioReceive I ended in&nbsp;<strong>nrf_802154_core.c</strong> in the function&nbsp;<strong>nrf_802154_core_receive</strong> which returned at the evaluation of the result from&nbsp;<strong>critical_section_enter</strong>.</p> <p>Basically this whole handling seems fine to me, but my problem is the handling of assert - <strong>otPlatAssertFail</strong> isn&#39;t implemented as far as I can tell (so it falls back to the endless while-loop in <strong>debug.hpp</strong>)&nbsp;and I&#39;m absolutely not sure how to implement it there in a way that will work fine for this event without interfering with all the other stuff.</p> <p>Hope this narrows it a bit down for you.</p> <p>As for the advertising interval - we won&#39;t use such a small one in the final application - this was just for testing and trying to reproduce this issue faster - and it dose it&#39;s job ;-)<br />The final application will advertise closer the 1000ms or something like that - so the probability of this happening will get smaller, but I&#39;d like it to be eliminated ;-)</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/150235?ContentTypeID=1Tue, 25 Sep 2018 11:43:58 GMT137ad170-7792-4731-bb38-c0d22fbe4515:cf6c1bfa-68d3-4a3e-bc91-c354b7de2487Lukasz Duda<p>Hello Marco,</p> <p>First of all, we have released yesterday the new version of nRF5 SDK for Thread and Zigbee 2.0.0. I encourage you to try it out. It contains fixes for RC oscilator in multiprotocol solution.</p> <p>Can you elaborate more on the problem that you see.I&#39;m confused if you see an assert or you identified infinite loop. Can you point me the file and line of the code where it asserts?</p> <p>Advertising interval of 20ms seems to be to aggressive, i suggest you to change it again to 100ms.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/150160?ContentTypeID=1Tue, 25 Sep 2018 06:55:55 GMT137ad170-7792-4731-bb38-c0d22fbe4515:f8288416-9e47-4d27-a3ae-0361aee86ac7Marco Sterbik<p>Actually there was no connection active in my test - th edevice was only advertising with a 16 Byte full name and the flags in advertising and additionaly a 128 Bit Service UUID in scan-response. The advertising interval was 100ms and for testing I decreased it to 20ms which lead to a worse behaviour (the error occured faster).</p> <p>I currently don&#39;t have any BLE trace of the application.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/149816?ContentTypeID=1Fri, 21 Sep 2018 11:40:37 GMT137ad170-7792-4731-bb38-c0d22fbe4515:7ea9e75b-3213-4f6b-b765-de9164f03732haakonsh<p>What is the nature of your BLE connections, conn interval, DLE, MTU, slave latency, conn supervisory timeout, throughput etc.<br /><br />Also do you have a BLE sniffer trace of your concurrent BLE and Thread application running?&nbsp;</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/148948?ContentTypeID=1Mon, 17 Sep 2018 08:24:07 GMT137ad170-7792-4731-bb38-c0d22fbe4515:d3879a39-4cea-40d1-8a6a-918871d2b91eMarco Sterbik<p>Hey&nbsp;H&aring;kon,</p> <p>I&#39;m using the mentioned accuracy settings allready (CTIV = 16, TEMP_CTIV&nbsp; = 2, ACCURARCY = 1 (=500ppm)), cause in my previous project (BLE only on nRF52832) I also used the internal RC only.</p> <p>Interesting Update from my side: I removed the BLE part from my project for testing (and verifying my theory) by simply not starting advertising and the Thread part now works for 3 days straight without any problem.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/148933?ContentTypeID=1Mon, 17 Sep 2018 08:03:06 GMT137ad170-7792-4731-bb38-c0d22fbe4515:47c9b0ab-153d-46f4-b33a-9199dd01878chaakonsh<p>Hey Marco, sorry for the late reply.</p> <p>Use the internal RC oscillator can cause the BLE and/or thread stack to miss their TX/RX windows, due to inaccurate schedulers. The SoftDevice can mediate this issue by accounting for this inaccuracy, but you need to set the clock accuracy to 500ppm when configuring the SoftDevice Handler(<a title="NRF_SDH_CLOCK_LF_ACCURACY" href="https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.0.0/group__nrf__sdh__config.html?cp=4_0_1_6_11_65_0_3#ga368f4ca68267cedc0f52644751e8630e">NRF_SDH_CLOCK_LF_ACCURACY</a>), and set the <span>LFRC&nbsp;</span>calibration interval to ~15 seconds(<a title="NRF_SDH_CLOCK_LF_RC_CTIV" href="https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.0.0/group__nrf__sdh__config.html?cp=4_0_1_6_11_65_0_4#ga7992d0564d149ff30a4d36fc81a6f127">NRF_SDH_CLOCK_LF_RC_CTIV</a>).&nbsp;<br /><br />I suggest you try setting the LFRC accuracy to 500ppm an/or using an external crystal and if that does not work then we will dig a bit deeper into the radio stacks.&nbsp;</p> <p>Cheers,</p> <p>Håkon.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/148408?ContentTypeID=1Wed, 12 Sep 2018 12:28:01 GMT137ad170-7792-4731-bb38-c0d22fbe4515:b6dc1316-e383-4b03-a215-8a673c7f221fMarco Sterbik<p>What just came to my mind now - I&#39;m using the internal 32.768 RC instead of an external one - maybe this increases the probability of this behaviour due to the higher tolerances.</p><div style="clear:both;"></div>