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