<div dir="ltr"><div><div><div>Hi,<br></div><div><br>>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.<br><br></div><div>I am using the stable 4.10.2 sources BTW. If the above still applies what areas were changed, so i can investigate ?<br></div><div><br>>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.<br><br></div>Are you sure ? looking at the code if the above pattern area is overwritten then i would see a printk with "damaged pattern area". I dont see that, and also when examining memory i can see the pattern is intact. <br>
<br>The other part of the stack check, is making sure the frame pointer is in range of the stack, it looks like its this check that fails.<br><br></div>Indeed within Stack_check_Frame_pointer_in_range() GCC's
__builtin_frame_address(0); is returning a sp of 0x814d299c, which is
outside the stack range of the IDLE thread 0x814d060c -> 0x814d1610<br><br></div>the callstack is,..<br><div><div><br>Stack_check_Frame_pointer_in_range() at check.c:69 0x81180f6e <br>rtems_stack_checker_switch_extension() at check.c:276 0x81180f6e <br>
_User_extensions_Thread_switch() at userextthreadswitch.c:41 0x8118cbaa <br>_Thread_Dispatch() at threaddispatch.c:128 0x8118bce6 <br>_Thread_Enable_dispatch() at threaddispatch.c:59 0x8118bd5e <br>rtems_task_delete() at taskdelete.c:94 0x81189750 <br>
Init() at startup.c:241 0x81007840 <br><br><br><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 April 2013 08:36, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 04/16/2013 07:24 PM, Matthew J Fletcher wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the suggestions,<br>
<br>
>Maybe this is a problem with the interrupt stack. Is the interrupt stack set<br>
up correctly?<br>
<br>
I've triple checked this, infact all the ARM BSP's,csb336, edb7312, gp32,<br>
gumstix and the rtl22xx_t all do it the same way. Only the lpcXX BSP's do it<br>
differently.<br>
<br>
They all use the linker file to allocate area's of RAM space with a variable<br>
pointing to the start, which is then used in the asm startup to setup the stack<br>
pointer and length. The rtl22xx_t is the same as all other others in this regard.<br>
</blockquote>
<br></div>
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.<div>
<div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
>You can set a hardware write break point in the stack pattern area.<br>
<br>
This was a really good piece of advice, i had forgotten about this.<br>
<br>
The blown stack message shows that the INIT thread stack runs 0x814d060c<br>
through 0x814d1610 (4100 bytes). So i place some breakpoints and i can see<br>
that Stack_check_Initialize() has run because all bytes are 0xA5 and the<br>
0xFEEDF00D, 0x0BAD0D06, 0xDEADF00D, 0x600D0D06, pattern appears pretty close to<br>
the stop of the stack.<br>
<br>
So at the bottom we see,.. all good here. So i run the program.<br>
<br>
0x814D15CC A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5<br>
A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5<br>
<br>
0x814D1604 A5A5A5A5 A5A5A5A5 A5A5A5A5 02000000 00000431 00000000 814D1904<br>
814D196C 814D19D4 00000000 00000000 00000000 00000000 00000000<br>
<br>
Then the memory watch hits,..<br>
<br>
0x814D15CC A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 814C9A7C<br>
00000001 FFFFFFFF FFFFFFFF 8118BD5F 81421FA8 811A3ECB 81485FE0<br>
<br>
0x814D1604 FFFFFFFF FFFFFFFF 811A3EA9 02000000 00000431 00000000 814D1904<br>
814D196C 814D19D4 00000000 00000000 00000000 00000000 00000000<br>
<br>
at 0x814d15e4 (splatted with 814C9A7C) and 0x814d15ec (splatted with FFFFFFFF),<br>
this is on the entry to _Thread_Dispatch(). Not sure how your email client will<br>
render the above, but there are various other overwrites as well.<br>
<br>
Now all of this is at the bottom of the stack, so 4000 bytes away from the last<br>
actual stack allocation, and remember this thread is just the rtems_idle() with<br>
a forever loop.<br>
<br>
So it looks like something around the inlined invocation of<br>
_Thread_Enable_dispatch() is splatting the bottom of the stack.<br>
</blockquote>
<br></div></div>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Can i ask what stack/context _Thread_Handler() is called in ? the gdb<br>
stacktrace thinks its called from _Objects_API_maximum_class(), but i guess<br>
thats it just failing to realise the top of the callstack.<br>
</blockquote>
<br></div>
The stack frame chain is not well terminated on the ARM. So this might be ok.<br>
<br>
[...]<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
BLOWN STACK!!!<br>
task control block: 0x814C9BBC<br>
task ID: 0x09010001<br>
task name: 0x49444C45<br>
task name string: IDLE<br>
task stack area (4100 Bytes): 0x814D074C .. 0x814D1750<br>
<br>
But my IDLE task is just a forever loop, so it seems unlikely.<br>
</blockquote></div>
[...]<br>
<br>
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.<div class="HOEnZb">
<div class="h5"><br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47 41-16</a><br>
Fax : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-<u></u>brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br>
</div>