Debugging basic BSP tasking functionality

Joel Sherrill joel.sherrill at OARcorp.com
Thu Apr 18 20:27:05 UTC 2013


On 4/18/2013 3:01 PM, Matthew J Fletcher wrote:
> > Are you not able to relocate the vector table base address?
>
> My understanding is that you cannot on the ARM7TDMI, you can on the 
> later Cortex cores, and also on the 20 year old CPU32/m68k 68340's we 
> use !
>
On at least PowerPCs, the preamble in Flash jumps to a common
place in a known state. Like the cause/vector in a register and a known set
of registers saved.

Could you effectively do this in the code at 0x0? And end up in your 
application
at the beginning of the RTEMS ISR Handler code? I am thinking an 
indirect jump
or carefully placing the address of the common entry at a fixed location.

--joel

>
> On 18 April 2013 20:56, Gedare Bloom <gedare at rtems.org 
> <mailto:gedare at rtems.org>> wrote:
>
>     Are you not able to relocate the vector table base address?
>
>     On Thu, Apr 18, 2013 at 3:21 PM, Matthew J Fletcher
>     <amimjf at gmail.com <mailto:amimjf at gmail.com>> wrote:
>     > Hi,
>     >
>     > During my cycle home the answer became clear, all i need to do
>     is take a
>     > copy of the arm_exc_interrupt asm, break it out into bits done
>     before before
>     > calling any functions in the 'C' interrupt handler, and those
>     that need to
>     > be done right at the end. Some advice on exactly what that split
>     might be
>     > would be much appreciated.
>     >
>     > I think i would need to add the GCC attribute 'naked'
>     > http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html so no
>     automatic
>     > stack push/pops are generated.
>     >
>     >
>     >
>     >
>     > On 18 April 2013 18:39, Matthew J Fletcher <amimjf at gmail.com
>     <mailto:amimjf at gmail.com>> wrote:
>     >>
>     >> Hi
>     >>
>     >>
>     >> > The C function should match the rtems_interrupt_handler typedef.
>     >>
>     >> I've corrected that, no change. I think the issue is that no
>     handler is
>     >> getting registered. I believe you said previously that
>     ISR_Handler() was the
>     >> single entry point for all interrupt vectors then it works out
>     what vector
>     >> its called on and calls the appropriate handler.
>     >>
>     >> ARM looks to be the odd one out in that it uses in
>     >> /cpukit/score/cpu/arm/arm_sec_interrupt.S
>     >>
>     >> I remember now what problem might be, i had to remove the
>     >> _CPU_ISR_install_vector() call which add arm_exc_interrupt
>     because on my
>     >> hardware the vector table at 0x0000000 is mapped to on ARM
>     internal flash
>     >> (which does contain basic interrupt handlers), not RAM.
>     >>
>     >> I've now got a sinking feeling that i cant use rtems on my
>     hardware as is.
>     >> I suppose this is a question for Sebastian, but when i
>     >> rtems_interrupt_handler_
>     >> install() can the handler just be 'arm_exc_interrupt', and the
>     argument
>     >> the vector number ?
>     >>
>     >> I've got my fingers crossed for the answer.
>     >>
>     >>
>     >>
>     >> On 18 April 2013 17:46, Gedare Bloom <gedare at rtems.org
>     <mailto:gedare at rtems.org>> wrote:
>     >>>
>     >>> On Thu, Apr 18, 2013 at 12:02 PM, Matthew J Fletcher
>     <amimjf at gmail.com <mailto:amimjf at gmail.com>>
>     >>> wrote:
>     >>> > Hi,
>     >>> >
>     >>> > I presume all that needs to be done is call
>     bsp_interrupt_initalize()
>     >>> > and
>     >>> > then rtems_interrupt_handler_install(), passing in your BSP
>     specific
>     >>> > interrupt vector and any old C function as the handler ?
>     >>> >
>     >>> >
>     >>>
>     >>>
>     http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__rtems__interrupt__extension.html
>     >>>
>     >>> The C function should match the rtems_interrupt_handler typedef.
>     >>>
>     >>> >
>     >>> >
>     >>> >
>     >>> >
>     >>> > On 18 April 2013 14:56, Matthew J Fletcher <amimjf at gmail.com
>     <mailto:amimjf at gmail.com>> wrote:
>     >>> >>
>     >>> >> Hi,
>     >>> >>
>     >>> >>
>     >>> >> > Now as Sebastian says, the handler might be
>     mis-registered as raw
>     >>> >> > not OS interrupt. And the BSP may have been mechanically
>     converted
>     >>> >> > to the new shared PIC interrupt code used by many BSPs
>     but not
>     >>> >> > tested.
>     >>> >>
>     >>> >> Is there an example of a BSP registering a tick interrupt
>     that i can
>     >>> >> examine/copy ? this morning attempts to change the use of
>     >>> >> rtems_interrupt_handler_install() has just resulted in
>     unhandled IRQ
>     >>> >> exceptions.
>     >>>
>     >>> libbsp/arm/shared/lpc/clock/lpc-clock-config.c appears to do it.
>     >>>
>     >>> >>
>     >>> >>
>     >>> >>
>     >>> >>
>     >>> >>
>     >>> >>
>     >>> >> On 17 April 2013 16:01, Joel Sherrill
>     <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>>
>     >>> >> wrote:
>     >>> >>>
>     >>> >>> On 4/17/2013 9:47 AM, Matthew J Fletcher wrote:
>     >>> >>>
>     >>> >>> >If you put an explicit call to
>     rtems_stack_checker_is_blown() in
>     >>> >>> > Init()
>     >>> >>> > at
>     >>> >>> >various points, does it think things are OK?
>     >>> >>>
>     >>> >>> I put in a few and even the last one before the Init()
>     task deletes
>     >>> >>> itself is ok.
>     >>> >>>
>     >>> >>>
>     >>> >>> OK.
>     >>> >>>
>     >>> >>> >Just to be clear.. is this with the rtl22xx or rtl22xx_t
>     BSP? The
>     >>> >>> > non-thumb version
>     >>> >>> >uses -mapcs-frame which no other BSP uses. That makes me
>     wonder.
>     >>> >>>
>     >>> >>> rtl22xx_t 'Thumb', -mapcs-frame is passed on the gcc
>     command line.
>     >>> >>>
>     >>> >>> If this is the BSP you are using, take it off and try
>     again. This is
>     >>> >>> the
>     >>> >>> only BSP
>     >>> >>> using this option. Sebastian can probably comment on the other
>     >>> >>> arguments.
>     >>> >>>
>     >>> >>>
>     >>> >>> >Not with RTEMS. When you enter/exit an ISR, you go
>     through some
>     >>> >>> >code which saves the proper registers, probably switches
>     you to
>     >>> >>> >a dedicated stack, and does the OS stuff needed so it will do
>     >>> >>> >any needed dispatching at the end of the interrupt.
>     >>> >>>
>     >>> >>> Is this shared between BSPs ? i tried to look for this and
>     failed.
>     >>> >>>
>     >>> >>>
>     >>> >>> It is absolutely shared. The BSP has to provide some glue
>     code but
>     >>> >>> between libbsp/shared, libbsp/<ARCH>/shared, and the
>     appropriate
>     >>> >>> libcpu directory, you will find the code.
>     >>> >>>
>     >>> >>> Look for shared and libcpu in the Makefile.am.
>     >>> >>>
>     >>> >>> Now as Sebastian says, the handler might be mis-registered
>     as raw
>     >>> >>> not OS interrupt. And the BSP may have been mechanically
>     converted
>     >>> >>> to the new shared PIC interrupt code used by many BSPs but not
>     >>> >>> tested.
>     >>> >>>
>     >>> >>>
>     >>> >>>
>     >>> >>> On 17 April 2013 15:34, Joel Sherrill
>     <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>>
>     >>> >>> wrote:
>     >>> >>>>
>     >>> >>>> On 4/17/2013 9:04 AM, Matthew J Fletcher wrote:
>     >>> >>>>
>     >>> >>>> Hi,
>     >>> >>>>
>     >>> >>>> 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.
>     >>> >>>>
>     >>> >>>> You are completely in C code when this happens. There has
>     been
>     >>> >>>> assembly
>     >>> >>>> to switch to the task initially (e.g. into
>     _Thread_Handler) and if
>     >>> >>>> an
>     >>> >>>> interrupt
>     >>> >>>> occurred.
>     >>> >>>>
>     >>> >>>> If you put an explicit call to
>     rtems_stack_checker_is_blown() in
>     >>> >>>> Init()
>     >>> >>>> at
>     >>> >>>> various points, does it think things are OK?
>     >>> >>>>
>     >>> >>>> It is easy for the stack not to be initialized to match
>     gcc or gdb's
>     >>> >>>> expectation
>     >>> >>>> of how it ends.
>     >>> >>>>
>     >>> >>>> Just to be clear.. is this with the rtl22xx or rtl22xx_t
>     BSP? The
>     >>> >>>> non-thumb version
>     >>> >>>> uses -mapcs-frame which no other BSP uses. That makes me
>     wonder.
>     >>> >>>>
>     >>> >>>> 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.
>     >>> >>>>
>     >>> >>>> 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...
>     >>> >>>>
>     >>> >>>>
>     >>> >>>>
>     >>> >>>>
>     http://www.procyonengineering.com/embedded/arm/armlib/docs/html/group__processor__lpc2000.html
>     >>> >>>>
>     >>> >>>> ISR_ENTRY / ISR_EXIT
>     >>> >>>>
>     >>> >>>>
>     >>> >>>> Not with RTEMS. When you enter/exit an ISR, you go
>     through some
>     >>> >>>> code which saves the proper registers, probably switches
>     you to
>     >>> >>>> a dedicated stack, and does the OS stuff needed so it will do
>     >>> >>>> any needed dispatching at the end of the interrupt.
>     >>> >>>>
>     >>> >>>> --joel
>     >>> >>>>
>     >>> >>>>
>     >>> >>>>
>     >>> >>>>
>     >>> >>>>
>     >>> >>>> On 17 April 2013 13:40, Sebastian Huber
>     >>> >>>> <sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>> wrote:
>     >>> >>>>>
>     >>> >>>>> On 04/17/2013 02:27 PM, Matthew J Fletcher wrote:
>     >>> >>>>>>
>     >>> >>>>>>  >Here a context switch from the Init to the idle (I
>     guess) thread
>     >>> >>>>>> happens.
>     >>> >>>>>>   The >_User_extensions_Thread_switch
>     >>> >>>>>>  >() is called before the context switch and the
>     running thread is
>     >>> >>>>>> checked.  So
>     >>> >>>>>> a sp of >0x814d299c must be in the range of the Init
>     stack area.
>     >>> >>>>>>
>     >>> >>>>>> Yes it is, Init() stack area is 0x814d1a70 ->
>     0x814d2a74 (4100
>     >>> >>>>>> bytes).
>     >>> >>>>>> So it
>     >>> >>>>>> looks like the stack pointer is not getting adjusted
>     correctly
>     >>> >>>>>> when
>     >>> >>>>>> task
>     >>> >>>>>> switching into a new thread ? as the rtems_idle task is
>     using the
>     >>> >>>>>> Init() stack
>     >>> >>>>>> pointer.
>     >>> >>>>>
>     >>> >>>>>
>     >>> >>>>> Now I am a bit confused.  What check goes wrong in
>     >>> >>>>>
>     >>> >>>>>
>     >>> >>>>> Stack_check_Frame_pointer_in_range() at check.c:69
>     0x81180f6e
>     >>> >>>>> rtems_stack_checker_switch_extension() at check.c:276
>     0x81180f6e
>     >>> >>>>> _User_extensions_Thread_switch() at userextthreadswitch.c:41
>     >>> >>>>> 0x8118cbaa
>     >>> >>>>> _Thread_Dispatch() at threaddispatch.c:128 0x8118bce6
>     >>> >>>>> _Thread_Enable_dispatch() at threaddispatch.c:59 0x8118bd5e
>     >>> >>>>> rtems_task_delete() at taskdelete.c:94 0x81189750
>     >>> >>>>> Init() at startup.c:241 0x81007840
>     >>> >>>>>
>     >>> >>>>> ?
>     >>> >>>>>
>     >>> >>>>> 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.
>     >>> >>>>>
>     >>> >>>>>
>     >>> >>>>>>
>     >>> >>>>>>  > nm your-app.exe | grep 'bsp_\(section\|stack\)' | sort
>     >>> >>>>>>
>     >>> >>>>>> No matches.
>     >>> >>>>>
>     >>> >>>>>
>     >>> >>>>> Ok, 4.10 uses the old linker command files.  These
>     symbols are only
>     >>> >>>>> available in 4.11.
>     >>> >>>>>
>     >>> >>>>>
>     >>> >>>>> --
>     >>> >>>>> Sebastian Huber, embedded brains GmbH
>     >>> >>>>>
>     >>> >>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>     >>> >>>>> Phone   : +49 89 189 47 41-16
>     >>> >>>>> Fax     : +49 89 189 47 41-09
>     >>> >>>>> E-Mail  : sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>     >>> >>>>> PGP     : Public key available on request.
>     >>> >>>>>
>     >>> >>>>> Diese Nachricht ist keine geschäftliche Mitteilung im
>     Sinne des
>     >>> >>>>> EHUG.
>     >>> >>>>
>     >>> >>>>
>     >>> >>>>
>     >>> >>>>
>     >>> >>>> --
>     >>> >>>>
>     >>> >>>> regards
>     >>> >>>> ---
>     >>> >>>> Matthew J Fletcher
>     >>> >>>>
>     >>> >>>>
>     >>> >>>>
>     >>> >>>> --
>     >>> >>>> Joel Sherrill, Ph.D.       Director of Research & Development
>     >>> >>>> joel.sherrill at OARcorp.com        On-Line Applications
>     Research
>     >>> >>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>     >>> >>>> Support Available        (256) 722-9985
>     >>> >>>
>     >>> >>>
>     >>> >>>
>     >>> >>>
>     >>> >>> --
>     >>> >>>
>     >>> >>> regards
>     >>> >>> ---
>     >>> >>> Matthew J Fletcher
>     >>> >>>
>     >>> >>>
>     >>> >>>
>     >>> >>> --
>     >>> >>> Joel Sherrill, Ph.D.   Director of Research & Development
>     >>> >>> joel.sherrill at OARcorp.com    On-Line Applications Research
>     >>> >>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>     >>> >>> Support Available    (256) 722-9985
>     >>> >>
>     >>> >>
>     >>> >>
>     >>> >>
>     >>> >> --
>     >>> >>
>     >>> >> regards
>     >>> >> ---
>     >>> >> Matthew J Fletcher
>     >>> >>
>     >>> >
>     >>> >
>     >>> >
>     >>> > --
>     >>> >
>     >>> > regards
>     >>> > ---
>     >>> > Matthew J Fletcher
>     >>> >
>     >>> >
>     >>> > _______________________________________________
>     >>> > rtems-users mailing list
>     >>> > rtems-users at rtems.org <mailto:rtems-users at rtems.org>
>     >>> > http://www.rtems.org/mailman/listinfo/rtems-users
>     >>> >
>     >>
>     >>
>     >>
>     >>
>     >> --
>     >>
>     >> regards
>     >> ---
>     >> Matthew J Fletcher
>     >>
>     >
>     >
>     >
>     > --
>     >
>     > regards
>     > ---
>     > Matthew J Fletcher
>     >
>
>
>
>
> -- 
>
> regards
> ---
> Matthew J Fletcher
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130418/2ad6b08a/attachment-0001.html>


More information about the users mailing list