From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Skov To: Daniel Lind Cc: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] Interrupt and IO-device driver Date: Thu, 19 Oct 2000 06:35:00 -0000 Message-id: References: <39ED54A6.6B90D0FB@bluelabs.se> <39EED88F.4447E92D@bluelabs.se> X-SW-Source: 2000-10/msg00216.html >>>>> "Daniel" == Daniel Lind 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