cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC™ 6

joco_4017211
New Contributor

Downloaded example dated: 01/10/2019. https://www.cypress.com/documentation/code-examples/ce219881-psoc-6-mcu-switching-between-power-mode...

I'm using the PSoC 6 BLE Pioneer Kit.

Note: I had to install and change the project to use PDL 3.1.0 to get it to build.

There is a way to get stuck in ULP (slow flashing) and then the button doesn't have any effect to the LED.

Example captured with power usage:

CE219881_ULP_bug.png

0 Likes
1 Solution
RodolfoGL
Employee

Hi. I was able to reproduce the problem. I found there is a bug in this code example. In the Clock_ExitUltraLowPowerCallback(), inside of the switch statement, change CY_SYSPM_BEFORE_TRANSITION to CY_SYSPM_AFTER_TRANSITION. We should only increase the FLL clock after exiting the ULP mode.

View solution in original post

13 Replies
RodolfoGL
Employee

Hi. I was able to reproduce the problem. I found there is a bug in this code example. In the Clock_ExitUltraLowPowerCallback(), inside of the switch statement, change CY_SYSPM_BEFORE_TRANSITION to CY_SYSPM_AFTER_TRANSITION. We should only increase the FLL clock after exiting the ULP mode.

View solution in original post

joco_4017211
New Contributor

Alright.  New problem.  Power usage after reset (7.85mA) does not match power usage after going to ULP and then back to LP (4.298mA).

The fixi above does seem to keep things working so thats a good step.

CE219881_ULP_bug2.png

0 Likes
RodolfoGL
Employee

That's probably related to the GPIO debug ports. After programming, the debug pins might be leaking some current.

You can avoid this if you disable debugging. Go to Design Wide Resources > System > Debug Select. Select GPIO.

0 Likes
joco_4017211
New Contributor

RodolfoG_11 wrote:

That's probably related to the GPIO debug ports. After programming, the debug pins might be leaking some current.

You can avoid this if you disable debugging. Go to Design Wide Resources > System > Debug Select. Select GPIO.

No change.

0 Likes
joco_4017211
New Contributor

Any additional thoughts.  I could understand that going to sleep mode and back could place various devices in power down and then they might not be woken up.  But switching cpu frequency to ULP and then back to LP, I'm more confused on why this would change power usage.

It hints there might be a power bug either on device reset or during transition back to LP.

0 Likes
RodolfoGL
Employee

There is another change required in the code example.

When defining the cy_stc_syspm_callback_t structures, there is a variable that tells which events to skip. The ClkExitUlpCb should be set like this:

    cy_stc_syspm_callback_t ClkExitUlpCb = {Clock_ExitUltraLowPowerCallback, /* Callback function */

    CY_SYSPM_LP,                /* Callback type */

                                            CY_SYSPM_SKIP_CHECK_READY |

                                            CY_SYSPM_SKIP_CHECK_FAIL |

                                            CY_SYSPM_SKIP_BEFORE_TRANSITION,  /* Skip mode */

&callbackParams,                /* Callback params */

                                            NULL, NULL};                    /* For internal usage */

0 Likes
joco_4017211
New Contributor

RodolfoG_11 wrote:

There is another change required in the code example.

When defining the cy_stc_syspm_callback_t structures, there is a variable that tells which events to skip. The ClkExitUlpCb should be set like this:

    cy_stc_syspm_callback_t ClkExitUlpCb = {Clock_ExitUltraLowPowerCallback, /* Callback function */

    CY_SYSPM_LP,                /* Callback type */

                                            CY_SYSPM_SKIP_CHECK_READY |

                                            CY_SYSPM_SKIP_CHECK_FAIL |

                                            CY_SYSPM_SKIP_BEFORE_TRANSITION,  /* Skip mode */

&callbackParams,                /* Callback params */

                                            NULL, NULL};                    /* For internal usage */

