<?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>Multilink - Causing Hardfaults</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/14124/multilink---causing-hardfaults</link><description>I&amp;#39;m running s120 v1.2 &amp;amp; SDK 9
My application will connect to, up to 8, known peripherals. If the connection is dropped or not established, my central app will try to continue to try to establish a connection. To the peripherals that do connect, my will</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Thu, 26 May 2016 23:59:52 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/14124/multilink---causing-hardfaults" /><item><title>RE: Multilink - Causing Hardfaults</title><link>https://devzone.nordicsemi.com/thread/53975?ContentTypeID=1</link><pubDate>Thu, 26 May 2016 23:59:52 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:e698ed46-a809-46de-9045-b4a0f9d4b4f0</guid><dc:creator>RK</dc:creator><description>&lt;p&gt;Why don&amp;#39;t you stick to the original thread about this problem instead of creating a second one, especially as the previous one actually has lots of good details and analysis in it and was possibly heading towards a result. Hardfaults are hard, especially the occasional ones.&lt;/p&gt;
&lt;p&gt;And the answer to this question is an emphatic no, as I was going to say in a reply to the previous one. In fact all the speculation about interrupts there is going in the wrong direction and is just guesswork. If the MCU is servicing an interrupt then even if that same interrupt, or any of the same or lower priority, is raised, it won&amp;#39;t be taken until after the handler returns from the first one. And you also ask there if a higher priority interrupt occurred and how would you stop that, and the answer to that is it doesn&amp;#39;t matter if it did and you can&amp;#39;t stop it nor would you want to. That&amp;#39;s the point of interrupt priorities and the ARM is perfectly capable of stacking the state of the lower priority ones to take the higher ones and return back to where it came from.&lt;/p&gt;
&lt;p&gt;Now we&amp;#39;ve sorted out where the PC actually is on the exception stack I&amp;#39;ll go look at the other thread again later and see if it makes any more sense now.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>