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: Re: Interrupt and IO-device driver


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:<Intr 0 Failed.> Line: 147, File:
//C/PROGRA~1/REDHAT~1/eCos/packages/hal/powerpc/mpc8xx/v1_3_1/tests/intr0.c

EXIT:<done>

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 <daniel.lind@sth.frontec.se> 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


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