Debugging basic BSP tasking functionality

Thu Apr 18 16:46:41 UTC 2013

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
>