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