<div dir="ltr"><div><div>Thanks for the suggestions,<br><br>>Maybe this is a problem with the interrupt stack. Is the interrupt stack set up correctly?<br><br></div>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.<br>
<br></div>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.<br>
<br><div><div>
<br>
>You can set a hardware write break point in the stack pattern area.<br><br></div><div>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 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.<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 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5<br><br>0x814D1604 A5A5A5A5 A5A5A5A5 A5A5A5A5 02000000 00000431 00000000 814D1904 814D196C 814D19D4 00000000 00000000 00000000 00000000 00000000<br>
<br>Then the memory watch hits,..<br><br>0x814D15CC A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 814C9A7C 00000001 FFFFFFFF FFFFFFFF 8118BD5F 81421FA8 811A3ECB 81485FE0 <br>
<br>0x814D1604 FFFFFFFF FFFFFFFF 811A3EA9 02000000 00000431 00000000 814D1904 814D196C 814D19D4 00000000 00000000 00000000 00000000 00000000 <br>
<br>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.<br>
<br></div><div>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.<br></div><div><br></div><div>So it looks like something around the inlined invocation of _Thread_Enable_dispatch() is splatting the bottom of the stack.<br>
</div><div><br></div><div><br>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.<br>
<br></div><div>Does it come from the call to rtems_clock_tick() from my 10ms inturrupt ? so is running in the IRQ (or FIQ) stack/context ?<br></div><div><br></div><div>I guess its possible that i just need to give the IRQ more stack space, its got 4k at the moment.<br>
</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 16 April 2013 13:04, 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">Hello Matthew,<div class="im"><br>
<br>
On 04/16/2013 01:34 PM, Matthew J Fletcher wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
It looks like i've got some pretty lowlevel problems with the rtl22xx_t BSP on<br>
my hardware, could i ask for some hints on how best to investigate. I am of<br>
course presuming this BSP is production ready, it might be rotten, does anyone<br>
know ?<br>
</blockquote>
<br></div>
the status of this BSP is unkown. Maybe you can use one of the lpc24xx based BSPs.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have two symptoms.<br>
<br>
1) RTEMS calls like rtems_task_wake_after() cause a return from a thread,<br>
despite being wrapped in forever loops.<br>
<br>
2) When using CONFIGURE_STACK_CHECKER_<u></u>ENABLED having threads other than the<br>
Init() and rtems_idle() threads cause the 'IDLE' thread's stack to be reported<br>
as blown.<br>
<br>
Now i run through boot_card() fine, task switch into the Init task, so a task<br>
switch has occurred once ok.<br>
<br>
An example stack blow.<br>
<br>
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>
<br></div>
Maybe this is a problem with the interrupt stack. Is the interrupt stack set up correctly?<br>
<br>
You can set a hardware write break point in the stack pattern area.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
See the example code following;<br>
</blockquote></div>
[...]<br>
<br>
I see nothing suspicious in the example.<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>
______________________________<u></u>_________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/<u></u>listinfo/rtems-users</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br>
</div></div>