Debugging basic BSP tasking functionality

[Joel Sherrill]

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        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/0f3adf52/attachment-0001.html>