The problem with skyeye and csb337
Ray
xr at trasin.net
Sat Jun 16 10:15:33 UTC 2007
I suspect skyeye do not implement the timer/ticker interrupt. So we can not set the interrupt right and CPU will not be acknowledged when interrupt comes.
Also, I suspect tick-register will not increase when CPU is running.
You can check the register related to timer and AIC. From my quick grep in skyeye source codes, it seems the function is not implemented.
BTW, I am pretty sure that CSB337 ticker runs very well in real hardware.
------------------
Thanks & Best Regards!
Ray
2007-06-16
-------------------------------------------------------------
From: Joel Sherrill
Date: 2007-06-16 04:51:03
To: xi yang
CC: RTEMS Users
Sub: Re: The problem with skyeye and csb337
>>xi yang wrote:
>>> joel
>>> Are you running hello or ticker?
>> I am running ricker.
>Then it doesn't make sense that you didn't get a break point
>at that code. Try to break at Clock_initialize which is the
>device driver initialization function for the clock.
>
>Do you get to the Init task? Do you see 4 lines of output
>and then TA1, TA2, and TA3 block and the idle task runs for
>a while?
>>> The code in
>>> c/src/lib/libcpu/arm/at91rm9200/clock has this routine
>>>
>>> static void clock_isr_on(const rtems_irq_connect_data *unused)
>>> {
>>> /* enable timer interrupt */
>>> ST_REG(ST_IER) = ST_SR_PITS;
>>> }
>>>
>>> which should be invoked when the interrupt is connected
>>> via a call to BSP_install_rtems_irq_handler in the irq directory
>>> one level up.
>> The problem is BSP_install_rtems_irq_handler with clock handler has
>> not been
>> invoked.
>>>
>>> > 2ed.It seems that after disabled all the interrupt sources and
>>> > install the
>>> > default_int_handler() at all 32 interrupt source vector
>>> > registers,rtems
>>> > has not enabled the SYS interrupt source(number 1) of AIC
>>> > and also has
>>> > not installed the CLOCK interrupt handler(I guss rtems
>>> > use interrupt
>>> > managers to manage the interrupt of 32 lines.Because
>>> > there are more
>>> > than one devices use the same line,for example,system
>>> > clock and DBGU
>>> > use the same SYS interrupt source),but i can not find
>>> > where is the SYS
>>> > interrupt source manger,who can tell me?
>>> The code for interrupt management on this CPU should be
>>> in c/src/lib/libcpu/arm/at91m9200/irq. I don't see any
>>> that is board specific reference in csb337/Makefile.am
>>> > Since the interrupt of SYS is disable ,there is not any
>>> > clock interupt can be
>>> > delivered to CPU ,without the clock interrupt,the system
>>> > is hang in idl
>>> > task.
>>> > So i enable the interrupt of clock and SYS interrupt
>>> > source of AIC.Since
>>> > default_int_handler() is still in all 32 interrupt source
>>> > vector registers ,at
>>> > every clock interrupt ,the system traps into
>>> > default_int_handler();
>>> > So,there are
>>> > " raw_idt_notify has been called
>>> > 1
>>> > raw_idt_notify has been called
>>> > 2
>>> > ..." on my screen.
>>> > Q1,Where is the code installs SYS interrupt handler?
>>> > Q2,Where is the code enables the interrupt of clock device and
>>> AIC?
>>>
>>> c/src/lib/libcpu/arm/at91rm9200/irq - look for
>>> BSP_install_rtems_irq_handler
>>> and look what it does when the interrupt is dynamically installed:
>>>
>>> /*
>>> * store the new handler
>>> */
>>> AIC_SVR_REG(irq->name * 4) = (uint32_t) irq->hdl;
>>>
>>> /*
>>> * unmask interrupt
>>> */
>>> AIC_CTL_REG(AIC_IECR) = 1 << irq->name;
>>>
>>> /*
>>> * Enable interrupt on device
>>> */
>>> if(irq->on) {
>>> irq->on(irq);
>>> }
>> Yeah,i know this,and problem is that rtems has not executed
>> BSP_install_rtems_irq_handler for clock,i mean the clock interrupt
>> handler is not
>> installed.
>> I think i can resolve it when i am more familar with code of rtems.The
>> key
>> is to detect why BSP_install_rtems_irq_handler has not been invoked.
>>> i think that's all the code you are looking for. irq->on() goes back
>>> to the
>>> Clock driver "on" callback which I cut and pasted above.
>>>
>>>
>>> > I think code of Q1 contains code of Q2,and some unkonw reasons
>>> > result in
>>> > system has not executed the code of Q1.
>>> I don't know if I helped or not. Even though I maintain RTEMS, I
>>> am not an expert on every CPU it supports. I have to struggle
>>> through the manuals with the rest of you. :)
>> Thank you very much.
>> I will resolve it as soon as possible.
>> regards.
>>>
>>> --joel
>>>
>
>_______________________________________________
>rtems-users mailing list
>rtems-users at rtems.com
>http://rtems.rtems.org/mailman/listinfo/rtems-users
>
More information about the users
mailing list