[ECOS] Interrupt and IO-device driver

Daniel Lind daniel.lind@sth.frontec.se
Fri Oct 20 02:19:00 GMT 2000

Have have one question, where does the siu register sipend reset? What
function? I need to know so I can decide if it's PowerPc problems or board
problems. I'm working on checking that the proper ISRs are set, but I
haven't figured out how to check it yet.

After my Tx interrupt has occoured, the following is in the registers

SIPEND 0 , is not set, and no other function is called that could have
reset SIPEND...as far as I know. Where does sipend reset?

SIMASK 0x10000, ie level mask 7

sivec 0x3c00000, this is not changed during the run of the program, value
after intializing, this corrsponds to level7...hmmmm. It's this value
before intitialization and after and intialization...always the same....

scc_scce 0x102, ie transmit interrupt, ok

CPMI_CIPR 0x200000018, SCC2 interrupt pending, besides this the register
tells me that SMC1 and SMC2 interrupt is pending, I don't understand why.

But if you look at all registers above and think off that no function in
eCos is called ( i stepped through the whole program from the begining to
the end) the problem doesn't seem to be eCos. I must have some problem
with the SIU. Can I be right?

Are the interrupts enabled globally? I write a function that reads
msr = 0x10e08 after initialization 1 0000 1110 0000 1000 , this tells that
the interrupts are enabled


Jesper Skov wrote:

> >>>>> "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_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

More information about the Ecos-discuss mailing list