<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 1/6/2014 10:58 AM, John Harwell
wrote:<br>
</div>
<blockquote cite="mid:52CAE0B9.2080808@swri.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hello,<br>
<br>
When RTEMS entries the Internal_error_Occurred() routine, it is
within the context of an ISR, according to the value of
_ISR_Nest_level.<br>
After reading the documentation on rtems_fire_after() <a
moz-do-not-send="true"
href="http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__ClassicTimer.html#gad9785a6bd78ab5a591a134d147b2bdd3">here</a>,
I realized that because my function attempts to acquire a global<br>
mutex lock within an ISR context, RTEMS will correctly lockup. Now
that I know the cause, restructuring my code should be<br>
relatively simple.<br>
<br>
</blockquote>
You could use the timer server version of the calls but acquiring a
lock potentially could<br>
potentially negatively impact other timers managed by the server.<br>
<blockquote cite="mid:52CAE0B9.2080808@swri.org" type="cite"> Thanks
for your help,<br>
<br>
<div class="moz-signature">-- <br>
John Harwell<br>
Engineer<br>
High Reliability Software Section<br>
Communications and Embedded Systems Department<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:john.harwell@swri.org">john.harwell@swri.org</a><br>
Office: 210-522-5965<br>
Southwest Research Institute (SwRI)<br>
6220 Culebra Road, San Antonio, TX 78238-5166<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985</pre>
</body>
</html>