Debugging basic BSP tasking functionality

Matthew J Fletcher amimjf at gmail.com
Thu Apr 18 20:43:32 UTC 2013 

> 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.

Yep, like a trampoline. I would need a special section at a fixed address
to jump to and the ISR Handler sitting there.


On 18 April 2013 21:27, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:

>  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> 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
>
>
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130418/0429fde5/attachment-0001.html>

More information about the users mailing list