The CY8CKIT-062S2-43012 Kit has an external crystal oscillator -- Y2 -- with a frequency of 17.2032MHz. I'm trying to feed it to the PLL to generate a 50MHz for CLK_HF2 to feed to the WiFi chip. I've enabled the ECO and entered 17.2032 for the clock speed. I left the other parameters the same. If PATH_MUX1 has IMO selected for the clock source, the demo project runs just fine. However, when the ECO is selected for the clock source, cybsp_init() hangs on a call to Cy_IPC_Drv_IsLockAcquired() in cy_ipc_drv.h. P12_6 and P12_7 are enabled and set to Analog Hi-Z and are connected to eco_in and eco_out respectively.
Is there a power sequence that is needed to be followed?
I've attached my design configuration file. The project was generated from the New Application GUI. I am using ModusToolbox version 3.0 and Device Configurator v4.0.
Our previous code base was based on an earlier version of the MQTT project and used the v2.4.1 toolset. We were able to enable the ECO and set the clocks without an issue.
Any help would be appreciated.
PSoC 6 MCU
Hi @MattTreiber ,
If possible, can you please send the strip-down version of your project? This will help us understand the issue and we will try to check it on our end.
->Is there a power sequence that is needed to be followed?
>> No, we do not follow any particular power sequence for enabling ECO.
Also, if possible can you please check the load capacitances as per the page no. 12 of hardware design considerations for PSoC 6? This will ensure all the hardware settings are on point.
Thank you for the quick response. I ran two experiments, with the first, enable the ECO and set it to 17.2032 MHz as described in the kit's schematic. Set PATH_MUX1 to ECO input. PLL0 is left unchanged at 48MHz.
In this case, it's difficult to figure out what is happening as after the call to cy_wcm_init(), the debugger loses track of execution. However, there are successful calls to Cy_SysClk_EcoConfigure() and Cy_SysClk_EcoEnable() before initializing the WiFi Connection Manger. So in theory, the ECO is enabled and running.
It is my understanding that the WiFi module's clock is controlled by CLK_HF4 which is connected to SDHC0 (CLK_HF2 is dedicated to the QSPI interface in this design). It is not enabled explicitly in the config, so in my second experiment, I enabled CLK_HF4 and set it to CLK_PATH0 based off of the FLL 100MHz clock. However, the correct clock must not still not be getting to the WiFi module as cy_wcm_init() fails to return again.
In this later case, the ECO and PLL0 are enabled, but the peripherals are using non-ECO clocks so in theory, the WiFi module should work. Setting PATH_MUX1 back to the IMO allows for normal and successful operation again.
I've attached my project with PATH_MUX1 set to ECO and I have enabled CLK_HF4 and set it to CLK_PATH0 at the default 100MHz. I've created a brand new project just to make sure it's the minimal changes. I did not include my local changes to the WiFi and MQTT connections.
In theory, the PLL0 output is not being used, but it appears to be set up to be the default clock for something that is interfering with the WiFi module.
As to the ECO caps, according to the kit schematic and BOM, C37 and C38 are 10pF load capacitors. I have Rev 07 of the kit hardware. The current BOM references the TXC 8Y17270001 ECO and is listed as a 10pF oscillator. Unfortunately, the part number in the BOM does not match the 8Y series datasheet part numbering scheme from TXC:
So I'm unable to verify frequency tolerance, stability, load capacitance, power drive, etc.
Thank you for looking into this!
I noticed that the default setting for the load capacitance is 18pF. I switched it to 10pF and then to 5pF but that those failed in other ways, like in FreeRTOS in the idle tasks where there is an assert that fails while trying to deep sleep in vApplicationSleep():
// If you hit this assert, the latency time (CY_CFG_PWR_DEEPSLEEP_LATENCY) should
// be increased. This can be set though the Device Configurator, or by manually
// defining the variable.
CY_ASSERT(actual_sleep_ms <= pdTICKS_TO_MS(xExpectedIdleTime));
However, if I change the System Idle Power Mode to CPU Sleep from System Deep Sleep in the Power->RTOS section, the board comes up and functions with the WiFi module running off of PLL0.
Is FreeRTOS not compatible with the default low frequency clock setup for System Deep Sleep mode? And if not, how should the low frequency clocks be set up? We have a battery powered device and we would love every power saving measure we can use.
>> However, if I change the System Idle Power Mode to CPU Sleep from System Deep Sleep in the Power->RTOS section, the board comes up and functions with the WiFi module running off of PLL0.
Just for confirmation - does the setup works with ECO to PLL0 connection using the above configuration?
Also, can you please enable CLK_HF5 and probe the signal on External Pin (please set it to CLK_PATH1)? Please share the output.
That is correct. When the System Idle Power Mode is set to CPU_SLEEP instead of System Deep Sleep, the ECO can be selected for PLL0 and the demo code runs normally. I've attached a screen shot of the ~48MHz output to the green LED from PLL0 (CLK_PATH1). The output is the same regardless of the System Idle Power Mode.
Hi @MattTreiber ,
"When the System Idle Power Mode is set to CPU_SLEEP instead of System Deep Sleep, the ECO can be selected for PLL0 and the demo code runs normally" and "The output is the same regardless of the System Idle Power Mode." both are contradictory and you please explain?
I apologize. The later sentence refers to the HF5 clock output which is PLL0 set to 48MHz and based on the ECO input per your earlier request. I set the HF5 to output the clock on the LED Green pin. Regardless of the System Idle Power Mode, there was a ~48MHz clock on the LED Green pin.
Hi @MattTreiber ,
Apologies for the delay in reply,
Can you please set the CLK_HF0 source clock to CLK_PATH1 as shown below screenshot?
The ECO-->PLL was not connected to CLK_ALT_SYS_TICK hence you faced this issue.
Please verify this at your end and let us know if you still face problems.
Hi @Gautami_12 ,
I've switched CLK_HF0 to CLK_PATH1, but the demo code will still not run.
> The ECO-->PLL was not connected to CLK_ALT_SYS_TICK hence you faced this issue.
> Please verify this at your end and let us know if you still face problems.
I am a little confused. In your setup, CLK_ALT_SYS_TICK is still set to the Watch Crystal Oscillator (32.768kHz +/- 0.015%). To connect CLK_ALT_SYS_TICK to ECO-->PLL, you would have to set CLK_TIMER to CLK_HF0 instead of Internal Main Oscillator.
However, I try to link CLK_ALT_SYS_TICK to ECO-->, I tried setting CLK_TIMER to CLK_HF0, dividing by 8, then 60, to yield a frequency of 100.053 kHz. Setting CLK_ALT_SYS_TICK to CLK_TIMER then still did not run.
So far, only by switching the System Idle Power Mode to CPU Sleep. With it set to System Deep Sleep, the demo will not run with the two settings above.
I've attached two config settings, one just as yours and what I described above where CLK_ALT_SYS_TICK is connected to EC0-->PLL and is 100kHz. In both cases, the demo will not run with System Idle Power Mode set to System Deep Sleep. The demo will run with it set to CPU_Sleep.
Hi @MattTreiber ,
Apologies for the confusion. Please ignore "The ECO-->PLL was not connected to CLK_ALT_SYS_TICK hence you faced this issue."
Initially, when we enabled the ECO, we didn't connect the CLK_HF0 to any clock; hence, CM4 was not getting any clock and there was no response from the MCU. Later, we connected the HF0 by providing the ECO clock to it via PLL0 and the MCU responded and the demo was working as expected.
Also, you can keep the CLK_ALT_SYS_TICK connected to WCO.
Please can you try the same at your end and do let us know your observation.
Note - We are using the same project that was provided by you.