Debugging basic BSP tasking functionality

Matthew J Fletcher amimjf at gmail.com
Thu Apr 18 16:02:38 UTC 2013


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 ?






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.
>
>
>
>
>
>
> 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 <%2B49%2089%20189%2047%2041-16>
>>>> Fax     : +49 89 189 47 41-09 <%2B49%2089%20189%2047%2041-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130418/b744ba31/attachment-0001.html>


More information about the users mailing list