<div dir="ltr"><div>Hi,<br><br></div>I presume all that needs to be done is call bsp_interrupt_initalize() and then rtems_interrupt_handler_install(), passing in your BSP specific interrupt vector and any old C function as the handler ?<br>
<br><br><div><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 April 2013 14:56, Matthew J Fletcher <span dir="ltr"><<a href="mailto:amimjf@gmail.com" target="_blank">amimjf@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,<div class="im"><br><br>> Now as Sebastian says, the handler might be mis-registered as raw<br>
> not OS interrupt. And the BSP may have been mechanically converted<br>
> to the new shared PIC interrupt code used by many BSPs but not<br>
> tested.<br><br></div></div>Is there an example of a BSP registering a tick interrupt that i can examine/copy ? this morning attempts to change the use of rtems_interrupt_handler_install() has just resulted in unhandled IRQ exceptions.<br>
<br><br><div><div><div><div><br><br></div></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 April 2013 16:01, 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>
<div>On 4/17/2013 9:47 AM, Matthew J
Fletcher wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>>If you put an explicit call to
rtems_stack_checker_is_blown() in Init() at<br>
>various points, does it think things are OK?<br>
<br>
</div>
<div>I put in a few and even the last one before the Init() task
deletes itself is ok.<br>
<br>
</div>
<div><br>
</div>
</div>
</blockquote></div>
OK. <br><div>
<blockquote type="cite">
<div dir="ltr">
<div>>Just to be clear.. is this with the rtl22xx or
rtl22xx_t BSP? The non-thumb version<br>
>uses -mapcs-frame which no other BSP uses. That makes me
wonder.<br>
<br>
</div>
<div>rtl22xx_t 'Thumb', -mapcs-frame is passed on the gcc
command line.<br>
<br>
</div>
</div>
</blockquote></div>
If this is the BSP you are using, take it off and try again. This is
the only BSP<br>
using this option. Sebastian can probably comment on the other
arguments.<div><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
>Not with RTEMS. When you enter/exit an ISR, you go through
some<br>
>code which saves the proper registers, probably switches
you to<br>
>a dedicated stack, and does the OS stuff needed so it will
do<br>
>any needed dispatching at the end of the interrupt.<br>
<br>
</div>
Is this shared between BSPs ? i tried to look for this and
failed.<br>
<br>
<div>
<br>
</div>
</div>
</blockquote></div>
It is absolutely shared. The BSP has to provide some glue code but<br>
between libbsp/shared, libbsp/<ARCH>/shared, and the
appropriate<br>
libcpu directory, you will find the code.<br>
<br>
Look for shared and libcpu in the Makefile.am.<br>
<br>
Now as Sebastian says, the handler might be mis-registered as raw<br>
not OS interrupt. And the BSP may have been mechanically converted<br>
to the new shared PIC interrupt code used by many BSPs but not<br>
tested.<div><div><br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 17 April 2013 15:34, 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>
<div>On 4/17/2013 9:04 AM, Matthew J Fletcher wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Hi,<br>
<br>
</div>
Yes it the stack pointer out of range, because the
current stack pointer returned by GCC
_builtin_frame_XX in the IDLE thread looks like
its actually that from the Init() thread.<br>
<br>
</div>
</div>
</blockquote>
</div>
You are completely in C code when this happens. There has
been assembly<br>
to switch to the task initially (e.g. into
_Thread_Handler) and if an interrupt<br>
occurred.<br>
<br>
If you put an explicit call to
rtems_stack_checker_is_blown() in Init() at<br>
various points, does it think things are OK?<br>
<br>
It is easy for the stack not to be initialized to match
gcc or gdb's expectation<br>
of how it ends.<br>
<br>
Just to be clear.. is this with the rtl22xx or rtl22xx_t
BSP? The non-thumb version<br>
uses -mapcs-frame which no other BSP uses. That makes me
wonder.
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div>Thinking this through,my target is Thumb, so
the C interrupt handler should be in a arm file
with -mthumb-interwork set on the compile line.<br>
<br>
</div>
<div>I guess GCC can not auto-magicly know what
particular functions are interrupts, so should
there be some entry/exit functions to save/restore
the stack, etc, like these...<br>
</div>
<div><br>
<a href="http://www.procyonengineering.com/embedded/arm/armlib/docs/html/group__processor__lpc2000.html" target="_blank">http://www.procyonengineering.com/embedded/arm/armlib/docs/html/group__processor__lpc2000.html</a><br>
<br>
ISR_ENTRY / ISR_EXIT <br>
<br>
</div>
<div><br>
</div>
</div>
</blockquote>
</div>
Not with RTEMS. When you enter/exit an ISR, you go through
some<br>
code which saves the proper registers, probably switches
you to<br>
a dedicated stack, and does the OS stuff needed so it will
do<br>
any needed dispatching at the end of the interrupt.<span><font color="#888888"><br>
<br>
--joel</font></span>
<div>
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 17 April 2013 13:40,
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>On 04/17/2013 02:27 PM, Matthew J
Fletcher wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> >Here a
context switch from the Init to the idle
(I guess) thread happens.<br>
The >_User_extensions_Thread_switch<br>
>() is called before the context
switch and the running thread is checked.
So<br>
a sp of >0x814d299c must be in the
range of the Init stack area.<br>
<br>
Yes it is, Init() stack area is 0x814d1a70
-> 0x814d2a74 (4100 bytes). So it<br>
looks like the stack pointer is not
getting adjusted correctly when task<br>
switching into a new thread ? as the
rtems_idle task is using the Init() stack<br>
pointer.<br>
</blockquote>
<br>
</div>
Now I am a bit confused. What check goes
wrong in
<div><br>
<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>
</div>
?<br>
<br>
In case the stack pointer is out of range,
then I guess that the interrupt exception
processing is broken. It is hard to know what
happens without an actual target.
<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
> nm your-app.exe | grep
'bsp_\(section\|stack\)' | sort<br>
<br>
No matches.<br>
</blockquote>
<br>
</div>
Ok, 4.10 uses the old linker command files.
These symbols are only available in 4.11.
<div>
<div><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>
</div>
</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>
</div>
</div>
<div>
<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>
</div>
</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 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>
</div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br>
</div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br>
</div>