<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 4/17/2013 4:48 AM, Matthew J
Fletcher wrote:<br>
</div>
<blockquote
cite="mid:CAPy9TikpLLs5-sA2TPts3QGUyUzDoZSeW5co+SiENk6droQBpg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hi,<br>
<br>
>Any chance the interrupt stack is overlapping the area
used by RTEMS for the<br>
>Workspace? That would be the simplest explanation. <br>
><br>
>Break at _Heap_Initialize (twice) and see what memory
areas are used for<br>
>the RTEMS workspace and C Program Heap. Then compare that
to the range<br>
>for the interrupt stack<br>
<br>
</div>
<div>Thanks for the information, but unfortunately that does not
seem to be the issue.<br>
<br>
</div>
<div>rtems worksapce: start 0x814c8d70, end 0x8152cbb8 (length
0x63e48)<br>
</div>
<div>malloc heap: start 0x8152cbb8, end 0x815acbb8 (length
0x80000)<br>
<br>
</div>
<div>so my IDLE thread stack 0x814d060c -> 0x814d1610 is
entirely within the rtems workspace.<br>
</div>
<div><br>
</div>
</div>
</blockquote>
:( Oh well. It is a common enough error and with Sebastian
mentioning<br>
cut and paste, it was worth checking.<br>
<br>
I am really suspicious that the assumptions on the stack and frame
pointer<br>
made by the stack checker are not met in this configuration for some
reason.<br>
Either because we set the stack up wrong or gcc is not returning a
valid frame<br>
pointer. <br>
<br>
it is also a delete self case which is also tricky to do without
screwing something<br>
up. You are freeing a stack you are still using.<br>
<blockquote
cite="mid:CAPy9TikpLLs5-sA2TPts3QGUyUzDoZSeW5co+SiENk6droQBpg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 16 April 2013 18:39, Joel Sherrill <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="im">
<div>On 4/16/2013 12:24 PM, Matthew J Fletcher wrote:<br>
</div>
<blockquote type="cite">
<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>
</div>
</div>
</blockquote>
</div>
Any chance the interrupt stack is overlapping the area
used by RTEMS for the<br>
Workspace? That would be the simplest explanation. <br>
<br>
Break at _Heap_Initialize (twice) and see what memory
areas are used for<br>
the RTEMS workspace and C Program Heap. Then compare that
to the range<br>
for the interrupt stack. <br>
<br>
_Thread_Enable_Dispatch is callable from ISRs. But
_Thread_Dispatch is not<br>
normally. This is the end of rtems_clock_tick():<br>
<br>
if ( _Thread_Is_context_switch_necessary() &&<br>
_Thread_Is_dispatching_enabled() )<br>
_Thread_Dispatch();<br>
<br>
It should not do that _Thread_Dispatch. <br>
<br>
Also any time you are in a task, _Per_CPU_Information
should have<br>
the isr_nest_level field == 0. And
_Thread_Dispatch_disable_level should<br>
be 0 unless you are inside an ISR or RTEMS directive. So
normal task<br>
code should have that as 0. If it looks like you are not
in ISR mode, in<br>
task code and _Thread_Dispatch_disable_level != 0, then
there is likely<br>
a bug in the interrupt exit code.
<div>
<div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 16 April 2013 13:04,
Sebastian Huber <span dir="ltr"><<a
moz-do-not-send="true"
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><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><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_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><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 moz-do-not-send="true"
href="tel:%2B49%2089%20189%2047%2041-16"
value="+4989189474116" target="_blank">+49
89 189 47 41-16</a><br>
Fax : <a moz-do-not-send="true"
href="tel:%2B49%2089%20189%2047%2041-09"
value="+4989189474109" target="_blank">+49
89 189 47 41-09</a><br>
E-Mail : <a moz-do-not-send="true"
href="mailto:sebastian.huber@embedded-brains.de"
target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche
Mitteilung im Sinne des EHUG.<br>
_______________________________________________<br>
rtems-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:rtems-users@rtems.org"
target="_blank">rtems-users@rtems.org</a><br>
<a moz-do-not-send="true"
href="http://www.rtems.org/mailman/listinfo/rtems-users"
target="_blank">http://www.rtems.org/mailman/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>
</blockquote>
<br>
<br>
</div>
</div>
<span class="HOEnZb"><font color="#888888">
<pre cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a moz-do-not-send="true" href="mailto:joel.sherrill@OARcorp.com" target="_blank">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985 </pre>
</font></span></div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div><br>
regards</div>
<div>---</div>
<div>Matthew J Fletcher</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985 </pre>
</body>
</html>