<div dir="ltr"><div><div><div>Hi<br><br>> The C function should match the rtems_interrupt_handler typedef.<br><br></div>I've corrected that, no change. I think the issue is that no handler is getting registered. I believe you said previously that ISR_Handler() was the single entry point for all interrupt vectors then it works out what vector its called on and calls the appropriate handler.<br>
<br></div>ARM looks to be the odd one out in that it uses in /cpukit/score/cpu/arm/arm_sec_interrupt.S <br><br>I remember now what problem might be, i had to remove the _CPU_ISR_install_vector() call which add arm_exc_interrupt because on my hardware the vector table at 0x0000000 is mapped to on ARM internal flash (which does contain basic interrupt handlers), not RAM.<br>
<br></div><div>I've now got a sinking feeling that i cant use rtems on my hardware as is. I suppose this is a question for Sebastian, but when i rtems_interrupt_handler_<div class="im">install() can the handler just be 'arm_exc_interrupt', and the argument the vector number ?<br>
</div></div><div><br></div><div>I've got my fingers crossed for the answer.<br></div><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 April 2013 17:46, Gedare Bloom <span dir="ltr"><<a 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"><div class="im">On Thu, Apr 18, 2013 at 12:02 PM, Matthew J Fletcher <<a href="mailto:amimjf@gmail.com">amimjf@gmail.com</a>> wrote:<br>

> Hi,<br>
><br>
</div><div class="im">> I presume all that needs to be done is call bsp_interrupt_initalize() 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>
</div><a 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>
<div class="im"><br>
><br>
><br>
><br>
><br>
> On 18 April 2013 14:56, Matthew J Fletcher <<a 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>
</div>libbsp/arm/shared/lpc/clock/lpc-clock-config.c appears to do it.<br>
<div class="HOEnZb"><div class="h5"><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On 17 April 2013 16:01, Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>> 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 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 the<br>
>>> only BSP<br>
>>> using this option. Sebastian can probably comment on the other 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 href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>> 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 pointer<br>
>>>> returned by GCC _builtin_frame_XX in the IDLE thread looks like its actually<br>
>>>> that from the Init() thread.<br>
>>>><br>
>>>> 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<br>
>>>> interrupt<br>
>>>> occurred.<br>
>>>><br>
>>>> If you put an explicit call to rtems_stack_checker_is_blown() in 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 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 save/restore the<br>
>>>> stack, etc, like these...<br>
>>>><br>
>>>><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>
>>>><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 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 bytes).<br>
>>>>>> So it<br>
>>>>>> looks like the stack pointer is not getting adjusted correctly 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 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 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 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 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>
>>>> joel.sherrill@OARcorp.com        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>
>>> joel.sherrill@OARcorp.com        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>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> rtems-users mailing list<br>
> <a href="mailto:rtems-users@rtems.org">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>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br>
</div>