PSoC 3 Pending Interrupt

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

 I have noticed the following interrupt behavior on my PSoC 3 ES3 and am trying to understand it.

   

I have an edge triggered ISR component connected to a digital line (I'll call it ISR1).

   

Given the following sequence:

   
        
  • Starting at power up (interrupt enable bit for ISR1 and global interrupt are not set by default)
  •     
  • Interrupt source occurs, setting the pending flag for ISR1
  •     
  • Call ISR1_Start();
  •     
  • Call ISR1_Stop();
  •     
  • Call ISR1_ClearPending();
  •     
  • Call CyGlobalIntEnable
  •    
   

When CyGlobalIntEnable is called, the isr for ISR1 is immediately executed. Checking the INTC_CLR_EN and INTC_CLR_PD registers confirms that ISR1 is neither enabled nor pending when global interrupts are enabled.

   

I assume the interrupt is pending somewhere in either the interrupt controller or CPU, but I have been reading the TRM and cannot determine where it is pending or how to clear it. Any insight on this is appreciated.

   

Note: I can 99% solve the problem by moving the ClearPending before the Start, so ISR1 is not enabled and pending at the same time. But this is not really a solution as there is a small chance the interrupt could be triggered during the period between Start and Stop. Plus I would like to understand what is actually happening.

   

Thanks,

   

-- Jonathan

0 Likes
17 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

That sounds interesting! Will you please upload your example project here, so that we can have a look at it?

   

To do so, Build->Clean Project, File->Create workspace Bundle (minimal)

   

Then attach .zip file here.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

 Gladly.

   

 

   

This project should recreate the behavior using a control reg and isr. If you place breakpoints on both cases in the ISR, both will be hit when I would expect only the second to be hit.

   

 

   

-- Jonathan

0 Likes
Anonymous
Not applicable

 Hmm, the attachment doesn't seem to be there. Let me try this agian.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

It takes some time until the attachment is uploaded. Don't stop trying!

   

 

   

Bob

0 Likes
Anonymous
Not applicable

   

Not sure if this can help.

   

According to ISR data sheet for clearPending()

 

 

   

   

 

   

 

   

   

 

       

   

 

   

Side Effects: Some interrupt sources also need to be cleared with the appropriate block API (GPIO,

   

 

   

   

UART, and so on) or they will just re-pend the interrupt. Entering the ISR clears the pending

   

bit for some interrupt source

 

0 Likes
Anonymous
Not applicable

Sorry about the formating of the last post 

0 Likes
Anonymous
Not applicable

Hi Jonathan,

   

 

   

If you are unable to attach the project, you can mail it to me. I will post it on your behalf.

   

My email id is dasg@cypress.com

0 Likes
Anonymous
Not applicable

 Last try uploading, then I'll email it to dasg.

0 Likes
Anonymous
Not applicable

 Okay, clearly this forum is too complicated for me, but I emailed the project to dasg.

   

 

   

In the meantime, I've noticed where the interrupt is pending, so I think the question is just how to properly clear it.

   

 

   

When the enable and pending bits are both set, the interrupt number is loaded into INTC_ACT_INT_NUM and the address of the isr is loaded into INTC_ACT_VECT. Clearing the enable and pending flags in INTC_CLR_EN and INTC_CLR_PD does not affect the active interrupt registers. Once the global mask is enabled, it jumps to the pending ISR in the active interrupt registers.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi all,

   

 

   

 

   

I am uploading the project on behalf of Jonathan.

0 Likes
lock attach
Attachments are accessible only for community members.
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I took the right to change the program as I thought it should be. Have a look at the comments. It is now running as expected.

   

Bob

0 Likes
Anonymous
Not applicable

 Bob,

   

Thank you for taking the time to look at the program and providing all the comments. However, moving the ClearPending() call before the Start() changes the behavior I was describing. Even in this new scenario, the interrupt could still be triggered between the ClearPending() and Disable() calls (assuming it was a real, external interrupt and not a control reg). I was hoping to be able to be clear interrupts which became pending while the global mask was set. Unless you are telling me I can't do that, in which case I guess I'll live 🙂

   

 

   

Thanks,

   

-- Jonathan

   

 

   

On a side note, I like this style of using StartEx(). That way I don't have to go to the hastle of adding code directly to those auto-generated ISR files which inevitably involves callbacks or externs.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

In my opinion any access of a routine before Start() or StartEx() is executed is not "legal" and must be avoided. Nonetheless such an access should lead to an error and captured by the module-routine(s).

   

 

   

There's one more point for the StartEx() function: when you switch from PSoC5 to PSoC3 (or vice versa) you do not have to change any code. The isr_1.c-files are differently generated and the manually entered changes have to be entered once more.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hmm, I'm not sure I completely understand what you mean by access of a routine before Start(). If the pending bit is set, Start() will setup the ISR location, priority, etc before setting the enable bit, so no ISR should be called before being initialized. The only way to prevent Start() from being called with a pending bit already set would be to gate the interrupt source which would seem to replicate the functionality of the enable bit. But I may have misunderstood your point.

   

 

   

-- Jonathan

0 Likes
Anonymous
Not applicable

 Hello Jonathan,

   

What Bob meant was calling isr_1_Clearpending and isr_1_stop is illegal before starting the isr ( isr_1_start ). The clearpend may not work without starting the isr component.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

That is what I wanted to express (sorry, I'm not native english). As long as you did not call Start() for any component, many things ane not initialized. Clearing an interrupt for which the interrupt-number is unknown (is set by Start() ) will have side-effects or will not work (as you see).

   

The Stop() function will de-initialize a component which will leave it in a state just as if it hasn't been initialized yet.

   

By the way, I would strongly suggest to put the ClearPending() call right into your interrupt-service routine!

   

 

   

Go on, don't get interrupted

   

Bob

0 Likes
Anonymous
Not applicable

 All Start() appears to do is set the vector, priority, then the enable bit. At least in this case, the interrupt number is hard coded by PSoC Creator. The pending bit already seems to function as expected before Start() is called (that is, it is set when the interrupt source occurs). However I understand it is good practice to call Start() before any other function of a component. So, given that calling ClearPending() before Start() is illegal, is there a preferred method to prevent the interrupt from firing as soon as Start() is called? (Since, admittedly, my current solution involves that illegal behavior)

0 Likes