Debugging basic BSP tasking functionality

Matthew J Fletcher amimjf at gmail.com
Thu Apr 18 20:01:40 UTC 2013


> 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 18 April 2013 20:56, Gedare Bloom <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>
> 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> 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> wrote:
> >>>
> >>> On Thu, Apr 18, 2013 at 12:02 PM, Matthew J Fletcher <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> 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>
> >>> >> 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>
> >>> >>> 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> 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
> >>> >>>>> 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
> >>> > http://www.rtems.org/mailman/listinfo/rtems-users
> >>> >
> >>
> >>
> >>
> >>
> >> --
> >>
> >> regards
> >> ---
> >> Matthew J Fletcher
> >>
> >
> >
> >
> > --
> >
> > regards
> > ---
> > Matthew J Fletcher
> >
>



-- 

regards
---
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130418/3dc299b6/attachment-0001.html>


More information about the users mailing list