Debugging basic BSP tasking functionality

Wed Apr 17 14:55:05 UTC 2013

On Wed, Apr 17, 2013 at 10:47 AM, Matthew J Fletcher <amimjf at gmail.com> 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.
>
>
>>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.
>
>
>>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.
>
Look for ISR_Handler. It is implemented at the cpukit/score/cpu level usually.

Are you registering your interrupt handler properly with
rtems_interrupt_hanlder_install()? If the ISR handler you are
registering is in "raw" mode, then yes you will have problems because
the hw will go directly to your function without saving the processor
state.

>
>
>
> 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
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>