Issue with implementing multiple ISRs

[Anonymous]

Hey there,

   

I'm using PSoC Creator for nearly half a year now and had Problems with multiple ISRs in the past, but could handle them (that "often occuring problem" when you don't use CY_ISR_PROTO).

   

Now I'm stuck at a Project with five different ISRs and can't find a way out so I hope someone can help me here.

       

I'm using a CY8CKIT-059 on a self-designed prototyping platform with two Manchester-Coded-Inputs to perform UART-over-USB-Communication with a PC. The Decoding is done by oversampling with help of an SPI-Slave. An Edge-Detector recognises the first Edge of the incoming Signal and Starts the Buffering of the oversampled Data by causing an Interrupt. Each Manchester-Bit is oversampled, next Bits are recognised after the SPI is "full" (2nd Interrupt), which will lead to copying the oversampled data to a buffer. This is done 34 Times as this is the Telegram-Length of the incoming signal. This Hardware-Part is included two times as there are two Manchester Inputs, so there are 4 Decoder-Interrupts. Two for edge-detecting-purposes, and two to recognise a finished oversampling. I implemente3d those Interrupts as external ones to implement my own code and all four use the mode "RISING-EDGE", which worked well in some other Projects with the same need for Manchester-Decoding, but all in all 2 Interrupts per Project (one declared as CY_ISR_PROTO, one as CY_ISR, both defined with CY_ISR ).

   

The fifth Interrupt is used to recognise an incoming UART-Byte (Used to control the System).It also uses the mode "RISING-EDGE" and has the highest priority in the system. I also have tested the UART-Part in other Projects and never had a problem.

   

Now I have this project where I want to use all this parts together. Two Manchester-Decoder and the UART-Part, as you can see in the Attached Picture. I also added the code with all the hardware-starts and Interrupt parts in it. When I comment all Interrupts except the one for UART, the ISR will work, but more than one ISRs don't work.

   

I tried different combinations with declaring different ISRs as PROTO, using different priorities and even made the code easier, but  nothing helped really. Collisions between the 4 Decoder-ISRs can't be, only with the UART-ISR, but even if there is no Manchester-Code incoming, the UART-ISR doesn't fire.

   

I hope someone can help me with my problem. If you need additional information, just ask. I will try to answer.

   

---

       

If you find a writing mistake, you can keep it.

   

Greetings from Germany 🙂

       

---

[Bob_Marlowe]

Welcome in the forum!

   

Can you please post your complete project, so that we all can have a look at all of your settings. To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.

       

Bob

   

PS: Where in Germany are you located, I live near Bremen.

[Anonymous]

Here are the files.

@Bob: I live in the north of Frankfurt where I do my bachelor degree in electrical engineering (not with this project 😛 ).

[Bob_Marlowe]

Well, you like the APIs 😉

   

Clocks do not need to be started

   

Start() usually enables the component.

   

CY_ISR_PROTO is the prototype declaration (like a forward) of a function. CY_ISR is the function definition

   

SPIM is a SPI slave component. Is that wanted???

   

It is essential to clear the interrupt cause in a handler for your SPI issue a ReadTxStatus() to reset the status bits.

   

Same for the UART.

   

Global variables that are changed within an interrupt handler must be declared as volatile or you get into hell when starting optimization.

       

Bob

[Anonymous]

Yeah the APIs give enough functions to me so I use them :p. But I think more complex Projects will need an other implementation.

   

Thank you for your tips, but didn't you mix up "definition" and "declaration"? AN54460 says it the other way and also you in this post: ://www.cypress.com/forum/psoc-5-known-problems-and-solutions/multiple-custom-isrs-psoc-5.

   

So what is right? Should I write CY_ISR_PROTO( handler ); at the beginning of my Project and should I name all Interrupts like that? Doing it like that I would have to write the macros like CY_ISR( handler ) { macro code here; }. Is this right?

All SPIs are Slaves, the M and S come from the component that delivers the input :).

   

I will implement a better handler for the SPI and optimize my code. Let's see if it will help.


Thanks for your help

   

Alex

[Bob_Marlowe]

didn't you mix up "definition" and "declaration"?  Corrected for coming generations ;-))

   

As long as you stay with ARM Mx cores you may leave out that CY_ISR... , That was introduced to maintain compatibility to the PSoC3 which has got an 8051 core (shudder). An interrupt handler is always a void function(void)

       

Bob

[Anonymous]

I've implemented everything like you said and it didn't work. So I experimented a bit and found out that the Edge-Triggered Interrupts seem to get triggered at the Power-On-Reset of the System where a rising edge occurs. This happens even if the Interrupts aren't enabled. So I implemented a clearing of all Interrupts and the system works well. Without the clearing it won't work.

   

But thanks for your tips. I think the program will work better and will be easier to optimize with the hints you gave me.

[Bob_Marlowe]

You're always welcome.

       

Bob