Debugging basic BSP tasking functionality
Joel Sherrill
joel.sherrill at OARcorp.com
Tue Apr 16 17:39:34 UTC 2013
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 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/20130416/7750617e/attachment-0001.html>
More information about the users
mailing list