Counter Compare Status Bit

[WiFl_1166056]

I’m having trouble with the Timer 3.0 (16-bit UDB) for PSoC 5LP.

   

What is the intended function of the compare bit in the status register?

   

The datasheet says it’s sticky, so it gets set to 1 when the compare condition goes TRUE, but if the compare condition remains true, does reading the status register clear the bit, or should it remain 1?  My problem is that the compare condition is true (I believe), but when I read the status register the CMP bit is false.

   

StepCounter_COUNTER=,0x0000,

   

StepCounter_PERIOD=,0xFFFE,

   

StepCounter_COMPARE=,0x000A,

   

StepCounter_Control_Reg=,0x82,

   

StepCounter_STATUS_MASK=,0x01,

   

StepCounter_STATUS_AUX_CTRL=,0x10,

       

Thank you.

[Bob_Marlowe]

Will, can you 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

[WiFl_1166056]

Hi Bob,

   

I can't publicly post my project, I'd need to extract this section to make an example project, which I'll do if we don't figure it out soon.

   

First, I'd like to know that is the intended behavior of the Status register sticky bit if the compare condition remains TRUE.

   

Also, how does this affect clearing the interrupt?  Using IO pins for debug, after changing the Compare value, reading Status, then counting toward new value, I see the comp output go high when the compare value is reached, but the interrupt doesn't fire again. 

   

Any suggestions?  Thanks!

[Bob_Marlowe]

How exactly do you want to manage that the compare condition remains TRUE? The component is clocked internally with the system clock to sync all the signals. This is the reason why the tc signal does not follow the input clock directly.

   

The compare condition does not remain set, reading the status register using the APIs will always reset the sticky bits. You may run into a misinterpretation when using breakpoints (The CPU stops, but the hardware continues running).

   

Post at least an excerpt of your project to let me have a look at.

       

Bob

[WiFl_1166056]

Bob,
What I mean is; if the counter equals the compare value and the compare mode is true, then CMP bit gets set (1).  If I read the status register and it clears the bit, but the counter doesn't change, then the compare condition is still true, so should the CMP bit get set again because the component's clock is still ticking?  Another example is if the compare condition is GreaterThanOrEqual, and the counter continues to increment.  Will the CMP bit get set again?

   

I pulled the relevant parts of my project into a little example, attached.  The only hardware required is an active-high button to act as a limit switch.

   

I will be out of the office until Jan 4., but thanks for looking into this issue.

   

Happy holidays!
-Will

[WiFl_1166056]

Happy New Year.  Does anyone have any suggestions on this issue?

   

As mentioned earlier, I see the Compare output go high when the compare value is reached, but the interrupt doesn't fire again. 

   

Thanks!

[Bob_Marlowe]

I do not think that the current behave of the timer is considered to be an issue.

   

UDB components are all synchronized to the system clock, so it will only happen once that the sticky status bits get set. A "remaining" condition is not the same as a condition "happening", thr latter will set the status, the former not.

       

Bob

[WiFl_1166056]

OK, that is how I'm expecting it to work, but the counter's interrupt still isn't firing a second time.  I believe I'm clearing it correctly.

   

When the program starts, the stepper motor homes by running until the limit switch is hit.  This part is working correctly and the switch's input pin interrupt sets the current step count to zero.  This, then, causes the counter's Compare to go TRUE, which causes the counter's interrupt to fire and its CMP output to go high.  The interrupt is cleared and the compare value is changed, which causes both the interrupt and CMP outputs to go low (signals are mapped to IO pins for viewing on o'scope).

   

Next, the stepper motor is moved in the other direction, and step pulses are counted by the counter.  After a couple seconds, the counter hits the compare value and the CMP output goes high, but the interrupt does not fire again.

   

Any ideas? 
Thanks.

[Bob_Marlowe]

Actual project workspace?

       

Bob