- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 *********
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is an issue with 6.2 SDK, we are working on the fix.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is the issue fixed ?? any work around available for this issue ??
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 );
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
{
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks @lili_4421586, that's quite helpful, I had shelved this all but might take a look again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.