<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><br><div class="gmail_quote">On 18 April 2013 20:56, 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">
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 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 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 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 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 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 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 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 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 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 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<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 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>
>>> >>>> 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>
>>> > _______________________________________________<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>
>><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>