(CYW43907) powersave test app - verify that it is working as intended

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

cross mob
NiMc_1688136
Level 5
Level 5
10 sign-ins 50 questions asked 10 solutions authored

I want to verify that the powersave application in deepsleep is working as intended. I am using the CYW943907AEVAL1F eval board with the powersave test application with SDK 6.2.

The issue also occurs on the Arrow QuickSilverEval platform.

I have POWERSAVE_STANDALONE_TEST_DEEPSLEEP_NO_ASSOC set to 1, attempting to test deepsleep power levels.

The only modification I made to the application was to change to long sleep time from 120s to 30s.

I program the device then do a power cycle to the board.

I use the following build commands

testProjects.powersave-CYW943907AEVAL1F-ThreadX-NetX download run

testProjects.powersave-CYW943907AEVAL1F-FreeRTOS-LwIP download run

Both RTOS/IP stack combos behave similarly.

The board boots, waits for a few seconds, then enters a low power mode of 300uA for 30s, and then sits in some kind of high current state at 38mA for about 20 seconds before rebooting. Only the FreeRTOS build displays a cold boot and time since deep sleep message on wake (before rebooting).

ThreadX/NetX

Starting WICED vWiced_006.002.000.0072

Platform CYW943907AEVAL1F initialised

Started ThreadX v5.8

Initialising NetX v5.10_sp3

Creating Packet pools

WLAN MAC Address : A4:08:EA:D9:BA:8A

WLAN Firmware    : wl0: May 15 2018 19:39:17 version 7.15.168.114 (r689934) FWID 01-d6f88905

WLAN CLM         : API: 12.2 Data: 9.10.74 Compiler: 1.31.3 ClmImport: 1.36.3 Creation: 2018-05-15 19:33:15

>

*** Goes to sleep for ~30s and then enters a unknown 38mA state for 20s ****

Starting WICED vWiced_006.002.000.0072

Platform CYW943907AEVAL1F initialised

Started ThreadX v5.8

Initialising NetX v5.10_sp3

Creating Packet pools

WLAN MAC Address : A4:08:EA:D9:BA:8A

WLAN Firmware    : wl0: May 15 2018 19:39:17 version 7.15.168.114 (r689934) FWID 01-d6f88905

WLAN CLM         : API: 12.2 Data: 9.10.74 Compiler: 1.31.3 ClmImport: 1.36.3 Creation: 2018-05-15 19:33:15

>

FreeRTOS/lwIP

Starting WICED vWiced_006.002.000.0072

Platform CYW943907AEVAL1F initialised

Started FreeRTOS v10.0.1     (Custom)

Initialising LwIP v2.0.3

DHCP CLIENT hostname WICED IP

WLAN MAC Address : A4:08:EA:D9:BA:8A

WLAN Firmware    : wl0: May 15 2018 19:39:17 version 7.15.168.114 (r689934) FWID 01-d6f88905

WLAN CLM         : API: 12.2 Data: 9.10.74 Compiler: 1.31.3 ClmImport: 1.36.3 Creation: 2018-05-15 19:33:15

>

***** Goes to sleep at 300uA for 30s *********

COLD boot

BEACONS:

    before sleep: from BSS 0 from not BSS 0

    after  sleep: from BSS 0 from not BSS 0

    during sleep: from BSS 0 from not BSS 0

TIME since deep-sleep enter: 104509

***** Sits at 38mA for 20+seconds *********

Starting WICED vWiced_006.002.000.0072

Platform CYW943907AEVAL1F initialised

Started FreeRTOS v10.0.1

Initialising LwIP v2.0.3

DHCP CLIENT hostname WICED IP

WLAN MAC Address : A4:08:EA:D9:BA:8A

WLAN Firmware    : wl0: May 15 2018 19:39:17 version 7.15.168.114 (r689934) FWID 01-d6f88905

WLAN CLM         : API: 12.2 Data: 9.10.74 Compiler: 1.31.3 ClmImport: 1.36.3 Creation: 2018-05-15 19:33:15

>

***** Goes to sleep at 300uA for 30s *********

0 Likes
13 Replies
VikramR_26
Employee
Employee
25 sign-ins 10 sign-ins 10 comments on KBA

There is an issue with 6.2 SDK, we are working on the fix.

0 Likes

vikr wrote:

There is an issue with 6.2 SDK, we are working on the fix.

vikr

Can you elaborate a bit about the issue with 6.2 sdk?

I believe the 6.2 users want to check if their application has impacted by a know issue.

0 Likes

Hi,

we ran in the same issue. Powersave for the CYW943907AEVAL1F and CYW954907AEVAL1F seems severely broken,  ~40mAh is the lowest we can achieve.

When can we expect a fix for that bug?

-Tobias

VikramR_26 wrote:

There is an issue with 6.2 SDK, we are working on the fix.

It has been almost 1 year since you replied working on the issue.

Is this still an issue or is the fix available?

0 Likes

Is the issue fixed ?? any work around available for this issue ??

0 Likes

It is very disappointing, but the Release Notes for 6.4 state under Known Issues:

Known Issues:

     11. CYW943907AEVAL1F:APPS: snip/ ping_powersave app is not entering to low power mode

I am at awe how such a vital feature is not working for the 43907.

0 Likes
NiMc_1688136
Level 5
Level 5
10 sign-ins 50 questions asked 10 solutions authored

Yes vikr, it will be very helpful to know what the identified problem is and a potential work around.

