How do I test if a 32K XTAL is installed?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

To all,

I have a PSoC 5LP and I enable the XTAL 32KHz in the clock editor.   Is there an official way to detect if a 32K watch XTAL is installed on the PCB?

Note: If the XTAL is installed, my XTAL clock out is 32768 Hz (as expected).  If not installed, the XTAL clock out is about 1984 Hz.  Although I could perform a rough sanity check of the XTAL_32K out to the IMO, I'd prefer not to allocate the counter.

I've read the CY_CLK_XTAL32_CR_REG for the analog stabilization status.  I always get a "stable" reading with or without a XTAL.

I'm not supporting the ILO @ 32K therefore I don't expect the digital stabilization status to be valid.

Len

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

Hello Len,

Thanks for your patience. We have checked the issue you have reported. Ideally CY_CLK_XTAL32_CR_REG ana_stat value is not designed to confirm the presence of the crystal, but to confirm the oscillator is stable if it is present in the circuit. The designer has to make sure that is the case. The inputs to the bypass capacitors are interfering and generating the signal you are observing. As these are not affecting the stability of the crystal oscillator output when crystal is present, it does not affect the normal functionality too. As this meets the expected working of the device under how the functionality is supposed to be used, this use case cannot be considered as a fault.


Anyways thanks a lot for reporting the issue. Have a nice day !

Best Regards,

Vasanth

View solution in original post

0 Likes
13 Replies
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hi Len,

please provide your project, so we can check.

You wrote that you used CY_CLK_XTAL32_CR_REG. Did you use this directly or did you use the corresponding API function, along with CyXTAL_32KHZ_Start() function?

Regards

0 Likes
lock attach
Attachments are accessible only for community members.

user_246598725,

I've attached a very simple project.

To answer your questions:  I used CY_CLK_XTAL32_CR_REG directly and CyXTAL_32KHZ_ReadStatus().  Either resulted in an answer of 0x20 = ANA_STAT = stable with or without the XTAL_32K installed.

Len

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

user_246598725,

I may have more information.

The TopDesign in the project archive has the following pin assignments:

Pin nameOutput FreqPin #
Pin_ILO~1000HzP0[0]
Pin_XTAL_32Kto1K1024HkzP0[1]
Pin_IMOto1K1000HzP0[2]
Pin_PLLto1K1000Hz

P0[3]

This pin configuration always yields ANA_STAT = stable even with the XTAL_32K not installed.

If I change the pin # configuration to the following:  ANA_STAT = not stable with the XTAL_32K not installed.

Pin nameOutput FreqPin #
Pin_ILO~1000HzP0[0]
Pin_XTAL_32Kto1K1024HkzP0[1]
Pin_IMOto1K1000HzP2[0]
Pin_PLLto1K1000Hz

P2[1]

Apparently changing the other outputs "fixed" the issue.

Len

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

Here's some additional information from testing I've performed.

I placed the pin #s back to the original assignments.   However I changed the outputs P0[2] and P0[3] from STRONG to RESISTIVE_PULLUP_PULLDOWN. (ie. decreased the slew-rate of output changes).  This allowed the ANA_STAT = not stable when no XTAL_32K is installed!  Yeah!

Pin name

Output Freq

Pin #

Drive

Pin_ILO~1000HzP0[0]STRONG
Pin_XTAL_32Kto1K1024HkzP0[1]STRONG
Pin_IMOto1K1000HzP0[2]RESISTIVE_PULLUP_PULLDOWN
Pin_PLLto1K1000Hz

P0[3]

RESISTIVE_PULLUP_PULLDOWN

I decided to try another test.  I was curious if the problem I'm having I associated with the fact that the CY8CKIT-059 I'm using has external 1uF caps to ground on them.  (Hence the reason I slowed the slew-rate in the test above).  For this test I changed the pin drive back to STRONG and moved them to P0[5] and P0[6] which have no external caps on the pins.  Results:  ANA_STAT = not stable when no XTAL_32K is installed!  Yeah again!

Pin name

Output Freq

Pin #

Drive

