Interrupt Problem

Hi,

Some remarks of me.

In the HAL-API-Reference it is described that alt_irq_enable and alt_irq_disable are not be available within ISR. So better don't call it from inside your ISR.

Additonally, I prefer not to call printf or similarwithin your ISR.

Regards,

Philipp

@Philipp, Thanks to give time for reply

As per your suggetion i make changes in code,but stiil i got same problem.

Again thank you,

Regards,

jayesh

Hi again,

what I noticed now, is following

alt_irq_enable(NFC_BASE);

Did you mean alt_irq_enable(NFC_IRQ)? Because alt_irq_enable(NFC_BASE) can't be right.

Greets

@pillemann

No,first i use NFC_IRQ in

alt_irq_register(NFC_IRQ,edge_capture_ptr,handle_nfc_interrupts)

to Register the interrupt request of Nand flash controller(NFC)

then after i wrote code to enable IRQ of Nand flash controller(NFC) is below

alt_irq_enable(NFC_BASE);

so its right,problem occurs because of other thing not this.

Thanks for your rpy

Regards,

jayesh

--- Quote Start ---

Did you mean alt_irq_enable(NFC_IRQ)? Because alt_irq_enable(NFC_BASE) can't be right.

--- Quote End ---

Lots of altera macros are written based on the _BASE address of the device. The macro then adds the offset to the proper register, masks off the correct bit, etc. I haven't checked, but I'd assume that alt_irq_enable() is such a macro (but generally their macros are ALL_CAPS).

However, this does seem a little bit generic in that it implies that all devices have the interrupt enable bit in the same location. Is this so?

Hi jayesh, donq!

Sorry I was on a trip yesterday.

@jayesh:

--- Quote Start ---

so its right,problem occurs because of other thing not this.

--- Quote End ---

This might be true, I can't know it for sure.

But alt_irq_enable(nfc_base); is not the right call to alt_irq_enable().

Take a look the HAL API Reference.

--- Quote Start ---

int alt_irq_enable (alt_u32 id)

--- Quote End ---

And with id it is meant to use <YOUR_MODULE_NAME>_IRQ. This is the id which also specifies the priority of your interrupt, at least with the LEGACY Interrupt API.

I am pretty sure with this, because I've used the interrupt API quite a time.

@donq:

--- Quote Start ---

Lots of altera macros are written based on the _BASE address of the device.

--- Quote End ---

That's true. But in general all MACROS are defined with big letters. And alt_irq_enable() isn't. It is a function call.

--- Quote Start ---

but I'd assume that alt_irq_enable() is such a macro

--- Quote End ---

No, it isn't. Maybe it is a INLINE function, I've to check on monday at work. But it is not a MACRO.

Have a nice weekend!

Philipp

@philip,@donq

After some change in my code i reslove my problem now my code look like.

write()

{

//data write code

//enable NFC

/*************NEW CODE ADED*************/

IOWR(NFC_BASE,NFC_IRQ_CLR,0);

IOWR(NFC_BASE,NFC_IRQ_MASK,0x01);

alt_irq_enable(NFC_BASE);

/**************************************/

while(intrstat == 0);

intrstat = 0;//globel variable

}

read()

{

//data read code

//enable NFC

/*************NEW CODE ADED*************/

IOWR(NFC_BASE,NFC_IRQ_CLR,0);

IOWR(NFC_BASE,NFC_IRQ_MASK,0x01);

alt_irq_enable(NFC_BASE);

/**************************************/

while(intrstat == 0);

intrstat = 0;

}

main()

{

IOWR(LED_BASE,0,0);

alt_irq_register(NFC_IRQ,edge_capture_ptr,handle_n fc_interrupts);

alt_irq_enable(NFC_BASE);

write();

read();

}

static void handle_nfc_interrupts(void* context, alt_u32 id)

{

volatile int* irq_capture_ptr = (volatile int*) context;

irq_capture_ptr = IORD(ONFI_BASE,NFC_STATUS);

alt_irq_disable(ONFI_BASE);

IOWR(LED_BASE,0,1);

intrstat = 1;

}

But now my problem is when i issue write or read API back to Back or say in for loop(say 10 times) it just suspended in RUN mode in NIOS II.but it's work very well in Debug mode.

so what i make change in above code to solve above problem.................

Thanks to Philipp,donq to give time for me.

Have a nice Weekend!!!!!!!!!!!!!!!!!!!

Regards,

Jayesh

Hi,

great you solved your problem!

But still I am sure you are using alt_irq_enable and alt_irq_disable the wrong way.

Don't use it with the BASE-address of your component. Instead, take the IRQ-id listed in system.h.

CU,

Philipp

@philipp

Hi ,

As per your suggetion like use Component IRQ id instead of component base address

i made change according it but no effect of it.

So it is same whether you use IRQ id or base address of the component.

Now i also resolve my below problem

/************************************************************************/

But now my problem is when i issue write or read API back to Back or say in for loop(say 10 times) it just suspended in RUN mode in NIOS II.but it's work very well in Debug mode.

so what i make change in above code to solve above problem.................

/*************************************************************************/

but putting some delay say 1 sec in write/read API.but it's not proper solution because

it reduce the read/write performance.so pls give me other solution........................

Regards,

Jayesh

Hi

--- Quote Start ---

So it is same whether you use IRQ id or base address of the component.

--- Quote End ---

Though, I would definitley use IRQ. But that's just my taste of doing it......

--- Quote Start ---

But now my problem is when i issue write or read API back to Back or say in for loop(say 10 times) it just suspended in RUN mode in NIOS II.but it's work very well in Debug mode.

so what i make change in above code to solve above problem.................

--- Quote End ---

What do you mean with suspended?

--- Quote Start ---

but putting some delay say 1 sec in write/read API.but it's not proper solution because

it reduce the read/write performance.so pls give me other solution........................

--- Quote End ---

Agree, not a soultion at all!

Just to be sure, your variable intrstat is volatile, right?

And do you set back your IRQ in your ISR? I can't see it right now, and it normally should be cleared at the beginning of your ISR. I just recognize that your are clearing the IRQ in read/write, but maybe I oversee something.

The only problem I know where you have to put a delay in your ISR is when you have a really small/short ISR which is executed extremly fast. This can lead to a second call of your ISR, because the clearing of the IRQ isn't done before you leave the ISR.

Regards,

Philipp