I created a new application to try out sleep mode, based on information from the WICED Development Power Save System PDF (from the docs folder in SDK).

With my customized build using FreeRTOS v10 (changes from v9 ported over) I am seeing FreeRTOS calling platform_power_down_hook repeatedly during the time that the processor should be in sleep mode ( i placed a print statement in this function for testing).

If I change to the FreeRTOS v9 build, then the application just resets when the sleep time is over which doesnt seem right as this is sleep mode, not deep sleep.

void application_start( ) 

wiced_init(); 

platform_led_set_state(PLATFORM_GREEN_LED_INDEX, WICED_LED_OFF ); 

platform_led_set_state(PLATFORM_RED_LED_INDEX, WICED_LED_OFF ); 

 

 

connectivity_deinit(); 

while(1) 

platform_led_set_state(PLATFORM_GREEN_LED_INDEX, WICED_LED_OFF ); 

wiced_platform_mcu_enable_powersave(); 

wiced_rtos_delay_milliseconds(15000); 

wiced_platform_mcu_disable_powersave(); 

platform_led_set_state(PLATFORM_GREEN_LED_INDEX, WICED_LED_ON ); 

WPRINT_APP_INFO( ( "Hello\n" ) ); 

wiced_rtos_delay_milliseconds(5000); 

NAME := testSleep

APPLICATION_DCT    := application_dct.c

GLOBAL_DEFINES  += PLATFORM_POWERSAVE_DEFAULT=1

GLOBAL_DEFINES  += PLATFORM_WLAN_POWERSAVE_STATS=1

GLOBAL_DEFINES  += PLATFORM_MCU_POWERSAVE_MODE_INIT=PLATFORM_MCU_POWERSAVE_MODE_SLEEP

GLOBAL_DEFINES  += WICED_DEEP_SLEEP_SAVE_PACKETS_NUM=4

$(NAME)_COMPONENTS := utilities/wiced_log \

filesystems/wicedfs \

protocols/HTTP_client \

libraries/utilities/JSON_parser \

                      utilities/mini_printf

$(NAME)_SOURCES    := main.c

$(NAME)_INCLUDES   := . \

$(WICED_LIB)/filesystems/ota2 \

$(WICED_LIB)/utilities/wiced_log \

$(WICED_LIB)/utilities/mini_printf

WIFI_CONFIG_DCT_H := wifi_config_dct.h

0 Likes

vikr

When using the FreeRTOS v9 build, the reset is due to being trapped in an assert in FreeRTOS which causes a Watchdog reset

void vTaskStepTick( const TickType_t xTicksToJump )

{

/* Correct the tick count value after a period during which the tick

was suppressed.  Note this does *not* call the tick hook function for

each stepped tick. */

configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime );

xTickCount += xTicksToJump;

traceINCREASE_TICK_COUNT( xTicksToJump );

}

I made this modification because the xTickCount + xTicksToJump was always > xNextTaskUnblockTime by 1.

configASSERT( ( xTickCount + xTicksToJump - 1 ) <= xNextTaskUnblockTime );

xTickCount += xTicksToJump - 1;

The project runs but the application is not entering any low power modes. The current is 42mA, regardless of running or sleep, as views witgh a meter and a scope. 

0 Likes
WiCa_4496921
Level 1
Level 1

Howdy,

I can also report the same issue with WICED 6.4, FreeRTOS+LwIP (confirmed on both FreeRTOS 9.0 and 10.0) - MCU Low Power mode is broken.

Folks, this is a key function for many of us.  Unless I missed it, I am not aware of any workarounds - is Cypress actively resolving this? Or can anyone point us in the right direction for a workaround/resolution?

Cheers.

0 Likes

Hello,

  I have the same problem and had a fixing.

This is a bug when integrating FreeRTOS with deep sleep mode. FreeRTOS expect the slept ticks is less or equal to requested sleeping ticks(the assertion in portTASK_FUNCTION), but when calling platform_tick_sleep_common(in WICED/platform/MCU/BCM4390x/platform_tick.c), it always return slept ticks more than the request by 1, when in debug mode , it will cause assertion failed, when in non-debug mode, prvGetExpectedIdleTime will return a very large sleep ticks of 0xffffffff(xReturn = xNextTaskUnblockTime - xTickCount), which will cause the application sleeping a very long time and not going into deep sleep mode again.

one of Fixings ( in WICED/RTOS/FreeRTOS/ver9.0.0/Source/tasks.c)

  1. modify prvGetExpectedIdleTime, change statement of:

                      xReturn = xNextTaskUnblockTime - xTickCount;

            to

                    if(xNextTaskUnblockTime > xTickCount)

                    {

                           xReturn = xNextTaskUnblockTime - xTickCount;

                    } 

                   else

                   {

                        xReturn = 0;

                   }

   2. delete "configASSERT( xNextTaskUnblockTime >= xTickCount )" in function portTASK_FUNCTION( prvIdleTask, pvParameters )

You  can also modify platform_tick_sleep_common to make sure the returned slept ticks is less by 1.

0 Likes

Thanks @lili_4421586, that's quite helpful, I had shelved this all but might take a look again.

0 Likes

Thanks again,

I did try the patch above and it seemed to make a difference. However I ran into further time related issues and panics still. It seems we've not been able to get Cypress' attention on this very basic issue, which is disappointing to say the least.

Cypress Developer Community Feedback​, any chance someone from Cypress could at the very least reply here? (BTW none of my emails have gone answered either).

Regards,

Will.

0 Likes