Pin_ILO~1000HzP0[0]STRONG
Pin_XTAL_32Kto1K1024HkzP0[1]STRONG
Pin_IMOto1K1000HzP0[5]STRONG
Pin_PLLto1K1000Hz

P0[6]

STRONG

Len

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

Hello Len,

glad that you got it to work. I hadn't enough time to test the initial project, sorry. I wondered why you didn't use CyXTAL_32KHZ_Start() function, which does a bit more than only starting the oscillator.

What confuses me is that port pins which aren't related to the XTAL are influencing the behaviour of the XTAL.

Regards

0 Likes

user_246598725,

I agree.  I'm also concerned that neighboring pins can influence the analog XTAL_32K lock circuit to "fake-out" a lock indication.  Do you think this should be investigated by Cypress?  If I'm missing something rudimentary: My bad.  If there is something not previously considered by Cypress, it might justify an App note or silicon errata when placing port pin assignments in a design.

I'm not using CyXTAL_32KHZ_Start() because it's handled in the "Configure System Clocks" editor by setting the XTAL 32KHz checkbox.  If I don't set it, the "Generate Application" phase aborts the build due to the fact I'm using the XTAL_32K as a clock source in the TopDesign.

Thanks for your input.

Len

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

Hello Len,

I agree.  I'm also concerned that neighboring pins can influence the analog XTAL_32K lock circuit to "fake-out" a lock indication.  Do you think this should be investigated by Cypress?  If I'm missing something rudimentary: My bad.  If there is something not previously considered by Cypress, it might justify an App note or silicon errata when placing port pin assignments in a design.

Yes, asking Cypress about this is a good idea. On worst case, there's really a problem which must be included in errata or application note, in best case they'll point you to the application note, etc. where this behaviour can be refered. If possible, post their response here.

I already checked some application notes, but I didn't find anything. The only thing I could imagine is that it's related to the internal analog switches or, as you assumed, the VREF capacitors. P0.2 and P0.3 are on the same analog global "lane" as P15.2 and P15.3 (the XTAL32 pins). So, this might be the explanation. Maybe it can be verified by doing the same experiment with other ports on the same lane (e.g. P3.6/P3.7).

Regards

0 Likes

user_246598725,

I tried your suggestion by placing the outputs from P0[5]  to P3[6]  and P0[6] to P3[7].   The analog stabilization still yields the correct reading.

I agree, Cypress should know about this.  However since they functionally disabled the "Create a Support Case", how do I contact Cypress with this issue?

Len

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

You're right, they disabled it - didn't know that. According to website, the new place for issues is developer community, which is also monitored by Cypress support staff. I assume the workflow is as follows:

  • if a topic is replied by another community member and marked as answered, there wouldn't be a response from Cypress
  • If no one replies or if the topic is not marked as answered within a given time, a Cypress support member will be informed

I can't see anything which will raise the priority of an issue if someone needs urgent help - strange.

So, it seems that we've to wait until Cypress makes a statement about this.

Regards

0 Likes

Hello Len,

We are checking the issue you have reported. We will update you soon.

Best Regards,
Vasanth

0 Likes

Vasanth,

Thank you!

Let me know if you need more assistance to root cause this issue.

I'm using an out-of-the-box CY8CKIT-059.  However, it may be an issue only on specific silicon.

Len

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

Hello Len,

Thanks for your patience. We have checked the issue you have reported. Ideally CY_CLK_XTAL32_CR_REG ana_stat value is not designed to confirm the presence of the crystal, but to confirm the oscillator is stable if it is present in the circuit. The designer has to make sure that is the case. The inputs to the bypass capacitors are interfering and generating the signal you are observing. As these are not affecting the stability of the crystal oscillator output when crystal is present, it does not affect the normal functionality too. As this meets the expected working of the device under how the functionality is supposed to be used, this use case cannot be considered as a fault.


Anyways thanks a lot for reporting the issue. Have a nice day !

Best Regards,

Vasanth

0 Likes

Vasanth,

Thanks for looking into this.  Apparently I discovered an interesting side effect.  I'll have to take extra caution in selecting ancillary pin outs.

Len

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