<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/18/2013 3:01 PM, Matthew J
Fletcher wrote:<br>
</div>
<blockquote
cite="mid:CAPy9Timh7NNgZo+JsAFxL0p+es5s77PYkb-B4iZDRSMBUJeV4w@mail.gmail.com"
type="cite">
<div dir="ltr">> <span
style="font-family:arial,sans-serif;font-size:13px">Are you
not able to relocate the vector table base address?</span>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div style=""><font face="arial, sans-serif">My understanding is
that you cannot on the ARM7TDMI, you can on the later Cortex
cores, and also on the 20 year old CPU32/m68k 68340's we use
!</font></div>
</div>
<div class="gmail_extra">
<br>
</div>
</blockquote>
On at least PowerPCs, the preamble in Flash jumps to a common<br>
place in a known state. Like the cause/vector in a register and a
known set<br>
of registers saved.<br>
<br>
Could you effectively do this in the code at 0x0? And end up in your
application<br>
at the beginning of the RTEMS ISR Handler code? I am thinking an
indirect jump<br>
or carefully placing the address of the common entry at a fixed
location.<br>
<br>
--joel<br>
<br>
<blockquote
cite="mid:CAPy9Timh7NNgZo+JsAFxL0p+es5s77PYkb-B4iZDRSMBUJeV4w@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 18 April 2013 20:56, Gedare Bloom <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Are you not able to relocate the vector table base address?<br>
<div class="HOEnZb">
<div class="h5"><br>
On Thu, Apr 18, 2013 at 3:21 PM, Matthew J Fletcher <<a
moz-do-not-send="true" href="mailto:amimjf@gmail.com">amimjf@gmail.com</a>>
wrote:<br>
> Hi,<br>
><br>
> During my cycle home the answer became clear, all i
need to do is take a<br>
> copy of the arm_exc_interrupt asm, break it out
into bits done before before<br>
> calling any functions in the 'C' interrupt handler,
and those that need to<br>
> be done right at the end. Some advice on exactly
what that split might be<br>
> would be much appreciated.<br>
><br>
> I think i would need to add the GCC attribute
'naked'<br>
> <a moz-do-not-send="true"
href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html"
target="_blank">http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html</a>
so no automatic<br>
> stack push/pops are generated.<br>
><br>
><br>
><br>
><br>
> On 18 April 2013 18:39, Matthew J Fletcher <<a
moz-do-not-send="true" href="mailto:amimjf@gmail.com">amimjf@gmail.com</a>>
wrote:<br>
>><br>
>> Hi<br>
>><br>
>><br>
>> > The C function should match the
rtems_interrupt_handler typedef.<br>
>><br>
>> I've corrected that, no change. I think the
issue is that no handler is<br>
>> getting registered. I believe you said
previously that ISR_Handler() was the<br>
>> single entry point for all interrupt vectors
then it works out what vector<br>
>> its called on and calls the appropriate
handler.<br>
>><br>
>> ARM looks to be the odd one out in that it uses
in<br>
>> /cpukit/score/cpu/arm/arm_sec_interrupt.S<br>
>><br>
>> I remember now what problem might be, i had to
remove the<br>
>> _CPU_ISR_install_vector() call which add
arm_exc_interrupt because on my<br>
>> hardware the vector table at 0x0000000 is
mapped to on ARM internal flash<br>
>> (which does contain basic interrupt handlers),
not RAM.<br>
>><br>
>> I've now got a sinking feeling that i cant use
rtems on my hardware as is.<br>
>> I suppose this is a question for Sebastian, but
when i<br>
>> rtems_interrupt_handler_<br>
>> install() can the handler just be
'arm_exc_interrupt', and the argument<br>
>> the vector number ?<br>
>><br>
>> I've got my fingers crossed for the answer.<br>
>><br>
>><br>
>><br>
>> On 18 April 2013 17:46, Gedare Bloom <<a
moz-do-not-send="true" href="mailto:gedare@rtems.org">gedare@rtems.org</a>>
wrote:<br>
>>><br>
>>> On Thu, Apr 18, 2013 at 12:02 PM, Matthew J
Fletcher <<a moz-do-not-send="true"
href="mailto:amimjf@gmail.com">amimjf@gmail.com</a>><br>
>>> wrote:<br>
>>> > Hi,<br>
>>> ><br>
>>> > I presume all that needs to be done is
call bsp_interrupt_initalize()<br>
>>> > and<br>
>>> > then
rtems_interrupt_handler_install(), passing in your BSP
specific<br>
>>> > interrupt vector and any old C
function as the handler ?<br>
>>> ><br>
>>> ><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__rtems__interrupt__extension.html"
target="_blank">http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__rtems__interrupt__extension.html</a><br>
>>><br>
>>> The C function should match the
rtems_interrupt_handler typedef.<br>
>>><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On 18 April 2013 14:56, Matthew J
Fletcher <<a moz-do-not-send="true"
href="mailto:amimjf@gmail.com">amimjf@gmail.com</a>>
wrote:<br>
>>> >><br>
>>> >> Hi,<br>
>>> >><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>
>>> >> Is there an example of a BSP
registering a tick interrupt that i can<br>
>>> >> examine/copy ? this morning
attempts to change the use of<br>
>>> >> rtems_interrupt_handler_install()
has just resulted in unhandled IRQ<br>
>>> >> exceptions.<br>
>>><br>
>>>
libbsp/arm/shared/lpc/clock/lpc-clock-config.c appears
to do it.<br>
>>><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> On 17 April 2013 16:01, Joel
Sherrill <<a moz-do-not-send="true"
href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>><br>
>>> >> wrote:<br>
>>> >>><br>
>>> >>> On 4/17/2013 9:47 AM, Matthew
J Fletcher wrote:<br>
>>> >>><br>
>>> >>> >If you put an explicit
call to rtems_stack_checker_is_blown() in<br>
>>> >>> > Init()<br>
>>> >>> > at<br>
>>> >>> >various points, does it
think things are OK?<br>
>>> >>><br>
>>> >>> I put in a few and even the
last one before the Init() task deletes<br>
>>> >>> itself is ok.<br>
>>> >>><br>
>>> >>><br>
>>> >>> OK.<br>
>>> >>><br>
>>> >>> >Just to be clear.. is this
with the rtl22xx or rtl22xx_t BSP? The<br>
>>> >>> > non-thumb version<br>
>>> >>> >uses -mapcs-frame which no
other BSP uses. That makes me wonder.<br>
>>> >>><br>
>>> >>> rtl22xx_t 'Thumb',
-mapcs-frame is passed on the gcc command line.<br>
>>> >>><br>
>>> >>> If this is the BSP you are
using, take it off and try again. This is<br>
>>> >>> the<br>
>>> >>> only BSP<br>
>>> >>> using this option. Sebastian
can probably comment on the other<br>
>>> >>> arguments.<br>
>>> >>><br>
>>> >>><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>
>>> >>> Is this shared between BSPs ?
i tried to look for this and failed.<br>
>>> >>><br>
>>> >>><br>
>>> >>> 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.<br>
>>> >>><br>
>>> >>><br>
>>> >>><br>
>>> >>> On 17 April 2013 15:34, Joel
Sherrill <<a moz-do-not-send="true"
href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>><br>
>>> >>> wrote:<br>
>>> >>>><br>
>>> >>>> On 4/17/2013 9:04 AM,
Matthew J Fletcher wrote:<br>
>>> >>>><br>
>>> >>>> Hi,<br>
>>> >>>><br>
>>> >>>> Yes it the stack pointer
out of range, because the current stack<br>
>>> >>>> pointer<br>
>>> >>>> returned by GCC
_builtin_frame_XX in the IDLE thread looks like its<br>
>>> >>>> actually<br>
>>> >>>> that from the Init()
thread.<br>
>>> >>>><br>
>>> >>>> You are completely in C
code when this happens. There has been<br>
>>> >>>> assembly<br>
>>> >>>> to switch to the task
initially (e.g. into _Thread_Handler) and if<br>
>>> >>>> an<br>
>>> >>>> interrupt<br>
>>> >>>> occurred.<br>
>>> >>>><br>
>>> >>>> If you put an explicit
call to rtems_stack_checker_is_blown() in<br>
>>> >>>> Init()<br>
>>> >>>> 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<br>
>>> >>>> expectation<br>
>>> >>>> of how it ends.<br>
>>> >>>><br>
>>> >>>> Just to be clear.. is this
with the rtl22xx or rtl22xx_t BSP? The<br>
>>> >>>> non-thumb version<br>
>>> >>>> uses -mapcs-frame which no
other BSP uses. That makes me wonder.<br>
>>> >>>><br>
>>> >>>> Thinking this through,my
target is Thumb, so the C interrupt handler<br>
>>> >>>> should be in a arm file
with -mthumb-interwork set on the compile<br>
>>> >>>> line.<br>
>>> >>>><br>
>>> >>>> I guess GCC can not
auto-magicly know what particular functions are<br>
>>> >>>> interrupts, so should
there be some entry/exit functions to<br>
>>> >>>> save/restore the<br>
>>> >>>> stack, etc, like these...<br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> <a moz-do-not-send="true"
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>
>>> >>>><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>
>>> >>>> --joel<br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> On 17 April 2013 13:40,
Sebastian Huber<br>
>>> >>>> <<a
moz-do-not-send="true"
href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>>
wrote:<br>
>>> >>>>><br>
>>> >>>>> On 04/17/2013 02:27
PM, Matthew J Fletcher wrote:<br>
>>> >>>>>><br>
>>> >>>>>> >Here a
context switch from the Init to the idle (I guess)
thread<br>
>>> >>>>>> happens.<br>
>>> >>>>>> The
>_User_extensions_Thread_switch<br>
>>> >>>>>> >() is called
before the context switch and the running thread is<br>
>>> >>>>>> 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<br>
>>> >>>>>> bytes).<br>
>>> >>>>>> So it<br>
>>> >>>>>> looks like the
stack pointer is not getting adjusted correctly<br>
>>> >>>>>> when<br>
>>> >>>>>> task<br>
>>> >>>>>> switching into a
new thread ? as the rtems_idle task is using the<br>
>>> >>>>>> Init() stack<br>
>>> >>>>>> pointer.<br>
>>> >>>>><br>
>>> >>>>><br>
>>> >>>>> Now I am a bit
confused. What check goes wrong in<br>
>>> >>>>><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<br>
>>> >>>>> 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>
>>> >>>>> ?<br>
>>> >>>>><br>
>>> >>>>> In case the stack
pointer is out of range, then I guess that the<br>
>>> >>>>> interrupt exception
processing is broken. It is hard to know what<br>
>>> >>>>> happens<br>
>>> >>>>> without an actual
target.<br>
>>> >>>>><br>
>>> >>>>><br>
>>> >>>>>><br>
>>> >>>>>> > nm
your-app.exe | grep 'bsp_\(section\|stack\)' | sort<br>
>>> >>>>>><br>
>>> >>>>>> No matches.<br>
>>> >>>>><br>
>>> >>>>><br>
>>> >>>>> Ok, 4.10 uses the old
linker command files. These symbols are only<br>
>>> >>>>> available in 4.11.<br>
>>> >>>>><br>
>>> >>>>><br>
>>> >>>>> --<br>
>>> >>>>> Sebastian Huber,
embedded brains GmbH<br>
>>> >>>>><br>
>>> >>>>> Address : Dornierstr.
4, D-82178 Puchheim, Germany<br>
>>> >>>>> Phone : +49 89 189
47 41-16<br>
>>> >>>>> Fax : +49 89 189
47 41-09<br>
>>> >>>>> E-Mail : <a
moz-do-not-send="true"
href="mailto:sebastian.huber@embedded-brains.de">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<br>
>>> >>>>> EHUG.<br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> --<br>
>>> >>>><br>
>>> >>>> regards<br>
>>> >>>> ---<br>
>>> >>>> Matthew J Fletcher<br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> --<br>
>>> >>>> Joel Sherrill, Ph.D.
Director of Research & Development<br>
>>> >>>> <a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a>
On-Line Applications Research<br>
>>> >>>> Ask me about RTEMS: a free
RTOS Huntsville AL 35805<br>
>>> >>>> Support Available
(256) 722-9985<br>
>>> >>><br>
>>> >>><br>
>>> >>><br>
>>> >>><br>
>>> >>> --<br>
>>> >>><br>
>>> >>> regards<br>
>>> >>> ---<br>
>>> >>> Matthew J Fletcher<br>
>>> >>><br>
>>> >>><br>
>>> >>><br>
>>> >>> --<br>
>>> >>> Joel Sherrill, Ph.D.
Director of Research & Development<br>
>>> >>> <a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a>
On-Line Applications Research<br>
>>> >>> Ask me about RTEMS: a free
RTOS Huntsville AL 35805<br>
>>> >>> Support Available
(256) 722-9985<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> --<br>
>>> >><br>
>>> >> regards<br>
>>> >> ---<br>
>>> >> Matthew J Fletcher<br>
>>> >><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > --<br>
>>> ><br>
>>> > regards<br>
>>> > ---<br>
>>> > Matthew J Fletcher<br>
>>> ><br>
>>> ><br>
>>> >
_______________________________________________<br>
>>> > rtems-users mailing list<br>
>>> > <a moz-do-not-send="true"
href="mailto:rtems-users@rtems.org">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>
>>> ><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>> regards<br>
>> ---<br>
>> Matthew J Fletcher<br>
>><br>
><br>
><br>
><br>
> --<br>
><br>
> regards<br>
> ---<br>
> Matthew J Fletcher<br>
><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <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>