cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC™ Creator & Designer

JoBr_1593366
Contributor II

The Counter datasheet (PSoC3) says

"Run Mode … One Shot – The Counter runs through a single period and stops at terminal count. …  On stop, …  for a fixed-function counter, the count register remains at terminal count."

"tc … goes high one clock cycle after the count value matches the terminal count and stays
high while the count value is equal to the terminal count."

So I would think that the tc output is low until it counts down to 0 (the terminal count) at which point the output switches to high, but in reality it only pulses high at that point and then goes low again, with these settings:

JoBr_1593366_0-1630593811255.pngJoBr_1593366_1-1630593818121.png

 

 

So I tried to latch it with an RS flip-flop, but it complains about "asynchronous clock domain crossing" and doesn't seem to work reliably.

JoBr_1593366_1-1630591891445.png

So I tried to use an asynchronous DFF to latch instead, but it complains about 'Control signal "dsrff(clock)" driving signal "Net_3998" is always "low".'

JoBr_1593366_0-1630591771567.png

Is there some better way?

0 Likes
1 Solution
BiBi_1928986
Valued Contributor

Hello.

I did this with a PSoC 4.  I connected the counter OV output to the clk input of DFF.  Connect a '1' to the D input.  I used a Control Register component to reset the DFF (with AR on symbol).  Otherwise, you can't reset the DFF back to 0.

For your application, connect TC to the DFF clk input, etc.  I expect this will also work with PSoC 3.

View solution in original post

15 Replies
JoBr_1593366
Contributor II

I am so confused.  With the above Counter settings, a 10 Hz clock, and this circuit:

JoBr_1593366_0-1630595115450.png

I would expect both LEDs to latch on, 5 seconds after reset drops low.  In reality, neither does.  They both pulse and then go back off. 

They do not repeatedly pulse, so it doesn't seem to be in continuous mode, but one-shot mode doesn't seem to match the datasheet, and the DFF async preset doesn't seem to work, either.

0 Likes
JoBr_1593366
Contributor II

This doesn't work, either:

JoBr_1593366_1-1630597031434.png

"No clock inferred, Expected a clock for this always statement" which leads into "Application.v generated from TopDesign.cysch".

So we can't make a synchronous latch, and can't make an asynchronous latch either?

0 Likes
BiBi_1928986
Valued Contributor

Hello.

I did this with a PSoC 4.  I connected the counter OV output to the clk input of DFF.  Connect a '1' to the D input.  I used a Control Register component to reset the DFF (with AR on symbol).  Otherwise, you can't reset the DFF back to 0.

For your application, connect TC to the DFF clk input, etc.  I expect this will also work with PSoC 3.

View solution in original post

JoBr_1593366
Contributor II

That works!

0 Likes
Len_CONSULTRON
Honored Contributor II

JoBr,

Did you try this?

Len_CONSULTRON_0-1630932533736.png

 

Len
"Engineering is an Art. The Art of Compromise."
JoBr_1593366
Contributor II

If I do this, or just change the clk to BUS_CLK, it still complains about asynchronous path.

0 Likes
Len_CONSULTRON
Honored Contributor II

JoBr,

You don't show what your clock source for Counter_1.  This may be a factor.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
JoBr_1593366
Contributor II

It's a 10 Hz clock divided down from IMO.  (But using it for both components still produces the clock domain error, as in my original example.)

0 Likes
Len_CONSULTRON
Honored Contributor II

JoBr.

Are you sure your 10Hz clock is divided down IMO?

If your IMO was 3 MHz, the maximum divisor that can be applied by the Clock component is 65536.  This means your output frequency is 3,000,000 / 65536 = 45.77 Hz.

If you specified "Automatic" for the clock, them most likely it assigned the ILO instead.

Besides, I believe you can ignore "async" warning.  It's just a warning that you could receive a multi-stable condition.  To address this you could put a "Sync" component between the TC output and the "S" input of the SRFF.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
JoBr_1593366
Contributor II

Yes it's divided twice from IMO because I want decently accurate timing against external devices. 

The circuit with the async warning didn't seem to work reliably, though that may be for some other reason.

0 Likes
Len_CONSULTRON
Honored Contributor II

JoBr,

Are you willing to share your project here?  If not the whole project then at least the TopDesign file?

If you're interested, there is a way to improve the frequency accuracy of the IMO to +/-0.25%.

Here is a pic of the "Configure System Clocks" using the USB-related clock settings.

Len_CONSULTRON_0-1631276804863.png

 

Len
"Engineering is an Art. The Art of Compromise."
JoBr_1593366
Contributor II

I can't share the project here.  Yes, it's 24 MHz +/-0.25%, which is why I used it for this clock

0 Likes
Len_CONSULTRON
Honored Contributor II

JoBr,

This circuit doesn't complain about async timing.

Len_CONSULTRON_1-1631277880674.png

 

Len
"Engineering is an Art. The Art of Compromise."
JoBr_1593366
Contributor II

OK, thanks.  Sorry if you didn't see it, but the D flip flop version above works for me, and this version seems to use more resources, so I will use the DFF version unless you know of something simpler.

I still don't understand why the component itself doesn't stay high in one-shot mode after reaching the final value.

0 Likes
Len_CONSULTRON
Honored Contributor II

JoBr,


I still don't understand why the component itself doesn't stay high in one-shot mode after reaching the final value.


Good question.  Apparently the TC pulse should last as long as the count matches the TC.

Here's a snip from the datasheet.

Len_CONSULTRON_0-1631313311617.png

Len
"Engineering is an Art. The Art of Compromise."
0 Likes