From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Lind To: ecos-discuss@sourceware.cygnus.com Subject: Re: Re: [ECOS] Interrupt and IO-device driver Date: Thu, 19 Oct 2000 04:17:00 -0000 Message-id: <39EED88F.4447E92D@bluelabs.se> References: <39ED54A6.6B90D0FB@bluelabs.se> X-SW-Source: 2000-10/msg00206.html Hi, I dont really know how to check that the CPM arbiter is properly set. Where does this ISR attach? I don't understand how the function hal_arbitration_isr_cpm works. I placed a breakpoint inside this function but the program never reached this function. Shall it to do that? externC cyg_uint32 hal_arbitration_isr_cpm (CYG_ADDRWORD vector, CYG_ADDRWORD data) Besides this I can't understand how the interrupts in the PowerPC, MPC860, works. I'm not used to this processor. In other controllers that I have used there is an interruptvector where you attach adresses to where the program is going to continue after an interrupt occour. Is there anything like this in PowerPC? The SIVEC in SIU doesn't seem to work like this...Where is the actual interrupt that interrupts the processor and orders the processor to go to another place in the code? I have tried to read everything about the core, because it's to the core that the interrupt finally will be sent (or am I wrong?)............(after some more reading).......Now I have found out that there is an exception vector table and that external interrupt is in this table. What function in eCos is called after an interrupt has occured? It must be some kind of function that finds out what source that have caused the interrupt. I have found the function hal_variant_IRQ_init(void) a few lines down in var_intr.c. Is this a function that I must call, or is it done by eCos? The mpc8xx/intr0 test doesn't PASS on my board, MBX860. After debugging the test I find out the following... // Periodic timer ISR. Should be executing 5 times. static cyg_uint32 isr_pit(CYG_ADDRWORD vector, CYG_ADDRWORD data) is called 1 time atfer this function has finished the program goes to static inline cyg_uint32 hal_call_isr (cyg_uint32 vector) from this function the program goes to externC cyg_uint32 hal_arbitration_isr_pit (CYG_ADDRWORD vector, CYG_ADDRWORD data) The program runs through this function and after this goes to function void hal_variant_init(void) in var_misc.c The program seems to get stuck in, it never leaves, void hal_variant_init(void) When I run the tests in eCos config tool I get the following result..... *** 12:58:28 Run started GNU gdb 20000926 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-cygwin --target=powerpc-eabi"... (gdb) set height 0 (gdb) set remotedebug 0 Warning: command 'set remotedebug' is deprecated. Use 'set debug remote'. (gdb) set remotebaud 38400 (gdb) target remote com1 Remote debugging using com1 0xfe005d98 in ?? () (gdb) load Loading section .text, size 0x7d5c lma 0x10000 Loading section .rodata, size 0x16b8 lma 0x17d60 Loading section .data, size 0x778 lma 0x19418 Start address 0x10000 , load size 39820 Transfer rate: 26546 bits/sec, 504 bytes/write. (gdb) break cyg_test_exit Breakpoint 1 at 0x138cc: file //C/PROGRA~1/REDHAT~1/eCos/packages/infra/v1_3_1/src/tcdiag.cxx, line 116. (gdb) break cyg_assert_fail Function "cyg_assert_fail" not defined. (gdb) break cyg_test_init Breakpoint 2 at 0x137ac: file //C/PROGRA~1/REDHAT~1/eCos/packages/infra/v1_3_1/src/tcdiag.cxx, line 62. (gdb) cont Continuing. Breakpoint 2, cyg_test_init () at //C/PROGRA~1/REDHAT~1/eCos/packages/infra/v1_3_1/src/tcdiag.cxx:62 62 } Current language: auto; currently c++ (gdb) set cyg_test_is_simulator=0 Address of symbol "cyg_test_is_simulator" is unknown. (gdb) cont Continuing. FAIL: Line: 147, File: //C/PROGRA~1/REDHAT~1/eCos/packages/hal/powerpc/mpc8xx/v1_3_1/tests/intr0.c EXIT: Breakpoint 1, cyg_test_exit () at //C/PROGRA~1/REDHAT~1/eCos/packages/infra/v1_3_1/src/tcdiag.cxx:116 116 ; (gdb) *** 12:59:09 Run complete I have verified that the CPM interrupt is unmasked properly, CIMR is 0x20000000 which is SCC2. One thing that I can't understand is that "PowerPC QUICC/ seriel port 2 driver" functions with interrupts. I have looked at this driver then writing the SCC2 driver, whats the difference between the initializations of the interrupts? The code looks just the same to me....is this driver doing some initializations which I can't see in quicc_smc_serial.c? /Daniel Lind Jesper Skov wrote: > >>>>> "Daniel" == Daniel Lind writes: > > Daniel> Hi, I'm using PowerPC MBX860 and I'm trying to write a device > Daniel> driver for SCC2. Look bellow for the code.... The interrupts > Daniel> doesn't seem to work right. I have investigated SCCE[Tx] and > Daniel> this bit is set after a buffert is sent, so this is ok. I have > Daniel> also checked CIPR (CPM interrupt pending register) and this > Daniel> register tells me that an interrupt is pending on SCC2, this > Daniel> is also ok. After doing these tests I think that the problem > Daniel> is that I haven't initialized the interrupts in the right > Daniel> way.....ISR and DSR are never called. > > Does the CPM arbiter in var_intr.c (hal_arbitration_isr_cpm) get > properly set up? It probably does if you selected the 860 variant. > > Still, that's the only thing in the chain I can think of (off hand) as > being broken. Do the mpc8xx/intr0 test PASS on your board? > > Daniel> void scc_uart_init_int(void){ > Daniel> cyg_drv_interrupt_create(CYGNUM_HAL_INTERRUPT_CPM_SCC2, > Daniel> CYGARC_SIU_PRIORITY_HIGH, (cyg_addrword_t) &buffers, > Daniel> scc_uart_ISR, scc_uart_DSR, &serial_interrupt_handle, > Daniel> serial_interrupt); > Daniel> cyg_drv_interrupt_attach(serial_interrupt_handle); > Daniel> cyg_drv_interrupt_unmask(CYGNUM_HAL_INTERRUPT_CPM_SCC2); } > > Also please verify that the CPM interrupt is unmasked properly (it > would be if the intr0 test PASSes). > > Finally, you should try to enable assertions (enable > CYGDBG_USE_ASSERTS and CYGPKG_INFRA_DEBUG) to catch any unhandled > interrupts. > > Jesper