- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
Solved! Go to Solution.
- Labels:
-
PSoC 5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I may have more information.
The TopDesign in the project archive has the following pin assignments:
Pin name | Output Freq | Pin # |
---|---|---|
Pin_ILO | ~1000Hz | P0[0] |
Pin_XTAL_32Kto1K | 1024Hkz | P0[1] |
Pin_IMOto1K | 1000Hz | P0[2] |
Pin_PLLto1K | 1000Hz | 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 name | Output Freq | Pin # |
---|---|---|
Pin_ILO | ~1000Hz | P0[0] |
Pin_XTAL_32Kto1K | 1024Hkz | P0[1] |
Pin_IMOto1K | 1000Hz | P2[0] |
Pin_PLLto1K | 1000Hz | P2[1] |
Apparently changing the other outputs "fixed" the issue.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 | ~1000Hz | P0[0] | STRONG |
Pin_XTAL_32Kto1K | 1024Hkz | P0[1] | STRONG |
Pin_IMOto1K | 1000Hz | P0[2] | RESISTIVE_PULLUP_PULLDOWN |
Pin_PLLto1K | 1000Hz | 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 | ~1000Hz | P0[0] | STRONG |
Pin_XTAL_32Kto1K | 1024Hkz | P0[1] | STRONG |
Pin_IMOto1K | 1000Hz | P0[5] | STRONG |
Pin_PLLto1K | 1000Hz | P0[6] | STRONG |
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Len,
We are checking the issue you have reported. We will update you soon.
Best Regards,
Vasanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."