Debugging basic BSP tasking functionality

Matthew J Fletcher amimjf at gmail.com
Wed Apr 17 09:48:22 UTC 2013


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.




On 16 April 2013 18:39, Joel Sherrill <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> 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 <%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.
>> _______________________________________________
>> rtems-users mailing list
>> 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        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>
>


-- 

regards
---
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130417/db6f7722/attachment-0001.html>


More information about the users mailing list