This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Interrupt and IO-device driver


>>>>> "Daniel" == Daniel Lind <daniel.lind@sth.frontec.se> writes:

Daniel> Hi, I dont really know how to check that the CPM arbiter is
Daniel> properly set.  Where does this ISR attach?  I don't understand
Daniel> how the function hal_arbitration_isr_cpm works. I placed a
Daniel> breakpoint inside this function but the program never reached
Daniel> this function. Shall it to do that?

Yes, it should. See below.

Daniel> Besides this I can't understand how the interrupts in the
Daniel> PowerPC, MPC860, works. I'm not used to this processor. In
Daniel> other controllers that I have used there is an interruptvector
Daniel> where you attach adresses to where the program is going to
Daniel> continue after an interrupt occour. Is there anything like
Daniel> this in PowerPC? The SIVEC in SIU doesn't seem to work like
Daniel> this...Where is the actual interrupt that interrupts the
Daniel> processor and orders the processor to go to another place in
Daniel> the code? I have tried to read everything about the core,
Daniel> because it's to the core that the interrupt finally will be
Daniel> sent (or am I wrong?)............(after some more
Daniel> reading).......Now I have found out that there is an exception
Daniel> vector table and that external interrupt is in this table.

Indeed, the somewhat untraditional behavior is what makes this a bit
different from other HALs.

Seeing as the various interrupt sources can be programmed to trigger
any of the 7 CYGNUM_HAL_INTERRUPT_SIU_LVL interrupts, we need some
magic to route the execution path to the proper interrupt handler.

This is what the arbiters do. They are small functions that you put on
the (appropriate, as per interrupt source configuration) SIU interrupt
vector. When called they examine their dedicated interrupt request
flag, figure out which CYGNUM_HAL_INTERRUPT_ vector the interrupt has,
and jumps to that vector.

And that may repeat something like 3 times, if I rememeber
correctly. Pretty nasty.

In your case, you'd put first the CPM arbiter on one of the SIO_LVL
vectors, and program the CPM to use that level (that's what
hal_variant_IRQ_init() does).

Then when the CPM arbiter is called, it finds the CPM sub-module which
caused the interrupt, and jumps to its vector. In this case, SCC2.


Since the CPM arbiter is attached and enabled per default, it's
somewhat worrying that it doesn't seem to be executed.

So what you should do is (a) ensure that the proper ISRs are set
(CYGNUM_HAL_INTERRUPT_SIU_LVL_?, CYGNUM_HAL_INTERRUPT_SIU_CPM, and
CYGNUM_HAL_INTERRUPT_CPM_SCC2), and (b) follow the flow through these
to make sure they do what you expect them to do, and check that the
hardware registers have the expected contents.

Daniel> What function in eCos is called after an interrupt has
Daniel> occured? It must be some kind of function that finds out what
Daniel> source that have caused the interrupt.

cyg_hal_default_interrupt_vsr, which uses hal_intc_decode (defined in
mpc8xx/variant.inc) that does the SIU level decoding.

Daniel> I have found the function hal_variant_IRQ_init(void) a few
Daniel> lines down in var_intr.c. Is this a function that I must call,
Daniel> or is it done by eCos?

It should be done by eCos during system initialization.

Daniel> The mpc8xx/intr0 test doesn't PASS on my board, MBX860. After
Daniel> debugging the test I find out the following...

Daniel> from this function the program goes to externC cyg_uint32
Daniel> hal_arbitration_isr_pit (CYG_ADDRWORD vector, CYG_ADDRWORD
Daniel> data)

Daniel> The program runs through this function and after this goes to
Daniel> function void hal_variant_init(void) in var_misc.c The program
Daniel> seems to get stuck in, it never leaves, void
Daniel> hal_variant_init(void)

That's plain weird. The pit arbiter should not end up in any of the
init functions.

Daniel> One thing that I can't understand is that "PowerPC QUICC/
Daniel> seriel port 2 driver" functions with interrupts. I have looked
Daniel> at this driver then writing the SCC2 driver, whats the
Daniel> difference between the initializations of the interrupts? The
Daniel> code looks just the same to me....is this driver doing some
Daniel> initializations which I can't see in quicc_smc_serial.c?

The existing driver is a SMC driver. You're doing a SCC driver. There
may well be some extra bits that need fiddling which are not fiddled
by the existing init code.

Jesper

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]