Debugging basic BSP tasking functionality
Matthew J Fletcher
amimjf at gmail.com
Thu Apr 18 17:39:12 UTC 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130418/0e19032b/attachment-0001.html>
More information about the users
mailing list