This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Abhilash R wrote: > > Hello, > We are using GNU C compiler in one of our project. The microcontroller > on our target board is MMC2107. However we are facing some problem > during interrupt handling. > > In my code I have defined an interrupt as fast interrupt coming on egde > port EP.4. I have done all the initialisations properly & simulated that > interrupt using Interrupt force register of MMC2107. Reading back the > status register shows that interrupt is valid & there is an interrupt > pending for execution. However the branching to ISR is not happening. AFAIK the M.CORE "interrupt processing uses an interrupt vector table and a set of internal shadow registers while making the transition to an Interrupt Service Routine (ISR)", as one of my docs says... And : ------------- "The FINT is the fast interrupt request input. If enabled the FE bit in PSR is set, it has higher priority than the normal interrupt input INT. Fast interrupts use the FPSR and FPC exception shadow registers and consequently are not masked when the EE bit in PSR is cleared. Fast interrupts are masked when the FE bit in PSR is cleared. When FINT is asserted, either the AVEC input can be asserted to cause autovectoring to occur, or a 7-bit vector number can be provided to select one of vectors 32-127 to be used. (No explicit attempt is made by the processor to preclude use of vectors 0-31.) If a fast interrupt is autovectored, the vector at offset 0x2C from the vector table base is used. So for the vectorable interrupts FINT and INT, a seven-bit interrupt vector number can be supplied at the time a request is generated, or the autovector input AVEC can be asserted to indicate that the appropriate predefined vector should be used. If AVEC is asserted, the VEC# inputs are ignored." ------------- I see this meaning that either the AVEC-input must be set to something, then the address entry in offset 0x2c in the vector table will be used, ie. only one fast interrupt is in use... Or a 7-bit vector number is put somewhere (on the VEC# inputs ?) and the vectors 32-127 in the vector table will be used for the 96 possible Fast-ISR's... You didn't mention the interrupt vector table at all, although it will be needed in both cases, so perhaps it is simply missing... And the state of the AVEC input was left unclear... Also AFAIK the plain vanilla GCCs for M.CORE don't include any ISR-support, like producing the following prologue and epilogue with the '__attribute__((interrupt))' or something: ------------- .file "isr_demo.c" gcc2_compiled.: .text .align 1 .export handle_intr .type handle_intr,@function handle_intr: subi sp,32 subi sp,28 stm r1-r15,(sp) <the function code> ldm r1-r15,(sp) addi sp,32 addi sp,28 rte ------------- So I'm curious how you now produce the ISRs with GCC ? Over a year ago I did some fixes to the 'mcore-elf' support in my GCC-sources and added some kind of ISR-support... But haven't seen anybody else asking about this possibility. > Kindly let us know the solution for this problem as soon as possible. Was this soon enough ? ;-) Cheers, Kai ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |