interrupt handling

[Kai Ruottu]

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