Showing results for 
Search instead for 
Did you mean: 

PSoC 5, 3 & 1

New Contributor II

On page 1745 of the psoc 5lp registers TRM_001-82120.pdf, it is described that

it is possible to get a DSI clock as the clock source for the systick.  bit 2,

CM3_SYSTICK_SRCSEL  when set to "1" should use the signal connected to


and a similar idea for the NMI source selection.

my question is: how do i get a signal of my choice onto that signal name??

i have read many community threads, documents and AN's, and tried various things

in Creator and the output files to find this "dsi_01_out_p_13"

signal, and have found nothing.

20 Replies
Honored Contributor II


There is good tutorial how to use external clock as a system clock.

External Clock

The SysTick counter runs on the system clock (BUS_CLK), derived from the external clock


New Contributor II

Thank you for the response.  but i do not follow if that is what i am looking for.

i don't want to change the CPU clock: i still want that to run fast (66Mhz for example).

so i am using an external Xtal, and the PLL is using Xtal as the source: and PLL

sets the Master clock, and hence the Bus clock.

SO, i guess the IMO is "free" to use for something else.

i didn't want to use the IMO with Digital Signal input; unless that is the only way.

More details:

in the Psoc5 Ref Man.pdf, page 41, section 4.2.5 "SysTick Timer"

says that the cortex-m3 register NVIC_SYSTICK_CTL selects whether

the clock source is "internal" or "external".  and the second register (the PANTHER_WAITPIPE)

which selects the "external" is the ILO or the DSI.

  so this makes it sound like there are 3 possible sources for this: and i want the DSI option

  (the ILO is not stable or accurate enough)

And in that Configure System Clocks dialog, there is the yellow/green line going

down from the Digital Signal item (you just cut it off in your picture).

i was hoping THAT somehow could become this mystery "dsi_01_out_p_13" signal.

by the way, how do i find this signal name?  where is it?  do i need a "Directive" to

force it?  what is it?  (i am not an expert in the internal psoc naming and i don't find

it in any clocking tree diagram)

Same questions for the NMI signal as in the future i might want to use that also



I can change the clock source with a function CySysTickSetClockSource() and the interrupt period with a function CySysTickSetReload() as follows.

#define SYSTICK_FREQ    (4)

#define SYSTICK_CLOCK   (100000)





In this case, the 100kHz ILO clock is used for the SysTick timer.  Please note that the 100kHz ILO must be enabled in the Clock Editor as follows.


