CY8CKIT-062S2-43012 Kit and Using the ECO

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.
MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

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.

0 Likes
1 Solution
MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

 

@YashM, on a clean Ubuntu VM, I am able to create an identical hex file, likewise with my Windows installation. There must be something wrong with my Mac installation, because that hex file is different. 

With the Mac build, the design.modus file is identical, but the hex output does not match. When I get the opportunity, I will go through my installation and see if anything is amiss. At this point, I think we can can close this issue and call it a build installation problem.

I should note that his hex file is very unstable. It only runs right after you program the board. If you unplug, and then plug it back in, it never runs, regardless of which system it is plugged in to. I would not recommend anyone use this clock setup.

 

View solution in original post

0 Likes
19 Replies
Gautami_12
Moderator
Moderator
Moderator
50 likes received 100 solutions authored 250 replies posted

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.

 

Best Regards,

Gautami J

 

0 Likes
lock attach
Attachments are accessible only for community members.
MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

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:

http://txccrystal.com/images/pdf/8y.pdf

So I'm unable to verify frequency tolerance, stability, load capacitance, power drive, etc.

Thank you for looking into this!

0 Likes
MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

Hi @Gautami_12,

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.

 

0 Likes

Hi

>> 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.

Thanks

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

Hi,

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.

0 Likes
Gautami_12
Moderator
Moderator
Moderator
50 likes received 100 solutions authored 250 replies posted

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?

Warm Regards,
Gautami J

 

0 Likes

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.

0 Likes
Gautami_12
Moderator
Moderator
Moderator
50 likes received 100 solutions authored 250 replies posted

Hi @MattTreiber ,

Apologies for the delay in reply,
Can you please set the CLK_HF0 source clock to CLK_PATH1 as shown below screenshot?

Gautami_12_0-1674120749346.png

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.

Warm Regards,
Gautami J

0 Likes
MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

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.

Kind regards,

Matt

0 Likes
Gautami_12
Moderator
Moderator
Moderator
50 likes received 100 solutions authored 250 replies posted

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.

Warm Regards,
Gautami J

0 Likes
lock attach
Attachments are accessible only for community members.
MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

"Initially, when we enabled the ECO, we didn't connect the CLK_HF0 to any clock;"

In the project I sent you, and I re-downloaded again to make sure, CLK_HF0 is connected to CLK_PATH0 which is the 100MHz Frequency Lock Loop source. The project does not run as is. I've attached a screen shot of the System config to show that.

Per your request, I connected CLK_HF0 to CLK_PATH1 which is the enabled PLL0 set to 48MHz. However, the demo does not run either with this setup.

When I set System Idle Power Mode to CPU Sleep though, CLK_HF0 can be set to 100MHz FLL source or the 48MHz PLL source and the demo project runs.

0 Likes
lock attach
Attachments are accessible only for community members.
Gautami_12
Moderator
Moderator
Moderator
50 likes received 100 solutions authored 250 replies posted

Hi @MattTreiber ,

Can you please remove the extra changes that are done in the driver source file(like set System Idle Power Mode to CPU Sleep)? and import the attached project? 
I have attached the project provided by you that is working at my end only by replacing the CLK_HF0 source clock with CLK_PATH1(No changes are made in the driver file).

Warm Regards,
Gautami J

0 Likes
lock attach
Attachments are accessible only for community members.
MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

Hi @Gautami_12,

I've downloaded your version of the project, built it, and I've run it on both Rev 7 and a Rev 8 versions of the CY8CKIT-062S2-43012 eval board. Both boards fail to run when directly programmed. I develop on an Apple M1 Macbook Pro, but I also have access to a Windows machine and I had the same results as shown in the MQTT Client Failure.png image attached. Both machines have ModusToolbox 3.0 installed.

At one point it ran with the Debugger, but I have been unable to repeat that. It fails executing here:

cybsp_init()->cycfg_config_init()->init_cycfg_system()->init_cycfg_power()->Cy_SysPm_LdoSetVoltage()->Cy_SysPm_WriteVoltageBitForFlash() where it stalls with this call:

while (Cy_IPC_Drv_IsLockAcquired(ipcSyscallBase))
{
/* Polls whether the IPC is released */
}

There it stalls and waits forever.

Best regards,

Matt

0 Likes
lock attach
Attachments are accessible only for community members.
Gautami_12
Moderator
Moderator
Moderator
50 likes received 100 solutions authored 250 replies posted

Hi @MattTreiber ,

Can you revert back the changes that you have made in the cy_syspm.c file and try to run the project I have attached?
you can also refer to the attached cy_syspm.c file for reference.

Warm Regards.
Gautami J

0 Likes
lock attach
Attachments are accessible only for community members.
MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

Hi @Gautami_12 ,

As I mentioned above, I ran your exact project. A git diff shows that you changed the WiFi AP SSID to "GautamiJ". CLOCK_HF0 is set to PATH1 and System Idle Power Mode is set to System Deep Sleep. I ran again it just now and it does not run.

Setting System Idle Power Mode to CPU Sleep allows the project to run. I've attached screen shots of both System Idle Power Mode settings with your uploaded.

Best regards,

Matt

0 Likes
lock attach
Attachments are accessible only for community members.
YashM
Moderator
Moderator
Moderator
First question asked 250 sign-ins 100 replies posted

Hi

Please try to load the following project and let us know your observation.

Thanks

0 Likes
lock attach
Attachments are accessible only for community members.
YashM
Moderator
Moderator
Moderator
First question asked 250 sign-ins 100 replies posted

Hi

Please try to load this project as well.

Thanks

0 Likes
MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

 

@YashM, on a clean Ubuntu VM, I am able to create an identical hex file, likewise with my Windows installation. There must be something wrong with my Mac installation, because that hex file is different. 

With the Mac build, the design.modus file is identical, but the hex output does not match. When I get the opportunity, I will go through my installation and see if anything is amiss. At this point, I think we can can close this issue and call it a build installation problem.

I should note that his hex file is very unstable. It only runs right after you program the board. If you unplug, and then plug it back in, it never runs, regardless of which system it is plugged in to. I would not recommend anyone use this clock setup.

 

0 Likes
YashM
Moderator
Moderator
Moderator
First question asked 250 sign-ins 100 replies posted

Hi @MattTreiber ,

Thanks for your updates. We take your feedback regarding the MAC OS installation (and the hex file mismatch). We will try to reproduce the issue of MAC OS and will update you with the same. 

At present, I will close the thread and please feel free to open a new community thread if you face any further issues regarding the MAC OS installation.

Thanks

Yash

0 Likes