Debugging basic BSP tasking functionality
Joel Sherrill
joel.sherrill at OARcorp.com
Wed Apr 17 14:50:00 UTC 2013
On 4/17/2013 4:48 AM, Matthew J Fletcher wrote:
> Hi,
>
> >Any chance the interrupt stack is overlapping the area used by RTEMS
> for the
> >Workspace? That would be the simplest explanation.
> >
> >Break at _Heap_Initialize (twice) and see what memory areas are used for
> >the RTEMS workspace and C Program Heap. Then compare that to the range
> >for the interrupt stack
>
> Thanks for the information, but unfortunately that does not seem to be
> the issue.
>
> rtems worksapce: start 0x814c8d70, end 0x8152cbb8 (length 0x63e48)
> malloc heap: start 0x8152cbb8, end 0x815acbb8 (length 0x80000)
>
> so my IDLE thread stack 0x814d060c -> 0x814d1610 is entirely within
> the rtems workspace.
>
:( Oh well. It is a common enough error and with Sebastian mentioning
cut and paste, it was worth checking.
I am really suspicious that the assumptions on the stack and frame pointer
made by the stack checker are not met in this configuration for some reason.
Either because we set the stack up wrong or gcc is not returning a valid
frame
pointer.
it is also a delete self case which is also tricky to do without
screwing something
up. You are freeing a stack you are still using.
>
>
>
> On 16 April 2013 18:39, Joel Sherrill <joel.sherrill at oarcorp.com
> <mailto:joel.sherrill at oarcorp.com>> wrote:
>
> On 4/16/2013 12:24 PM, Matthew J Fletcher wrote:
>> Thanks for the suggestions,
>>
>> >Maybe this is a problem with the interrupt stack. Is the
>> interrupt stack set up correctly?
>>
>> I've triple checked this, infact all the ARM BSP's,csb336,
>> edb7312, gp32, gumstix and the rtl22xx_t all do it the same way.
>> Only the lpcXX BSP's do it differently.
>>
>> They all use the linker file to allocate area's of RAM space with
>> a variable pointing to the start, which is then used in the asm
>> startup to setup the stack pointer and length. The rtl22xx_t is
>> the same as all other others in this regard.
>>
>>
>> >You can set a hardware write break point in the stack pattern area.
>>
>> This was a really good piece of advice, i had forgotten about this.
>>
>> The blown stack message shows that the INIT thread stack runs
>> 0x814d060c through 0x814d1610 (4100 bytes). So i place some
>> breakpoints and i can see that Stack_check_Initialize() has run
>> because all bytes are 0xA5 and the 0xFEEDF00D, 0x0BAD0D06,
>> 0xDEADF00D, 0x600D0D06, pattern appears pretty close to the stop
>> of the stack.
>>
>> So at the bottom we see,.. all good here. So i run the program.
>>
>> 0x814D15CC A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5
>> A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5
>> A5A5A5A5
>>
>> 0x814D1604 A5A5A5A5 A5A5A5A5 A5A5A5A5 02000000 00000431 00000000
>> 814D1904 814D196C 814D19D4 00000000 00000000 00000000 00000000
>> 00000000
>>
>> Then the memory watch hits,..
>>
>> 0x814D15CC A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5
>> 814C9A7C 00000001 FFFFFFFF FFFFFFFF 8118BD5F 81421FA8 811A3ECB
>> 81485FE0
>>
>> 0x814D1604 FFFFFFFF FFFFFFFF 811A3EA9 02000000 00000431 00000000
>> 814D1904 814D196C 814D19D4 00000000 00000000 00000000 00000000
>> 00000000
>>
>> at 0x814d15e4 (splatted with 814C9A7C) and 0x814d15ec (splatted
>> with FFFFFFFF), this is on the entry to _Thread_Dispatch(). Not
>> sure how your email client will render the above, but there are
>> various other overwrites as well.
>>
>> Now all of this is at the bottom of the stack, so 4000 bytes away
>> from the last actual stack allocation, and remember this thread
>> is just the rtems_idle() with a forever loop.
>>
>> So it looks like something around the inlined invocation of
>> _Thread_Enable_dispatch() is splatting the bottom of the stack.
>>
>>
>> Can i ask what stack/context _Thread_Handler() is called in ? the
>> gdb stacktrace thinks its called from
>> _Objects_API_maximum_class(), but i guess thats it just failing
>> to realise the top of the callstack.
>>
>> Does it come from the call to rtems_clock_tick() from my 10ms
>> inturrupt ? so is running in the IRQ (or FIQ) stack/context ?
>>
>> I guess its possible that i just need to give the IRQ more stack
>> space, its got 4k at the moment.
>>
>>
> Any chance the interrupt stack is overlapping the area used by
> RTEMS for the
> Workspace? That would be the simplest explanation.
>
> Break at _Heap_Initialize (twice) and see what memory areas are
> used for
> the RTEMS workspace and C Program Heap. Then compare that to the range
> for the interrupt stack.
>
> _Thread_Enable_Dispatch is callable from ISRs. But
> _Thread_Dispatch is not
> normally. This is the end of rtems_clock_tick():
>
> if ( _Thread_Is_context_switch_necessary() &&
> _Thread_Is_dispatching_enabled() )
> _Thread_Dispatch();
>
> It should not do that _Thread_Dispatch.
>
> Also any time you are in a task, _Per_CPU_Information should have
> the isr_nest_level field == 0. And _Thread_Dispatch_disable_level
> should
> be 0 unless you are inside an ISR or RTEMS directive. So normal task
> code should have that as 0. If it looks like you are not in ISR
> mode, in
> task code and _Thread_Dispatch_disable_level != 0, then there is
> likely
> a bug in the interrupt exit code.
>
>>
>> On 16 April 2013 13:04, Sebastian Huber
>> <sebastian.huber at embedded-brains.de
>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>
>> Hello Matthew,
>>
>>
>> On 04/16/2013 01:34 PM, Matthew J Fletcher wrote:
>>
>> Hi,
>>
>> It looks like i've got some pretty lowlevel problems with
>> the rtl22xx_t BSP on
>> my hardware, could i ask for some hints on how best to
>> investigate. I am of
>> course presuming this BSP is production ready, it might
>> be rotten, does anyone
>> know ?
>>
>>
>> the status of this BSP is unkown. Maybe you can use one of
>> the lpc24xx based BSPs.
>>
>>
>>
>> I have two symptoms.
>>
>> 1) RTEMS calls like rtems_task_wake_after() cause a
>> return from a thread,
>> despite being wrapped in forever loops.
>>
>> 2) When using CONFIGURE_STACK_CHECKER_ENABLED having
>> threads other than the
>> Init() and rtems_idle() threads cause the 'IDLE' thread's
>> stack to be reported
>> as blown.
>>
>> Now i run through boot_card() fine, task switch into the
>> Init task, so a task
>> switch has occurred once ok.
>>
>> An example stack blow.
>>
>> BLOWN STACK!!!
>> task control block: 0x814C9BBC
>> task ID: 0x09010001
>> task name: 0x49444C45
>> task name string: IDLE
>> task stack area (4100 Bytes): 0x814D074C .. 0x814D1750
>>
>> But my IDLE task is just a forever loop, so it seems
>> unlikely.
>>
>>
>> Maybe this is a problem with the interrupt stack. Is the
>> interrupt stack set up correctly?
>>
>> You can set a hardware write break point in the stack pattern
>> area.
>>
>>
>>
>> See the example code following;
>>
>> [...]
>>
>> I see nothing suspicious in the example.
>>
>> --
>> 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.
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org <mailto:rtems-users at rtems.org>
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>>
>>
>>
>> --
>>
>> 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/240cba33/attachment-0001.html>
More information about the users
mailing list