The callback function is registered by the CySysTickSetCallback() function.

    /* Find unused callback slot and assign the callback. */

    for (uint32 i = 0u; i < CY_SYS_SYST_NUM_OF_CALLBACKS; i++) {

        if (CySysTickGetCallback(i) == NULL) {

            /* Set callback */

            CySysTickSetCallback(i, SysTickISRCallback);




Please refer the "PSoC® Creator™ PSoC 3/PSoC 5LP System Reference Guide" which can be downloaded from a WEB page invoked by the following menu item.


You can see SysTick related functions in the "System Timer (SysTick)" section.

Please refer the example project "SysTick_Example" too.



New Contributor II

Thank you for your response.

I know how to and am using the ILO signal to drive SysTick.

Your answer does not address my question of how to get the external DSI signal

to clock systick.

Honored Contributor II


I am curious why do you want the SysTick timer to work from external source, when a standard Timer is available. Did you run out of all UDBs? Alternatively, the SysTick can work from ILO, controlled by 32kHz Quartz.


New Contributor II

thank you for asking.

the psoc 5lp has a large "data size disconnect" between the 32bit wide CPU,

and the only 8 bit wide control/status register access to/from the logic.

suppose one wants to have a good, high speed 32-bit (or even wider counter), clocked

at say 4Mhz that is to be used as a time-stamper by the CPU.

Wouldn't it be great if the CPU could access this 32 bit value in a single instruction

cycle atomically?

You do see the massive problem if this counter is out in the logic: trying to access

a 32 bit value via multiple 8 bit status register reads? and then making sure the value was

read correctly?  and the extra effort to try and make the status registers align in memory

so one can try to use 16 or 32 bit pointer accesses? (i have a working solution for these

so i know them), but still have to then check for proper reading of the bit value?

or trying to do some DMA magic? (i have not tried this yet.  might have to...)

so using the logic takes a lot of cpu instructions: just to read a 32 bit counter !?!?!

the SysTick Counter is the ONLY counter i could find in the entire psoc 5 that is directly

tied into the CPU, readable with a single instruction, and with no apparent reading hazards.

Fantastic! a way to have a good, fast access, easy to use, reliable, Time Stamp generator.

well... almost.  accessing it is easy and works great: but it is clocked by awful clocks!!

the ILO is not accurate, unstable and slow!  the only other choice is the CPU clock:

with only 24 bits in the register: way tooo fast!

What !?!   this counter would be great!

if it only could be clocked by a real crystal controlled clock:  the type that are all over the digital logic!

and wow, there in the documentation says there is a way... if only one could figure out

that signal name... and i've spent some of yesterday and all of today trying to find anything about

that signal, or naming conventions on names or.... and have failed at everything.

That is why i want the systick counter to be clocked at say 200khz, 1Mhz, 2Mhz, whatever i choose.

and not the drifty ILO...

I hope you and/or the community can find the information and solve this for me and

all the others whose posts i've been reading for the past few days.

(i have tried your suggestion of driving the IMO with the DigitalSignal, and no, there is

no clocking of the systick.  so i still don't know how to attach to that magic signal )

Esteemed Contributor


While ago, there was a similar question, about how we can use DSI input for clock,

I tried to find the magic word for a half day and resigned.

But with this thread, now I know that the secret word was "ext_clk."

May be I'm missing something but with following wire name and clock configuration

I could provide external clock to PLL and generate 66MHz for CPU.



But as you wrote it seems that we have only 2 choices for the SysTick Clock source.


Then SysTick will be also clocked with the Matser_CLK = 66MHz.

But how about having upper bits counter counting with SysTick's TC?

Although as you wrote, accessing logic takes time, you get the lower 24 bits from the SysTick Counter

then hopefully accessing the upper bits will not take 16M (2^24) Cycles.

I know that this is clumsy, but may be better than nothing.


New Contributor II

Thank you for your response.  I am bypassing the as-provided C/h source code and looking

directly in the 5lp reference manuals, and thus directly can set/read the particular

register bits.  that way i am not hindered by the limits imposed by the C/h file writers.

some sort of "hybrid" between two different counters sounds harder to keep them

coherent than using the logic.

my prototype has been using the ILO to clock systick at 100khz;

and i use software to catch the wraparound and create a 64 bit coherent count.

and this has been working well enough for development.

and now i am back to trying to get a more stable clock rather than the ILO.

i had thought to use the watch crystal to make the slow speed clock: but i

think it is exactly the same problem: how to get a clock source of my choosing

to drive the systick.

Honored Contributor II


can you use a standard 32-bit Counter instead of SysTick? It will take 4 UDBs, but reading of the UDB is atomic.

Alternatively, you can use DWT timer of PSoC5, it is 32-bit (long enough even for BUS_CLK)

Measuring cycles using DTW on PSoC 6(M4)


New Contributor II

BoTa, thank you for your response.  I've seen your work around this subject on the web

and i've made use of suggestions.

I still want to answer my original question of how to get a clock signal of my choosing

to drive systick.

(and i use software to maintain an in-cpu 64 bit coherent counter as systick overflows)

when i first was researching this (over a year ago) i did look at the WatchDog timer.

but rejected it as that is made to hard reset the chip; and i found no way to override that

so that is just to dangerous.  it would probably work fine in final product but would make

development and debugging a real pain.

thus i chose to use systick as harmless timing is what it is for.

as for a logic 32 bit counter.  that is what i have most recently worked out.  i followed some of

your work on the StatusReg32, and others (like the 32-bit parallel non-contiguous GPIO write technique)

and have that working.  i placed 4 status registers, forced their UDB locations such that their 8bit

access is in-address order and a single 32 bit pointer access works fine.

so the reading works.  however, the separate basic_counter whose outputs connect to these

status registers is the problem: signal skew, ripple count, delays all make the 32 bit value

NOT "coherent" when the fast cpu access happens: the CPU gets mixed up bits, non-linear

progression of the count.

  (so i have the cpu read the count multiple times and compare them until stable over

    the time needed for the HW to do a full clock of the HW 32 bit counter.  this takes multiple

    instructions and if statements...)

and i have not found a way to have status registers "sticky" function

work for this as "sticky" is "clear on cpu read", which means a second cpu read will find

a 32 bit value of 0 !  until the next hw count increment clock comes in.

SO maybe using the counter32 counter with built-in status registers would do better

at keeping the count coherent, and still let me force the udb placement.

or insert a latch layer between my counter and the status registers; but even that

could still have a hazard because of differences in the clocks....

all this is sooo much effort (that some future maintainer of this would have to learn) that

i've not wanted to go there yet.... maybe later today i will do more experiments.

so i am still holding out the hope for systick...

Honored Contributor II


did you see the modified 32-bit Counter?

Phase offset and Quadrature signal generator for lock-in

it is 32-bit, resides in the UDB Datapath, not PLD (as BasicCounter does), and works up to 80MHz BUS_CLK. The reading of the 32-bit Count should be atomic for Datapath (using CY_GET_RE32 (...)).


New Contributor II

Thank you BoTa: no i have not seen that.  i just got it, and am reading the downloaded info.

i tried that component a couple of years ago, and it was very slow reading using the normal

API calls.  i have not read/used the  CY_GET_RE32  call: is that a fast access thing?

(i was going to try reaching inside the normal counter32 and Directive placement into

memory address aligned status register locations... but have not had time yet today.

i'm STILL holding out someone out there can find how to route the signal into the systick...

i have a vague memory of long ago reading something about being able to look at the

digital routing (not the analog: they have the editor for that) and see what the cross-point

switches are and directly manipulating them....

if i knew how to find that signal, on which logic block edge it was, and what switch(es) it

connects to... then i could make headway....

Honored Contributor II


Sorry for being a late-comer to this melee of ideas from such a knowledgeable group of people.

As indicated eariler, the SysTick clock source can come from IMO and ILO and ILO_100 sources.  IMO clock source can come from the ECO XTAL or from a user defined input through the Digital Signal channel.  The external input can be a crystal based device external to the PSoC.

I realize legr_1685996 wants atomic coherency to the 32-bit counter value to have an accurate timestamp without 'hiccups' in the readings.

Here's my 'two-cents' (probably valued less than that).  Using the SysTick with an accurate clock input will yield a 24-bit coherent value.  Would that be enough bits at the least-significant (LS) part of your data?  If not, you need to clock faster to get more resolution.

If the problem is there is not enough bits in the most-significant (MS) part of the data,  you can use a SysTick interrupt to create a separate variable that increments the MS part of the data that adds to the lower 24-bits of the counter.

Consider this:  The SysTick counter value read in the LS part of your data is only as accurate at the time your CPU reads the counter.  Therefore there is latency from when the Event occurs requiring the timestamp:

  • If the Event is tied to an interrupt:
    • Processing the interrupt.   (Assuming the interrupts are enabled and you're not already in another interrupt)
  • If the Event is detected by polling a status:
    • Polling loop delays
  • Reading the 24-bit SysTick value for the LS part.
  • Adding any MS part to the LS part.

A very fast clock source to the SysTick will always be off a few counts at best by the time the SysTick counter read occurs.

Alternate suggestion:

If an uber accurate timestamp is needed with pin-point accuracy in the timestamp on the Event,  I suggest you use a UDB 32-bit counter with capture input.

If your Event can be boiled down to a single digital output, it can be used to feed a Capture input.  This Capture can occur on a rising, falling or both edge to capture the 32-bit timestamp value into 1 or 4 FIFO locations.  This is particularly useful if more than one Event can occur in short time proximity to another.  The latency I mentioned to determine the timestamp is virtually non-existent.   The Capture is HW determined and should have no coherency issues.

If the CPU is not fast enough to acquire 4 Event captures, a DMA channel can be allocated to grab the FIFO data and place them in a RAM buffer for latter analysis.

That's a lot of words for 'two-cents' but what the heck!


"Engineering is an Art. The Art of Compromise."
New Contributor II

Thank you Len (i am sure not that knowledgeable about psoc... yet)

Yes, i use the 24 bits systick counter to feed a software maintained 64 bit counter.

this is not interrupt driven; it is polled in a single-threaded way

at semi-random times 10-30 times per second

(when busy and the values matter, much more times per second when at "idle"

and the values don't matter).

i've used this idiom on other systems so i keep doing it the same way for consistency

across these systems.

the no-interrupt way means debugging is easy and no "critical sections" or locking

is necessary.

there is no hardware event associated with these time-grabs, so HW triggers and

capture are not doable.  and Latency is not an issue here.

one thing i was researching this morning is using a single datapath to maintain 24+ bits of

count.  thus it would not be spread across multiple UDB's.  if a single datapath ALU

could do that, and then have a DMA to move the result into CPU memory safe from

access hazards only when the datapath signals it has a finished, coherent result,

that would work well.  if these timestamps appeared in CPU memory with 1us granularity,

that would be great (i can at this point tolerate 10us granularity).

but i have never used the datapath.

i have still to try BoTa's number 11: the modified 32 bit counter.  i tried the 32 bit counter

approach almost 2 years ago, and it was very slow to read the count!  that was blindly

using the normal API calls... long before i started researching further and doing

direct register access type things.

Honored Contributor II


Since you are polliing the SysTick if you use the Cy_SysTick_GetCountFlag() there may be some issue I noticed.  Here is a link to a discussion of the issue:  Cy_SysTick_GetCountFlag() Issue.

This discussion is concerning the PSoC6 implementation.   I haven't checked to see if this issue is present on the PSoC5.

About assigning an external clock to source to the SysTick:

As was indicated, there are three clock sources that can be used for the SysTick:

  • IMO
  • ILO (~1KHz)
  • ILO_100 (~100KHz)

I'm assuming you want a faster clock than 100KHz.

If you have an external clock source you want to supply to the SysTick you need to choose the IMO clock.

Try the following steps:

  1. Add an input to your TopDesign with a wire and name the wire (net). 
  2. Go to the DWR/Clock tab and select Edit Clocks...
  3. In the Configure System Clocks Window, select Digital Signal in the IMO box then Check the Digital Signal box then select the "..." button.
  4. In the Select source clock window, select the external input netname you assigned, type in the Frequency (tolerance values appear to be for documentation purposes only) then select the "OK" button.
  5. The Configure System Clocks window now has your external clock signal assigned with a target frequency.
  6. Make sure the Digital Signal is selected in the IMO box.
  7. You may have to adjust the PLL and you may have to reassign the Master Clock.
  8. Once you're happy with the system clock assignments, select the "OK" button.
  9. Now SysTick being sourced by IMO uses your assigned external clock.


"Engineering is an Art. The Art of Compromise."
New Contributor II

Sorry Len: nope. that does not work.  i tried your above suggested setup, nope.

the documents say (and my experiments show) that the IMO

does not feed the systick counter.

It is interesting to note that Cypress has been changing the documentation in and

about this area over the years.  from my long-standing Architecture reference

manual from late 2012 version D, page 41 :

"The timer uses either the Cortex-M3 internal clock or a

PSoC 5 clock (see the Clocking System chapter on

page 91). There are two registers that control the clock

source.  The first is the Cortex-M3 register

NVIC_SYSTICK_CTL, which selects whether the source is

internal or external (default). The second is the PSoC 5 reg-

ister PANTHER_WAITPIPE, which selects the external

clock source: either the ILO 100 kHz (default) or a clock

routed from the DSI."

this has been changed in the TRM version G, 2019.  still page 41


The timer can take an internal clock (the free running

clock on the CM3 processor) or an external clock through

the STCLK. In PSoC 5LP devices use one of three sources

as, ILO (1 kHz), ILO_100 (100 kHz), or the SYSCLK (BUS-



And in the PSoC 5LP Registers TRM, Document Number. 001-82120 Rev. *G

(the modern version G, which matches the older version text),

on page 1709 about the Register PANTHER_WAITPIPE:


Bits Name Description

31:4 RSVD1[27:0] Reserved


2 CM3_SYSTCK_SRCSEL CM3 SYSTCK clock source selection.

1= DSI clock (connected to dsi_01_out_p_10 ).

0= 100KHz Slow Clock


when i directly manipulate these bits in these two registers while running,

i do see the CPU clock driving systick (for me this is 66Mhz, my IMO for this

test is 4.9Mhz), or the ILO which i have configured (via the clock config window)

to be 100khz and "routed") which does indeed clock the systick counter at 100khz

(and interesting to note, that it is always using the 100khz signal, regardless

of what is set in the ILO clock config window...)

but when switch to the DSI input... nothing.  no clocking at all.

so my experiment results match what the registers TRM doc says: 100khz,

or a DSI clock (which i can't get a signal to), or more matching the older

Architecture doc: "Cortex-M3 internal", which in the newer doc is changed

to say: BUS_CLK.

but NOT the 1khz ILO....

about reading systick; i don't use any cypress API's.  direct register pointer access.

i don't depend on their flags, and no interrupts.  my software handles 24-bit rollover

into a 64-bit count value.

Honored Contributor II


I read the PSoC5 Register TRM.  It only mentions External clock and the CPU clock.

The PSoC5 Architecture TRM indicates:

4.2.5 SysTick Timer

The SysTick timer is integrated with the NVIC and generates the SYSTICK interrupt. This interrupt can be used for task management in a real time system. The timer has a

reload register with 24 bits available to use as a countdown PSoC 5LP Architecture TRM, Document No. 001-78426 Rev. *C 45 Cortex™-M3 Microcontroller value. The timer can take an internal clock (the free running clock on the CM3 processor) or an external clock through the STCLK. In PSoC 5LP devices use one of three sources as, ILO (1 kHz), ILO_100 (100 kHz), or the SYSCLK (BUSCLK).

I realize it is confusing.

I know you prefer to directly talk to the PSoC registers.  I try to avoid that as much as possible.  This is because if I tend to use the Cypress API calls, issues that show up in silicon, or changing the PSoC device being used can usually be taken care of in the API code with forcing me to rewrite my code.

If you look to the SysTick API call to CySysTickSetClockSource() you find it can change the clock source to CPU clock and the External Clock source which is sourced from the ILO which can be selected as ILO @ 1KHz internal RC  or ILO @ 100KHZ internal RC.

Have you considered using the ECO (external crystal) inputs?  If one of the selections for SysTick  source is the CPU clock and the CPU clock can be sourced from the ECO then this might be a valid clock source with the accuracy you are desiring.


"Engineering is an Art. The Art of Compromise."
Honored Contributor II


I just tried a very simple experiment with the SysTick with different IMO sources.

  • I sourced the internal RC IMO @ 3MHz.  No issue.
  • I sourced the external XTAL IMO @ 24MHz.  No issue.  (Used a CY8CKIT-050 with on-kit 24MHz crystal)
  • I sourced the external DSI signal IMO @ 20MHz (using the "Digital Signal" method I described above).  No issue.  (Used a CTS Knights MXO-053-GA external frequency device)

In each case, the output frequency from the SysTick isr was as expected.

I apologize if I don't understand the true nature of the issue you are having.  I believe my third case validates your question.


"Engineering is an Art. The Art of Compromise."
New Contributor II

Hi Len, sorry for the days delay: other work came up.

Please don't get the wrong impression: i use the cypress API calls all the time.

i'll only go around them in the rare case of wanting speed, or to fiddle around.

and in this case, one can just access these two registers directly and easily.

yes, i see the same documents you do, and yes there is/are some inconsistency(s) in them.

and that is what i'm wanting to resolve: if indeed the writing that says systick can

come from a DSI...  now maybe that DSI is indeed the one that has to clock the CPU.

in which case the systick counter will run way too fast (because the cpu needs to run

fast) to be of any real use.

about your experiments: that is what i do also: though i am using my own PCB with a different

frequency crystal (4.9Mhz).

so yes, my cpu clock can always be up around 66Mhz, and my earlier result still stands:

that in the 3 cases of the setting of those register flags, systick clocks at 66Mhz, 100Khz, or nothing.

i am not on the cypress-work system now, so i can't check the internals of the systick

API call to see what else it does with register bits (it has been some time since i looked inside it).

with your experiment, i don't clearly see your output frequencies in those cases:

did you actually get 1Khz and 100Khz, and CPU clock?

(because i never get the 1khz clock).

on another direction: even if reading systick counter register is 1 instruction,

the extra math to expand that into 32 or 64 bits takes extra instructions: so the

end result may be longer time taken than using some other HW.

i did setup and use a Counter32, and that ends up being, in the end, about

the same time as the systick method.

so my question about getting systick to clock how i want still stands.

but the final result goal might use another method (Counter32).

Honored Contributor II


I apologize if I haven't fully understood the nature of what you are trying to achieve.

Your issue is a challenge for me to try to help you to solve.

Here is my understanding of your requirements.

  • You were looking for use of the SysTick to provide a timestamp.
  • You want this timestamp to be reasonably accurate that is why you are trying to use a 4.9MHz crystal.
  • You want your BUS_CLK (CPU clock) to be 66 MHz.
  • You are looking for about 64bits of timer resolution (24bits from the SysTick counter + 32bits from the SysTick wrapping)

Any remaining requirements are a bit unclear to me.

Here is some data on my experiments that you have requested.


24 MHz3 MHz16 MHzRCIMOPLL100 KHzBUS_CLK66 MHz66 MHz66 MHz500-166 KHz
24 MHz3 MHz16 MHzXTALIMOPLL100 KHzBUS_CLK66 MHz66 MHz66 MHz500-166 KHz
24 MHz3 MHz16 MHzDSIIMOPLL100 KHzBUS_CLK66 MHz66 MHz66 MHz500-166 KHz
24 MHz3 MHz16 MHzRCIMOPLL100 KHzILO66 MHz66 MHz66 MHz500-1102.7 Hz
24 MHz3 MHz16 MHzRCIMOPLL1 KHzILO66 MHz66 MHz66 MHz500-1not cycling

Experiment Specs:

The SysTick Src is either the BUS_CLK or the ILO.

In my experiment, I use the SysTick isr to increment the SysTick wrap variable.

The output systick_isr_toggle is an output I dedicate to the SysTick isr routine that gets executed when the SysTick Counter counts down to 0.  There I toggle the output producing 1/2 the systick wrap frequency.

The SysTick Reload is the value loaded into the SysTick reload register.  This is always 500-1.  Therefore the output frequency observed with the SysTick counter set to 500-1 and the output toggling in the SysTick isr is the SysTick input clock / 1000.

You will note in the data above, I was not able to get the ILO set to 1KHz to run either.

You state:

... in which case the systick counter will run way too fast (because the cpu needs to run

fast) to be of any real use.

If the CPU clock is 66MHz, you can set the SysTick Reload count to 1000000-1.  Therefore the SysTick count value read will have an approximate accuracy of 15ns per count.  The SysTick counter will wrap around every 15msec.  With a 32bit SysTick wrap counter, it will take 753 days (>2 years) before it wraps to 0.  It you need longer, consider a 64bit SysTick wrap counter.

It appears from your requirements of a crystal-based accuracy that the SysTick clock source of ILO will not work for you.  The ILO is a RC-based oscillator.

This is where my understanding of your design intent goes a bit 'dim'.  You want to run the CPU @ 66MHz.  In your case the SysTick needs to be sourced by the CPU clock which is crystal-based in your design for timestamp accuracy purposes.  The SysTick counter can keep up with 66MHz as the input frequency.  To reduce the SysTick wrap rate, use a higher SysTick Reload count.  The counter is 24bits which provides up to a 16777216 count before wrapping.

One more question:

You state:

...  i am using my own PCB with a different frequency crystal (4.9Mhz).

Is this crystal on the XTAL circuit of the PSoC5?  Is it being driven by an external oscillator circuit before inputted into the PSoC5?

If you're interested, I've included my example project that I used for the experiments.  It is very simple.


"Engineering is an Art. The Art of Compromise."