PSoC 4 WCO issue

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.
KimS_967071
Level 2
Level 2
10 replies posted 5 sign-ins 5 replies posted

I have my project configured to use an external WCO instead of the internal 32 kHz ILO.  I am using a 32.768 kHz 10 ppm crystal with a load capacitance of 9 pF.  I used the 2 to 1 cap recommendation.  My capacitors are 27 pF and 13.5 pF (stacked a 12 pF and a 1.5 pF to get them in parallel).  All traces are short and equal in length.

I have the same project running on 2 boards and have my EXT_int pins tied together with a pull down.  I power up both boards at the same time and then pull the EXT_int pin high to sync up the one second outputs I am generating with the watchdog interrupts.  I am looking at the onesecpulse output from both boards on my scope.  After I bring the EXT_int line high both of the onesecpulse output rising edges are aligned.  After 10 mins they are drifting 50 ms from each other.  This would give 300 ms in an hour and in a few hours they would be off by a second and in a month 216 s. 

I started with what I thought was a 32.768 kHz 5 ppm crystal with a load capacitance of 12.5 pF.  My capacitors were 36 pF and 18 pF.  I was getting 14.8 ms in 10 mins and 44 ms of drift in 30 minutes with it.  Which was still more than I was expecting.  Digikey and the datasheet had the part listed as 5 ppm but when I went to the ECS website and searched for the part it was listed as 20 ppm but in the datasheet I downloaded from them it was listed as 5 ppm.  So, I had a 10 ppm crystal available to try and figured it would be better than the results I was getting with this one but instead it was 3-4 times worse. 

From a 20 ppm crystal I was expecting approximately 52 s of drift in a month, 1.2 ms in a minute, 12 ms in 10 mins, and 36 ms in 30 mins.  At room temp.

This is a pretty basic project with just the WCO, watchdog, and some I/O.  Am I missing something in the config for the WCO?

thanks,

Kim

0 Likes
1 Solution

Kim,

I believe that the issue in the capacitors variation, not temperature. Switch XTALs to confirm. Use caps from same tape to have closer values.

Alternative solution can be to use whatever XTAL frequency, but to fine-tune output clock using DDS technique (DDS only needs to know precise XTAL frequency), so while MASTER_CLOCK will be different on two boards, the DDS output frequency can be practically the same. See e.g. DDS24 an DDS32 generators here:

DDS24: 24-bit DDS arbitrary frequency generator component

Re: How can I handle a PSoC 5 community library DDS24 on PSoC 4 BLE device ? 

/odissey1

View solution in original post

0 Likes
8 Replies
odissey1
Level 9
Level 9
First comment on KBA 1000 replies posted 750 replies posted

Kim,

I believe that 20ppm accuracy refers to the frequency stability of the individual XTAL. There is another parameter named Pullability, which indicates frequency accuracy beween XTALs in the same setup.

From ECS website:

Frequency Stability: The most common stabilities are 25, 50 and 100 PPM. Overall stability usually includes accuracy at 25°C, effects due to changes in operating temperature, input voltage, aging, shock and vibration. ... For tighter than 25 PPM stability applications, please consult the factory or consider a TCXO.

I believe that other factors determine actual output frequency of XTAL circuit, primarily load capacitors, which greatly vary in value (10%). To test this simply switch XTAL1 and XTAL2 on the boards: if no significant amount of change observed, than the assumption is correct. To see how capacitance variation affects output frequency, check this demo project:

Simple FM audio transmitter using PSoC5

Consider some adjustable XTAL circuit, e.g. VCXO, to finely--tuned output frequency, or lock frequency to the 1pps GPS signal for ultimate accuracy. There are some other options. Can you describe your application more?

/odissey1

0 Likes

Hi odissey1,

Thanks for the response.  I am considering a TXCO too.  I know temper and aging are going to affect my resulto but right now I am working on the bench so it should be closer to 72 F in my office.  I suppose I could try to generate some heat to warm it up a bit.  But, the temp remained relatively constant testing both crystals.  So, I would have expected better results from a 10 ppm crystal.

