Cypress Perform

Home > Cypress Developer Community > Blog Posts > PSoC Sensei Blog > Using Clocks with PSoC 4


Using Clocks with PSoC 4
May 29, 2013
By Bradley Budlong

For those that have used PSoC 3 or PSoC 5LP and are now using PSoC 4, you'll notice that there are some changes between what can be done with clocks on the different devices.  There are a few new restrictions and several new capabilities.  In this post I'll take a look at using clocks in the UDB array and with pins.

The first change is that clocks can only be used as clocks.  They cannot be used as data signals.  In PSoC 3 and 5LP this was possible, but discouraged.  In PSoC 3 and 5LP the clock signals were available as clocks and also as routed signals.  The reason it was discouraged to use them as routed data signals is that the timing of these signals is not guaranteed.  That means that setup and hold is not known when a routed clock is used as a data signal and clocked by another clock.  With PSoC 4 this discouraged usage is just not allowed.  PSoC 4 only has the clocks distributed on the low skew clock lines and those are only connected to clock inputs.  As an example the following circuit will generate an error with PSoC 4.

Although this isn't the most useful circuit, what if I really needed to implement this circuit?  The solution is to convert the clock signal to a data signal.  This is easily done with a toggle flip-flop and a clock signal running 2x faster.

This circuit is perfectly legal.  In this case a 4 MHz clock is used instead of a 2 MHz clock.  The toggle flip-flop toggles with every 4 MHz clock edge resulting in a data signal that is a perfect square wave at 2 MHz.  The resulting signal also has a known timing relationship.  Because of that, this is also the circuit that should be used for PSoC 3 and 5LP designs as well.

One common debug application for routed clocks is to send the clock to a pin along with a data signal.  This can be done just to observe the clock during debugging.  In PSoC 3 and 5LP this is done simply by hooking a clock to an output pin.

This is not allowed on PSoC 4 since clocks can't be used as data signals.  However, PSoC 4 has some new pin capabilities and they allow the clock to be sent directly to a pin.  In fact there are a bunch of new clocking capabilities for pins.  Right now I'll just take a look at the one that allows this function to be implemented with PSoC 4.

This configuration looks a little odd, but it does exactly what is desired.  The 12 MHz clock in this case is sent directly to the pin.  The clock signal needs to be sent to the out_clk terminal and the output pin terminal is just tied high.  To get to this point start with a standard output pin and then change the configuration as shown here:

This causes the output pin to output the clock instead of the data signal.  Then make this second configuration change:

This configures the pin to use the clock that is being provided as the out_clk as the output clock signal for the pin.

With those changes and the signal connections shown the clock signal is once again visible on the pin.

See full blog


Comments:
dccvr wrote:
 Great! Without your help I was till in testing and trying...
Thu May 30 15:53:58 PM
MoxonDesign wrote:
Nice - thanks Brad.
BTW, I noticed that the baud rate was out-of-spec with the standard clock settings.
So I wound up changing the HFCLK to be a multiple of the baud-rate
For example if you want to get 115200 baud :

115200 * 16 = 1,843,200 Hz * 26 = 47,923,200 Hz

so set the main HFCLK to 47,923,200 Hz

(don't set it to 48mHz exactly...)

and your baud rate will be within the margin of error
for reliable communication. Otherwise you'll get too
many transmission errors... 

If you know a better way to do this - I'm all ears...

;-) Tom
Thu May 30 23:28:16 PM
bjbu wrote:
Tom - I'm uncertain how you are getting the HFCLK to be something other than in increments of 1 MHz. That is all that the IMO is able to produce unless you are using an external signal. I've just created another post that introduces the fractional clock dividers that were also added with PSoC 4. These are a perfect solution for accurate UART sampling clocks.
Mon Jun 10 16:35:49 PM
jgraham wrote:
The clock pin I/O nuance seems like it could have been handled by the compiler...  I understand the technical reasons, but why force the user to climb the new learning curve?
Thu Jun 27 09:09:57 AM
bjbu wrote:
jgraham - We always have to trade off having the tools automatically implement a function or having the user implement the function. The reason to not have the tool do something automatically is usually because the implementation isn't a true representation of what has been asked for or the transformation that we would implement has other limitations. In the case of using a clock signal as a data signal there are some cases where we could just generate a 2x clock and then divide it to create a signal that could be used as a data signal. Problems would arise however if that signal was also used as a proper clock.  In that case you want the clock to be the direct output of a clock. Another issue would be that the clock would be reported as a 2x clock and any API calls to change the clock would need to take this into account.  Just doing this automatically in this case would be very confusing for the user. In the other example that I brought up of sending a clock to an output pin that could have been done automatically, but once again there is an issue that I didn't raise in my original post. Only one clock can be used per port. The error message generated in this case could be a little confusing, but this is a closer call.
Mon Jul 01 00:56:03 AM
You must be logged in to leave a comment. Login / Register
Like this item? Spread the news:  
Post this story on Digg.com Digg this   Share this on Facebook.com Facebook   Post this story on Digg.com LinkedIN   Add to Twitter Twitter  
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: DWV; Secondary Owner: JMAL; Sunset Date: 06/15/20