Cypress Perform

Home > Design Support > Cypress Developer CommunityTM > Cypress Forums > PSoC® 5 > Counter Confusion

Bookmark and Share
Cypress Developer CommunityTM
Forums | Videos | Blogs | Training | Rewards Program | Community Components



Counter Confusion
Moderator:
ANCY

Post Reply
Follow this topic



Counter Confusion

Helmut posted on 05 Jul 2012 1:19 PM PST
Top Contributor
48 Forum Posts

 I don't want to sleep or save power, but I *do* want to get a very accurate interrupt every second as the basis of my timebase.

I have a Counter (v2.10) in a PSoC5 design.  It generates the first interrupt, but never again, as if it's not running continuously.

By configuration is as follows:

Resolution: 24bit
Implementation: UDB
Period: 1999999 (shortened to 1999 for testing)
Compare Mode: Software Controlled (I don't care)
Compare Value: 1999999 (I don't care, shortened to 1999 for testing)
Clock Mode: Up Counter
Capture Mode: None
Enable Mode: Software Only
Run Mode: Continuous
Reload Counter: On Reset, On TC
Interrupt; On TC

Inputs and Outputs:

count: 2MHz clock
clock: 5MHz clock
reset: no connection
tc: no connection
comp: no connection
interrupt: connected to "ISR_UPDATE"

In ISR_UPDATE.c CY_ISR() function, I set a flag true.  In main program I wait "while" for flag to be true, then set flag false.  In debug mode, I hit a breakpoint inside the CY_ISR() function, then I hit a breakpoint after my wait.  But when I continue after that, the interrupt never happens again.  I am calling the both counter Start() function and ISR_UPDATE_Start().

Why am I never getting the second update?

Thanks!




Re: Counter Confusion

danaaknight posted on 05 Jul 2012 01:38 PM PST
Top Contributor
1773 Forum Posts

This from help site, strangely not mentioned in DS.

 

Clearing Counter/Timer/PWM Interrupt in PSoC 3/5

Last Updated: 03/23/2011

 
How do I clear the interrupt caused by Counter/Timer/PWM component so that the next interrupt is processed by the CPU?

 

To clear interrupt caused by peripherals, inside the ISR code, read the status register of the peripheral causing the interrupt. This status read will clear the ‘interrupt request’ bit of the peripheral.

So for clearing the interrupts caused by counter, Counter_ReadStatusRegister API should be called inside the counter's ISR. This will clear the interrupt request enabling further interrupts.

 

Regards, Dana.



Re: Counter Confusion

hli posted on 06 Jul 2012 01:45 AM PST
Top Contributor
675 Forum Posts

Yes, forgetting to clear the interupt status is, in my experience, the most frequent error when dealing with interrupts. Fortunately it is a simple one, and easy to find from the symptoms.



Re: Counter Confusion

Bob Marlowe posted on 06 Jul 2012 02:26 AM PST
Top Contributor
1768 Forum Posts

Nontheless, as a newbee you may spend hours and hours trying to find out, what is going on.

Or just ask the community. ,-)

 

Bob



Re: Counter Confusion

Helmut posted on 06 Jul 2012 04:32 AM PST
Top Contributor
48 Forum Posts

Thanks, that did it, of course...  And, yes, I now find this comment in the manual, but NOT in the location I would have (did) searched and encountered it.

 

 



Re: Counter Confusion

Bob Marlowe posted on 06 Jul 2012 04:37 AM PST
Top Contributor
1768 Forum Posts

Isn't there a forum concerning documentation / datasheets? If you post a short description there together with a link to this thread maybe somebody changes the docs accordingly.

 

Bob



Re: Counter Confusion

hli posted on 06 Jul 2012 06:28 AM PST
Top Contributor
675 Forum Posts

It might be an idea to add a comment stating the possible need for clearing the interrupt flag to the generated code. That way it might be more obvious to anybody implementing his/her first ISR.



Re: Counter Confusion

danaaknight posted on 06 Jul 2012 10:54 AM PST
Top Contributor
1773 Forum Posts

www.psocdeveloper.com specifically has a forum for sugegsting doc changes.

 

You might also consider posting it as a tech case to get Cypress attention.

 

Regards, Dana.






ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". CYPRESS SEMICONDUCTOR AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY CYPRESS SEMICONDUCTOR. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM CYPRESS SEMICONDUCTOR.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

Spec No: None; Sunset Owner: GRAA; Secondary Owner: RAIK; Sunset Date: 01/01/20