My plan is to use GPS to set the RTC on receipt of 1PPS after lock.  Then I need to turn off GPS because this is a battery operated device.  It would be nice if I could leave the GPS on!  I intend to periodically turn GPS back on to resync but I am also trying to minimize that too.  Every 1-2 hours.  I have a project working with GPS and the RTC but I made a new project with just the WCO to try to figure what was causing it to drift faster than expected. 

Thanks,

Kim

0 Likes

Kim,

I believe that the issue in the capacitors variation, not temperature. Switch XTALs to confirm. Use caps from same tape to have closer values.

Alternative solution can be to use whatever XTAL frequency, but to fine-tune output clock using DDS technique (DDS only needs to know precise XTAL frequency), so while MASTER_CLOCK will be different on two boards, the DDS output frequency can be practically the same. See e.g. DDS24 an DDS32 generators here:

DDS24: 24-bit DDS arbitrary frequency generator component

Re: How can I handle a PSoC 5 community library DDS24 on PSoC 4 BLE device ? 

/odissey1

0 Likes

I received some parts over the weekend so I will do some more testing today.  I ordered my caps from Digi-key so they are from the same tape and they are 5%. 

Will I be able to use the WCO for the clock input or does it require HFClk or EXTclk via the PLL Sel routing?  I need to use deep sleep too so I will loose all the clocks except WCO.

If I am going to consider one of these, it looks like based on the comments that the DDS32 is better for PSoC4 devices.  Is that correct?  Specifically, I am using CY8C4246.

0 Likes

Kim,

DDS24 is PLD-based and will consume all PLD resources of approx. 4 UDB blocks (but leaves UDB datapath unused). DDS32 is UDB-based (leaves PLD resources unused), in 24-bit mode it will consume only 3 UDB datapaths. The 24-bit accuracy should be enough to achieve resolution of  <1ppm (INP_CLOCK / 1'677'7216). I didn't test it with WCO clock, so can't comment on that. If WCO can be routed to UDB somehow, it will work. The internals of DDS24 and DDS32 are entirely different, it is worth checking both of them.

There is related paper about using DPLL to lock to 1PPS GPS signal, which may be of interest (Use DPLL to Lock Digital Oscillator to 1PPS Signal):

https://www.fpgarelated.com/showarticle/991.php

Basically, once in a while, DDS clock can be tuned up by API call to achieve a lock with 1PPS signal and then left freewheeling. If perfect lock is not needed, then simply measure ticks between 1PPS signals, and re-calculate DDS tuning word in code - that will be much faster then waiting for DPLL to settle the phase.

/odissey1

0 Likes

Hi odissey1,

user_342122993 schrieb:

Kim,

DDS24 is PLD-based and will consume all PLD resources of approx. 4 UDB blocks (but leaves UDB datapath unused). DDS32 is UDB-based (leaves PLD resources unused), in 24-bit mode it will consume only 3 UDB datapaths. The 24-bit accuracy should be enough to achieve resolution of  <1ppm (INP_CLOCK / 1'677'7216). I didn't test it with WCO clock, so can't comment on that. If WCO can be routed to UDB somehow, it will work. The internals of DDS24 and DDS32 are entirely different, it is worth checking both of them.

A question about the DDS32 24-bit UDB implementation: the CY_GET_REG16/CY_SET_REG16 and CY_GET_REG32/CY_SET_REG32 functions provided by Cypress can access the UDB registers atomically. This is not the case for 24-bit, so how did you overcome this?

Regards

0 Likes

Ralph,

This is a snapshot from DDS32.h, which compiles and (I believe) works:

#if (DDS_1_BUS_WIDTH == 24u)

#define DDS_1_ReadStep()     ((uint32) CY_GET_REG24(DDS_1_STEP_PTR))

#define DDS_1_WriteStep(val)               CY_SET_REG24(DDS_1_STEP_PTR , val)

/odissey1

0 Likes

Hi odissey1,

okay, so the access is not atomically. I asked because I'm currently also creating a 24-bit UDB component, where I came across this. So I decided to use 32-bit UDB even when only 24-bit are needed to ensure atomic access. This is just for information, if you think that this might become an issue for your component.

Regards

0 Likes