Debugging basic BSP tasking functionality

Tue Apr 16 17:24:48 UTC 2013

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.

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
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-**brains.de<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<http://www.rtems.org/mailman/listinfo/rtems-users>
>

-- 

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