Debugging basic BSP tasking functionality

Joel Sherrill joel.sherrill at OARcorp.com
Wed Apr 17 15:01:29 UTC 2013


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 
> <mailto: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
>>     <mailto: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 <tel:%2B49%2089%20189%2047%2041-16>
>>         Fax     : +49 89 189 47 41-09 <tel:%2B49%2089%20189%2047%2041-09>
>>         E-Mail  : sebastian.huber at embedded-brains.de
>>         <mailto: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  <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130417/91d3dbb0/attachment-0001.html>


More information about the users mailing list