<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 4/17/2013 9:47 AM, Matthew J
      Fletcher wrote:<br>
    </div>
    <blockquote
cite="mid:CAPy9Tik1+n_bT9wG797pNadNrG1ST6v-KekpWovWQ29VSV2p7w@mail.gmail.com"
      type="cite">
      <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>
        </div>
      </div>
    </blockquote>
    OK. <br>
    <blockquote
cite="mid:CAPy9Tik1+n_bT9wG797pNadNrG1ST6v-KekpWovWQ29VSV2p7w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>>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>
    </blockquote>
    If this is the BSP you are using, take it off and try again. This is
    the only BSP<br>
    using this option. Sebastian can probably comment on the other
    arguments.<br>
    <blockquote
cite="mid:CAPy9Tik1+n_bT9wG797pNadNrG1ST6v-KekpWovWQ29VSV2p7w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <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>
    </blockquote>
    It is absolutely shared. The BSP has to provide some glue code but<br>
    between libbsp/shared, libbsp/<ARCH>/shared, and the
    appropriate<br>
    libcpu directory, you will find the code.<br>
    <br>
    Look for shared and libcpu in the Makefile.am.<br>
    <br>
    Now as Sebastian says, the handler might be mis-registered as raw<br>
    not OS interrupt. And the BSP may have been mechanically converted<br>
    to the new shared PIC interrupt code used by many BSPs but not<br>
    tested.<br>
    <blockquote
cite="mid:CAPy9Tik1+n_bT9wG797pNadNrG1ST6v-KekpWovWQ29VSV2p7w@mail.gmail.com"
      type="cite">
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On 17 April 2013 15:34, Joel Sherrill <span
            dir="ltr"><<a moz-do-not-send="true"
              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 moz-do-not-send="true"
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
                            moz-do-not-send="true"
                            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 moz-do-not-send="true"
                                href="tel:%2B49%2089%20189%2047%2041-16"
                                value="+4989189474116" target="_blank">+49
                                89 189 47 41-16</a><br>
                              Fax     : <a moz-do-not-send="true"
                                href="tel:%2B49%2089%20189%2047%2041-09"
                                value="+4989189474109" target="_blank">+49
                                89 189 47 41-09</a><br>
                              E-Mail  : <a moz-do-not-send="true"
                                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 moz-do-not-send="true" 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>
    </blockquote>
    <br>
    <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>