Debugging basic BSP tasking functionality

[Sebastian Huber]

On 04/16/2013 07: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.

They should do it all in the same way.  The difference is that some BSPs use 
copy and paste start.S files.  I removed a lot of copy and paste from the ARM 
port with mechanical changes.  It is possible that this broke some BSPs 
including the rtl22xx_t.

>
>
>  >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.

The above seems to be all right.  In case the idle thread is suspended by an 
interrupt the _Thread_Dispatch() will do the context switch using the idle 
thread 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.

The stack frame chain is not well terminated on the ARM.  So this might be ok.

[...]
>         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.
[...]

The stack checker inspects the pattern (0xFEEDF00D, 0x0BAD0D06, 0xDEADF00D, 
0x600D0D06) at the end of the stack area.  One of these values must be modified 
to the the blown stack message.  You can set the write break point here.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-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.