Debugging basic BSP tasking functionality

Thu Apr 18 19:56:55 UTC 2013

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
>