Hmm that seems to have made things worse.  Now after exiting ULP the power usage becomes super spikey.  In the capture below, we start in LP, go to ULP and then back to LP which starts all the spiky power.  I then go back to ULP to make sure the device is still responding and back to LP.

The 2nd graph shows the spikey power zoomed in.

Note: I am using the Buck converter.

CE219881_ULP_bug3.PNG

Here is my main_cm4.c if you need to look at it. main_cm4.c - Pastebin.com

0 Likes
RodolfoGL
Employee

If you check the average current, it should be the same after you reset and after you re-enter to LP mode. That's what the fix is about.

It seems these spikes are related to the LED blinking. You can either remove the LED blinking and see if this goes away. You can also use the LDO and see the behavior. Maybe the SIMO Buck can't drive that much of current.

0 Likes
joco_4017211
New Contributor

RodolfoG_11 wrote:

If you check the average current, it should be the same after you reset and after you re-enter to LP mode. That's what the fix is about.

It seems these spikes are related to the LED blinking. You can either remove the LED blinking and see if this goes away. You can also use the LDO and see the behavior. Maybe the SIMO Buck can't drive that much of current.

Average after reset is 3.709mA and after ULP is 3.097mA.

The LED was blinking after reset as well and it wasn't spiking...  As far as my measurements have show up to this point, I'm not measuring the LED power usage.

I will check the LDO and see if it behaves differently but the pioneer kit is not setup to drive the LEDs, it mearly grounds them.  Does the Buck converter effect the gpio's sink current? I wouldn't think so.

0 Likes
RodolfoGL
Employee

Your measurements are odd. I'm seeing 3.7 mA after reset and 1.60 mA after entering ULP. When returning to LP, I still see 3.7 mA.

I would suggest to try another board. Maybe it is an hardware issue.

0 Likes
joco_4017211
New Contributor

Could you attach your modified CE219881 example incase I've mistyped something?

0 Likes
RodolfoGL
Employee

Here we go.

0 Likes
joco_4017211
New Contributor

Switching to your copy fixed the issue.  There were also some changes to clock dividers.

$ diff -bu /data/main_cm4.c /data/main_cm4_update.c

--- /data/main_cm4.c    2019-02-07 16:07:01.422591000 -0500

+++ /data/main_cm4_update.c    2019-02-07 17:30:48.361663791 -0500

@@ -1,6 +1,6 @@

/***************************************************************************//**

* \file main.c

-* \version 1.20

+* \version 1.30

*

* \brief

* Objective:

@@ -15,7 +15,7 @@

*

********************************************************************************

* \copyright

-* Copyright 2017-2018, Cypress Semiconductor Corporation. All rights reserved.

+* Copyright 2017-2019, Cypress Semiconductor Corporation. All rights reserved.

* You may use this file only in accordance with the license, terms, conditions,

* disclaimers, and limitations in the end user license agreement accompanying

* the software package with which this file was provided.

@@ -483,8 +483,8 @@

             /* Re-enable the FLL */

             Cy_SysClk_FllEnable(FLL_CLOCK_TIMEOUT);

-            /* Set Peri Clock Divider to 1u, to keep at 50 MHz */

-            Cy_SysClk_ClkPeriSetDivider(1u);

+            /* Set Peri Clock Divider to 0u, to keep at 50 MHz */

+            Cy_SysClk_ClkPeriSetDivider(0u);

             retVal = CY_SYSPM_SUCCESS;

             break;

@@ -514,8 +514,8 @@

     switch (mode)

     {

         case CY_SYSPM_AFTER_TRANSITION:

-            /* Set Peri Clock Divider to 2u, to keep at 50 MHz */

-            Cy_SysClk_ClkPeriSetDivider(2u);

+            /* Set Peri Clock Divider to 1u, to keep at 50 MHz */

+            Cy_SysClk_ClkPeriSetDivider(1u);

             /* Disable the FLL */

             Cy_SysClk_FllDisable();

Note: You guys should add a diff syntax highlighter

0 Likes
Top labels