C6455:Two Interrupt accomplish program were called after the first interrupt program completed.

Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI Home Page documents and in the TI Wiki Pages. You may search all of these for helpful information and to browse for the questions others have asked about topics on E2E. Our new E2E red Search box near the upper-right corner has improved functionality, and it is the key to getting the most out of the forum as we include more and more answers to questions like yours.

The problem you describe is not what we expect to happen. There should be only one call to the interrupt accomplish program. This will require some debug work by you and your team to help us determine the cause.

Let me ask some questions and make some suggestions for debug:

The FPGA provide interrupts for the DSP. Is this done by driving a GPIO?

Is the GPIO polled by your running program or does it generate an interrupt that is configured for the DSP?

What are the configuration settings for the GPIO to allow it to generate an interrupt?

Are you using DSP/BIOS? Which version?

Which version of CCS are you using?

How long are the pulses from the FPGA? Is there a difference between the first pulse and the other 89 pulses?

For debug purposes, it will be helpful to configure the FPGA to only generate one interrupt signal. Verify that in that case of only 1 interrupt signal, you still get the 3 calls to the interrupt accomplish program.

At this point, you will have to debug the code find out how the second call to the interrupt accomplish program occurs. You could set an interrupt at the beginning of that program and then example the call stack to determine what called it.

The primary goal of the debug effort will be to determine if the signal from the FPGA is causing multiple interrupts inside the DSP (long pulse or incorrectly cleared interrupt flags) or if the software is incorrectly making multiple calls.

Please reply back with whatever additional information you have.

Regards,
RandyP

Thanks for your enthusiastic and rapid reply. We have done some debug work to find out the reason without any result. We hope the information below can give some clue to figure out the problem.

As you noticed, the FPGA provide interrupts for the DSP, and this is done by driving a GPIO.

GPIO generate an interrupt that is configured for the DSP. 

The configuration settings for the GPIO to allow it to generate an interrupt is:

config.pinNum = CSL_GPIO_PIN5;

config.trigger = CSL_GPIO_TRIG_FALLING_EDGE;

config.direction = CSL_GPIO_DIR_INPUT;

We're not using DSP/BIOS.

My CCS version is 3.3.81.6.

And the pulses from FPGA are 50ns. The fist and the other 89 pulses have no difference. And they are 100us away from each other.

We have tried to debug with only one FPGA interrupt, and we can still get the 3 calls to the interrupt accomplish program. So we need try other method to solve the problem.

Currently, we have 2 interrupts signal from FPGA, interrupt A is in 10ms interval, and there are 90 interrupt B between 2 interrupt A, in the interrupt A service function, there is some flag setting, in the interrupt B service function, trigger an edma transfer between fpga and dsp, we enable the edma transfer complete interrupt, so we should get 90 edma transfer complete interrupt. You can find the interrupt diagram in the attachment.

1641.Interrupt diagram.rar

Best Regards,

Xiaochuan

Xiaochuan,

xiaochuan zhang said:

We have tried to debug with only one FPGA interrupt, and we can still get the 3 calls to the interrupt accomplish program. So we need try other method to solve the problem.

Many users have a difficult time getting to the 1 interrupt scenario. It is good that you have these skills and abilities to control your board environment. I know you will be successful.

Do you get 3 calls to the interrupt accomplish program only one time and this problem never repeats again? Or will you get 3 calls to the interrupt accomplish program after the first interrupt B after every interrupt A? In other words, do you get 92 calls to the interrupt accomplish program only between the first two interrupt A pulses or between every pair of interrupt A pulses?

Since you are not using DSP/BIOS, please explain about your interrupt response flow. This will help me understand your system. For example, when the GPIO pin has a falling edge, a bit will be set in the INTC event combiner and then in the IFR (Interrupt Flag Register) or a bit will be set directly in the IFR if the event combiner is not used. There is an interrupt vector table which will branch to a program which I assume is the "interrupt program" that you have mentioned. And this continues until the "interrupt accomplish program" is called. Would you please explain the actual interrupt response flow to correct my assumptions and to fill the missing pieces. Please be specific with INTC bit numbers, IFR bit numbers, and program/function labels.

For debug, I recommend you configure the FPGA to generate only one interrupt A and only one interrupt B, as you have done already.Continuing with that configuration will allow you to set breakpoints in the program code without having additional interrupt pulses after the breakpoint has been reached.

Please set two breakpoints in the interrupt program. Set one at the beginning of the interrupt program and set one at the line which calls the interrupt accomplish program. Allow the system to run. After the interrupt A and interrupt B pulses occur, the program will stop at the first breakpoint. Run again, and you will reach the second breakpoint to call the interrupt accomplish program. Run again, and find out if either breakpoint is reached again. That will be important information, critical to determining the cause of the problem.

Continuing the debug, please set a breakpoint in the interrupt accomplish program and allow the system to run. After the interrupt A and interrupt B pulses occur, the program will stop at the breakpoint. Observe the Call Stack to see what previous program flow occurred. Run again, and you should stop at the breakpoint again because of the incorrect 2nd call to the interrupt accomplish program; again, observe the Call Stack and compare it to the first time. Run again, stopping at the breakpoint because of the incorrect 3rd call to the interrupt accomplish program; again, observe the Call Stack and compare it to the first and second times.

There may be enough information in the Call Stack to tell you why you have made the extra calls.

Depending on what you learn from the program behavior in these steps, you may find the cause of the problem or you may eliminate some causes or you may narrow down the range of possible problems.

Regards,
RandyP