<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/16/2013 12:24 PM, Matthew J
Fletcher wrote:<br>
</div>
<blockquote
cite="mid:CAPy9TinTM26H0SBek+YC6FBbVQw6H1xWPOzzHXCDeCYF+5svOw@mail.gmail.com"
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>
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.<br>
<blockquote
cite="mid:CAPy9TinTM26H0SBek+YC6FBbVQw6H1xWPOzzHXCDeCYF+5svOw@mail.gmail.com"
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 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_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 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>
<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>