Fix Function Timer Component help

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

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hello,

   

I have been struggling to have the fixed function timer component to do what I need.   I need a timer that starts when needed and then programmatically check the status of the timer to determine if the timer has expired.   For the life of me I cannot achieve this with the FF Timer component.  This is to be accomplished through software,  no hardware connections or interrupts needed.

   

What am I doing wrong? 

   

Please take a look at the attached project.  It is a  very basic test project.  The idea is to start a timer,  check for timer expiration and if so turn an LED on, if not turn the LED off.  The timer is configured for "one shot" and I would have thought that once the timer expired the timer would not be reset.  But it appears the simple act of reading the status register is resetting the timer and causing it to start.   The bottom line is that in the supplied project the LED blinks continuously which not what I am attempting to achieve.   

   

Thanks,
Ron

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

I changed your device to an PSoC5LP (I don't have another PSoC active in ma lab) compiled, setting breakpoints at lines 80 and 82 in main()where you write to the LEDs and I get only one stop, not more.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

Yep, I see the same results.  After the firmware is uploaded to the PSoC 3,  the led blinks which means the comparison test at line 77 is alternately testing true then false (at the timer component value of 2 seconds).  But, if I put the firmware into debug mode the test is only successful once and then fails on every iteration there after.  If I reinstate line 85 the firmware works as expected,  whether in debug or not. 

   

I think I found yet another bug in either PSoC Creator 3.1 or the component. 

   

BTW:  compiler optimization has no effect on this issue.  I have tested this test program at all available optimization levels.

   

Thanks,

   

Ron 

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

When reaching a breakpoint the CPU stops, but all internal hardware keeps running. This sometimes leads to strange behave.

   

Under Creator -> Tools -> Options -> Program/Debug you find an option mamed "Disable Clear-On-Read". I was told that this may have influence in situations like yours.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

Thanks for the info.  I will give that a shot in a day or two.  In the mean time I have created a case on the issue. 

   

While I have been dealing with this issue for over a week, during that period of time I  created my own timer based on a clock component and a counter variable.  It is serving the purpose for now but it is not as accurate (I'm sure) as using a timer component.  I will be the first one to admit that I may be doing something wrong, but at this point I can't determine what it may be. 

   

Thanks for being here and offering your invaluable advice and help,

   

Ron

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Why not add a 1 bit status register tied to the Tc pin of the timer,

   

and set it as sticky ? Then just poll that status register.

   

 

   

Regards, Dana.

   

 

   

0 Likes
Anonymous
Not applicable

Hi Dana,

   

Yes, I could do that and it would solve part of the problem of when the timer has expired.  However the issue I am experiencing is that the timer resets itself and starts again.   I need to start the timer when a certain event occurs elsewhere in the program.   But if the problem as I mentioned previously is that reading the status register is resetting the timer, then your solution just may do the trick.  I will give it more thought and give it a go.

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

I cannot reproduce that reading the status of a one-shot-timer resets it or restarts it for a PSoC5LP.

   

I will create a test-program for the CY9CKIT-050 and post it here.

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

If you set the timer to one shot mode it stops at count = 0,and does not

   

start back up. So you can get the timeout event with the status register and

   

with an API at a time of your choosing reset and restart the timer. Or

   

use a control reg on reset pin, either way.

   

 

   

Regards, Dana.

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

Probably the reset is the problem. The datasheet tells only about the hardware reset and a software-reset via API is not provided.

   

So you need to stop() and Start() the one-shoot when it has couted down.

   

See attached project.

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

The reset is as Bob stated not available from an API, per se. The Start()

   

seems to handle that.

   

 

   

If you use a control reg and reset input the following apply -

   

 

   

   

 

   

Regards, Dana.

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

Afaik the Start() API allone does not work as a reset, you have to Stop() the timer before.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hello,

   

Thanks to both of you for the information.  I will continue to give this a go and come back here with the results.  This a bit more complex than I had originally thought.  It appears the software API is not what I was hoping for.  The API for the timer component is more complex than it needs to be.  A basic timer really only needs:

   

Start timer, reset timer, stop timer and timer status.  (From my understanding, the API Timer_Start() does more than simply start the timer.  It powers up the component and then starts the timer and is basically the same for Timer_Stop() which stops the timer and powers down the component.  The powering up and down is not necessary. 

   

Thanks,

   

Ron

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

Yes, you are quite right, many of the components could be less complex, to serve as many users as possible Cypress has built some jack of all trades devices (hopefully my translator didn't guide me wrong) and so there might be a lack of simplicity.

   

But

   

Nobody hinders you to build your very own timer component that exactly reflects the properties you just mentioned. You may even copy the existing files for the timer, rename the component-name and strip down the component to the barest. There is a Component Author Guide installed in your cypress directory that might help you with the design.

   

This takes some time, I did it and later with this knowledge I was able to solve some other projects for my customers.

   

 

   

Bob

0 Likes
markgsaunders
Employee
Employee
50 sign-ins 10 solutions authored 5 solutions authored

This one had me scratching my head for a while but I think this is what you need.

   

The _Start API does start the timer running. In the following I use the TC output to control a flip-flop. After the 1s timer period my LED comes on forever. The only C code is Timer_Start();

   

   

In your project you are using SW to detect the TC. I did that with the following:

   

   

 

   

In C I wrote this...

   

    LED_Write( 0 );     // LED Off
   
    Timer_Start();  
   
    for(;;)
    {
        status_reg = Timer_ReadStatusRegister();

        if( status_reg & 0x80 )
        {
            LED_Write( 1 ); 
            CyDelay( 250 );     // Allow time for my old eyes to see the LED
        }
        else
        {
            LED_Write( 0 );  
        }
    }

   

 

   

Note that the timer does not restart in this case but the TC bit I am reading does get cleared. I think that is because it is only asserted for one cycle. The datasheet is a little misleading on this matter. it says "The tc output is available to monitor the
current value of the counter register; it is high while the counter is zero." and "The TC signal is always a single clock cycle pulse". The former implies that it remains high for a long while but, actually, the counter is reloaded on terminal count but the timer is stopped. As a result the TC is asserted for just one clock pulse. The word "while" in the first sentence is what threw me off.

   

Hope this helps...

   

-- Mark

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

@yfs, scratching is not enough for me, I am going to put my head

   

into a log splitter, I am sure that will feel so much better. 🙂

   

 

   

I used both a timer and a counter, in one shot mode, and nothing I tried

   

would get them restarted with the below code. The status reg sees the first

   

Tc and then never again. Operated in sticky mode. The control reg in pulse

   

mode. Code gets once inside if statement, then never again.

   

 

   

As the original poster stated, a timer/counter in one shot mode should

   

not have to be stopped, powered down. And what gives with the status

   

reg......The D and the pins for debugging.

   

 

   

int main()
{
    /* Place your initialization/startup code here (e.g. MyInst_Start()) */
   
    Counter1_Start( );



    /* CyGlobalIntEnable; */ /* Uncomment this line to enable global interrupts. */
    for(;;)
    {
        /* Place your application code here. */
       
        if ( CounterStat_Read( ) == 1 ) {                       // One shot Counter finished ?
           
            CyDelay( 10 );                                      // Wait 10 mS and then retrigger Counter
            TrigCounter_Write( 0x01 );                          // Reset Counter

        }
    }
}
 

   

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

The reset signal "...requires at least one rising edge of the clock to implement the resets of the counter value and the capture counter." (from timer datasheet) This may not be guaranteed to be fulfilled.

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

The reset shown is way oversampled, so should happen.

   

 

   

Still at a loss.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

Hello All,

   

I'm getting blurry eyed looking at the possible permutations.  So what if any conclusions can be made?  It appears to me that the one shot option of the FF timer component is hosed.  I have tried this six ways to Sunday and can't make it work.   I have submitted a case on this and hopefully Cypress is reading this thread (a link was provided in the case). 

   

When I have more time I will come back to this issue but for now I have a  crude timer that uses a clock attached to a status register.   Part of the program cycles through reading the status resister and if there is a clock pulse active, a counter is incremented.   Based on before and after counters,  I know how many milliseconds have passed between times when the status register is read.  

   

Thanks again everyone for taking an interest in this issue.

   

Ron

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

@Dana

   

"The reset shown is way oversampled, so should happen." This I cannot deduct from the provided picture, the output setting of the control register and the write sequence could be so tight that the pulse is missed.

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

You are right Bob, reset input is not edge detect, its sampled by the clock.

   

 

   

Lets see if that works.

   

 

   

Regards, Dana.

0 Likes
markgsaunders
Employee
Employee
50 sign-ins 10 solutions authored 5 solutions authored

I could be wrong but I think you have a 24MHz pulse resetting a 2.4MHz counter. The counter does not see the reset. I removed the BUS_CLK that was driving the TrigCounter register and wired the Counter_Clock to the register instead. It resets with wild abandon for me!

   

This is probably too much fun during office hours...!

   

-- Mark.

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

Hello,

   

I thought I would come back and pass along a solution Cypress provided.  The attached project does work and has been adapted to my particular hardware configuration.   One thing that Cypress did not mention and was determined while I was testing the solution is that the timer component apparently has a clock frequency lower limit.  With a clock running at a frequency below the limit the timer component appears to experience timing issues and will not set its status register properly.  I really don't know what the lower limit is, but can tell you that a 1KHz clock frequency will not work.  The solution Cypress provided had a 50KHz clock and I was able to move down to a 15KHz clock.  

   

Also you will notice another timing issue with the timer component.  A call to CyDelayUs is required after setting the control register bit to reset the timer.  I have found the value for CyDelayUs can be set as low as 10us.  Anything below that the timer component misses the reset.  The call to CyDelayUs might be able to be removed if the control register bit is set to "PulseMode" but I have not tested that.

   

Regards,

   

Ron

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

Hi Again,

   

OK, attached is the same solution but using a control register bit set to "PulseMode" .   This eliminates the need for a call to CyDelayUs. 

   

Cheers,

   

Ron

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

There is a condition required for the correct functioning of the one-shot reset: The reset pulse has to be so long that the timer "sees" at least one rising edge of the clock (stated in datasheet).

   

Since your controll register is asynchron to the timer clock it is difficult to fulfill this condition. You use a delay of 100µs and feed the timer with 15kHz which is 66µs => that will work. But when you lower the input frequency to 10kHz the reset will start to fail from time to time.

   

A way out as you already suggested is to use a pulsed control register output with a clock at least with the input clock. better would be to divide it with a t-FF.

   

 

   

Bob

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

We got a tough timing with our posts,too !

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

I can see clearly now the rain is gone .   These timing issues were presented in this thread but I just was not catching on.  Yes, there is a direct relationship between the timer component input clock and reset pulse width.  This comes under the category of being "thick as a brick".   But I'm on my way now. 

   

Thanks to you and all,

   

Ron

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

Be sure: You're not the first having that issue... and probably not the last.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

One last post regarding the timer component.  The timer component solution has been successfully integrated into the "real" application.  Bob,  I did incorporate the t-ff . and the timer is working flawlessly providing accurate "timer expired" results. 

   

 

   

Thanks to all,

   

Ron

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

Thank you for keeping us informed!

   

 

   

Bob

0 Likes
ChLi_1922061
Level 1
Level 1
First like given

Hi all!

I know this thread is old and dead, but I'd like to share my "solution" to this problem for everyone having same issue today:

I was also looking for a simple SW-only solution, and here it is: Just call the _Init(); function of the timer PRIOR to the (re)start.

The init will reset the timer (start calls init only the very first time!).

Oh, and use the TC-Pin as output.

That's it! You got a simple, SW-controlled OneShot-Timer with minimal HW-ressources.

I hope someone will find this helpful and Cypress will one day mention this in the Datasheet...

0 Likes

Hi Christian.

When I need to restart a timer I usually write a zero into the period register using the appropriate API. Works with counters too.

Bob

Are you living in Germany? I am located near Bremen.

0 Likes

Hi Bob!

Does wirting a zero also reset a OneShot FF-Timer?

Going further, I'm using now the interrupt output, and restart the timer with the init-function only. Nice thing is, this way the you get a delayed "high" output wich persists until you call init - great for "windowed interrupts"!

Actually yes, I'm living in Germany...near Lindau (am Bodensee), so quite far away

Regards,

Chris

0 Likes