<div dir="ltr"><div>>If you put an explicit call to rtems_stack_checker_is_blown() in
    Init() at<br>>various points, does it think things are OK?<br><br></div><div>I put in a few and even the last one before the Init() task deletes itself is ok.<br><br></div><div><br>>Just to be clear.. is this with the rtl22xx or rtl22xx_t BSP? The
    non-thumb version<br>>uses -mapcs-frame which no other BSP uses. That makes me wonder.<br><br></div><div>rtl22xx_t 'Thumb', -mapcs-frame is passed on the gcc command line.<br><br></div><div><br>>Not with RTEMS. When you enter/exit an ISR, you go through some<br>

    >code which saves the proper registers, probably switches you to<br>
    >a dedicated stack, and does the OS stuff needed so it will do<br>>any needed dispatching at the end of the interrupt.<br><br></div>Is this shared between BSPs ? i tried to look for this and failed.<br><br><div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 April 2013 15:34, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div class="im">
    <div>On 4/17/2013 9:04 AM, Matthew J
      Fletcher wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>Hi,<br>
            <br>
          </div>
          Yes it the stack pointer out of range, because the current
          stack pointer returned by GCC _builtin_frame_XX in the IDLE
          thread looks like its actually that from the Init() thread.<br>
          <br>
        </div>
      </div>
    </blockquote></div>
    You are completely in C code when this happens. There has been
    assembly<br>
    to switch to the task initially (e.g. into _Thread_Handler) and if
    an interrupt<br>
    occurred.<br>
    <br>
    If you put an explicit call to rtems_stack_checker_is_blown() in
    Init() at<br>
    various points, does it think things are OK?<br>
    <br>
    It is easy for the stack not to be initialized to match gcc or gdb's
    expectation<br>
    of how it ends.<br>
    <br>
    Just to be clear.. is this with the rtl22xx or rtl22xx_t BSP? The
    non-thumb version<br>
    uses -mapcs-frame which no other BSP uses. That makes me wonder.<div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Thinking this through,my target is Thumb, so the C
          interrupt handler should be in a arm file with
          -mthumb-interwork set on the compile line.<br>
          <br>
        </div>
        <div>I guess GCC can not auto-magicly know what particular
          functions are interrupts, so should there be some entry/exit
          functions to save/restore the stack, etc, like these...<br>
        </div>
        <div><br>
          <a href="http://www.procyonengineering.com/embedded/arm/armlib/docs/html/group__processor__lpc2000.html" target="_blank">http://www.procyonengineering.com/embedded/arm/armlib/docs/html/group__processor__lpc2000.html</a><br>

          <br>
          ISR_ENTRY / ISR_EXIT    <br>
          <br>
        </div>
        <div><br>
        </div>
      </div>
    </blockquote></div>
    Not with RTEMS. When you enter/exit an ISR, you go through some<br>
    code which saves the proper registers, probably switches you to<br>
    a dedicated stack, and does the OS stuff needed so it will do<br>
    any needed dispatching at the end of the interrupt.<span class="HOEnZb"><font color="#888888"><br>
    <br>
    --joel</font></span><div><div class="h5"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>
          <div>
            <div>
              <div><br>
              </div>
            </div>
          </div>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On 17 April 2013 13:40, Sebastian Huber
          <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div>On 04/17/2013 02:27 PM, Matthew J Fletcher
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                 >Here a context switch from the Init to the idle (I
                guess) thread happens.<br>
                  The >_User_extensions_Thread_switch<br>
                 >() is called before the context switch and the
                running thread is checked.  So<br>
                a sp of >0x814d299c must be in the range of the Init
                stack area.<br>
                <br>
                Yes it is, Init() stack area is 0x814d1a70 ->
                0x814d2a74 (4100 bytes). So it<br>
                looks like the stack pointer is not getting adjusted
                correctly when task<br>
                switching into a new thread ? as the rtems_idle task is
                using the Init() stack<br>
                pointer.<br>
              </blockquote>
              <br>
            </div>
            Now I am a bit confused.  What check goes wrong in
            <div><br>
              <br>
              Stack_check_Frame_pointer_in_range() at check.c:69
              0x81180f6e<br>
              rtems_stack_checker_switch_extension() at check.c:276
              0x81180f6e<br>
              _User_extensions_Thread_switch() at
              userextthreadswitch.c:41 0x8118cbaa<br>
              _Thread_Dispatch() at threaddispatch.c:128 0x8118bce6<br>
              _Thread_Enable_dispatch() at threaddispatch.c:59
              0x8118bd5e<br>
              rtems_task_delete() at taskdelete.c:94 0x81189750<br>
              Init() at startup.c:241 0x81007840<br>
              <br>
            </div>
            ?<br>
            <br>
            In case the stack pointer is out of range, then I guess that
            the interrupt exception processing is broken.  It is hard to
            know what happens without an actual target.
            <div><br>
              <br>
              <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <br>
                 > nm your-app.exe | grep 'bsp_\(section\|stack\)' |
                sort<br>
                <br>
                No matches.<br>
              </blockquote>
              <br>
            </div>
            Ok, 4.10 uses the old linker command files.  These symbols
            are only available in 4.11.
            <div>
              <div><br>
                <br>
                -- <br>
                Sebastian Huber, embedded brains GmbH<br>
                <br>
                Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
                Phone   : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47
                  41-16</a><br>
                Fax     : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47
                  41-09</a><br>
                E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
                PGP     : Public key available on request.<br>
                <br>
                Diese Nachricht ist keine geschäftliche Mitteilung im
                Sinne des EHUG.<br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <br>
        -- <br>
        <div><br>
          regards</div>
        <div>---</div>
        <div>Matthew J Fletcher</div>
        <br>
      </div>
    </blockquote>
    <br>
    <br>
    </div></div><div class="im"><pre cols="72">-- 
Joel Sherrill, Ph.D.             Director of Research & Development 
<a href="mailto:joel.sherrill@OARcorp.com" target="_blank">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>
  </div></div>

</blockquote></div><br><br clear="all"><br>-- <br><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br>
</div>