8 Replies Latest reply on Jun 13, 2014 7:00 AM by GregG_16

    Keeping power usage to a minimum

      I am using the ISM (invateck) module with the 32kHz change to have the module/cpu put into its lowest power mode possible.  But it seems to wake up from that mode quite often.


      I am using ThreadX and NetDuo.


      At the time this is happening, the device is connected to an WiFi AP and assigned an IP address via DHCP.


      Here is the code that is functioning, with the caveat that there is a thread waiting for a UDP packet to be received.




                          BoardSleep();   //power down other board peripherals (control FPGA, SD media, TFT & backlight)








                              wiced_gpio_output_high( WICED_LED1 );






                                  if((hook_run1 = wiced_network_suspend())==WICED_SUCCESS)




                                      time = platform_power_down_hook((sleeptime=(time_left>SLEEP_TIME?SLEEP_TIME:time_left)));










                              if(hook_run!=WICED_SUCCESS || hook_run1!=WICED_SUCCESS)




                                  WPRINT_APP_INFO( ( "pd_hook not run %#x %#x %#x


      ",hook_run,hook_run1,Awakened) );








                                  WPRINT_APP_INFO(("timer said %ld of %ld with timeleft of %ld %#x






                              time_left = CheckRunKeepAlive(hook_run==WICED_SUCCESS?time:0);


                              wiced_rtos_delay_milliseconds(SLOP_TIME);   //let other stuff run


                          }while(Awakened==0 && (state==new_state));








                          WakeUp();       //power up and init other board peripherals



      Awakened gets set to a non-zero if the thread that is receiving the UDP packet finds something interesting.  SLEEP_TIME is 9995 and SLOP_TIME is 5.


      The problem Im getting is that the power_down_platform_hook is not running for very long (mostly).  When it is running, I have a current of 2.1mA (which is still to high, but I may not have every IO in the appropriate state).  Every 60 seconds, the device sends out a Im here announcement (CheckRunKeepAlive).


      Here is a serial dump during this time.


      timer said 663 of 9995 with timeleft of 60000 0


      timer said 1212 of 9995 with timeleft of 59325 0


      timer said 1008 of 9995 with timeleft of 58100 0


      timer said 188 of 9995 with timeleft of 57079 0


      timer said 395 of 9995 with timeleft of 56878 0


      timer said 190 of 9995 with timeleft of 56470 0


      timer said 188 of 9995 with timeleft of 56267 0


      timer said 395 of 9995 with timeleft of 56065 0


      timer said 190 of 9995 with timeleft of 55656 0


      timer said 1005 of 9995 with timeleft of 55453 0


      timer said 393 of 9995 with timeleft of 54435 0


      timer said 802 of 9995 with timeleft of 54028 0


      timer said 1212 of 9995 with timeleft of 53212 0


      timer said 2440 of 9995 with timeleft of 51987 0


      timer said 2643 of 9995 with timeleft of 49533 0


      timer said 1212 of 9995 with timeleft of 46876 0


      timer said 1212 of 9995 with timeleft of 45650 0


      timer said 1212 of 9995 with timeleft of 44424 0


      timer said 5713 of 9995 with timeleft of 43198 0


      timer said 597 of 9995 with timeleft of 37470 0


      timer said 9751 of 9995 with timeleft of 36859 0


      timer said 3308 of 9995 with timeleft of 27089 0


      timer said 1416 of 9995 with timeleft of 23768 0


      timer said 2645 of 9995 with timeleft of 22338 0


      timer said 1416 of 9995 with timeleft of 19679 0


      timer said 4282 of 9995 with timeleft of 18249 0


      timer said 4081 of 9995 with timeleft of 13955 0


      timer said 5505 of 9861 with timeleft of 9861 0


      timer said 2032 of 4342 with timeleft of 4342 0


      timer said 2240 of 2297 with timeleft of 2297 0


      timer said 38 of 40 with timeleft of 40 0



      So as little as 188ms to as much as 9751ms suspend.  Since this is running on 4AA batteries, I need the suspend to be as long as possible and at the lowest current possible.



      How do I go about doing so?  Or am I doing as much as I can?
        • 1. Re: Keeping power usage to a minimum

          Your application should not be calling platform_power_down_hook(). This is done internally when there isn't any work to do done by any thread.

          Instead your application should call wiced_rtos_delay_milliseconds() for the time you want to sleep. The WICED code will determine the duration of time it can sleep before it needs to wake up and service a thread.

          • 2. Re: Keeping power usage to a minimum

            Thank you for your reply, but it's not quite what I'm looking for.  I need to make sure the system goes into it's lowest power consumption at this point, ie a wfi.  Doing a wiced_rtos_delay_milliseconds() is not necessarily going to do that.  Plus it will cause that thread to go away for at least the amount of time I request in the iced_rtos_delay_milliseconds(), instead of coming back as soon as something 'interesting' (see my first post) happens and can take action.  Also, one of the 'interesting' things is a button press that is on the WKUP pin, prompting an exit from a wfi that needs action taken ASAP. I can't seem to find a way to hook an exit from wfi without doing the platform_power_down_hook().

            If there is a way, could that be pointed out?

            And, I have to wonder if the platform_power_down_hook() wasn't meant to be called by user code, why it isn't documented as such.


            • 3. Re: Keeping power usage to a minimum

              When every thread is waiting or sleeping the idle thread will run which simply calls WFI causing the MCU to go to sleep.

              Instead of delaying for a number of milliseconds you can wait on a message queue and have the events that you are interested in post messages to that queue.

              All functions beginning with "platform_" are designed so they do not need to be called by any user application. They are used internally to abstract platform specific functionality from common WICED core code.

              I will follow up later with some guidance on how to create custom power down hooks.

              • 4. Re: Keeping power usage to a minimum

                I have tried implementing with a semaphore (I haven't tried yet with an event), but now when the power usage is at its lowest, it is at 3.8ma.  Switching off the semaphore and using the pd_hook, I get 3.0ma.  For a while I was getting 2.1ma with the same setup (same AP, same distance from AP, same number of devices on the AP, same password, etc.).  I don't know what's changed.  But the  wiced_rtos_get_semaphore using 0.8ma more is worrisome.  I'm running on 4AA batteries.  I need this even lower than the 2.1ma I was getting before.


                If I switch to using an event instead of semaphore, will that change power?  Is the order of wiced_wifi_enable_powersave & wiced_network_suspend done correctly, or do I have to NOT do one or both of them?


                Also, as I suspected, my button does not work, since it's tied to the WKUP pin, and WICED takes over that ISR.  Is there a way to insert my code into that ISR?  Or some other way that my code can notice that the WKUP pin has been tickled.


                And, a question has come up, does the module wake up (and wake up the processor) if it receives a broadcast from an AP it is not currently attached to?

                • 5. Re: Keeping power usage to a minimum

                  Can you run the the snip.ping_powersave app and see what kind of power usage you are getting at the lowest point?


                  Also, what instruments are you using and what is your test setup to measure the power usage?

                  • 6. Re: Keeping power usage to a minimum

                    Is this still an issue for you?

                    • 7. Re: Keeping power usage to a minimum

                      Yes, this is still an issue, but not in the same way.

                      By messing with the power_down_hook code, and installing something that would call my code on a wfi wakeup so I can check my button state, I am able to get my button to wake things up.


                      But with or WITHOUT that code in place, I now get other power problems.  We had current leakage on an other place on our board, taking an extra ~1ma (which is now fixed).  And the differences I saw between the 3.1 and 2.1 was whether or not the Olimex dongle was attached or not.  Now we have acceptable power draw at first.  But if the network drops connection (I get a notification from the wiced_network_register_link_callback) and I then do a wiced_network_down, then restart my network connection, the power usage is up by ~800na (if I can reconnect at all), about twice as much as it is at first connection.  If I reset the board, and go through the same reconnect code, it's back to the original power draw.


                      This is on both our (Rumble Dev) board and an Inventek eval board (ISM43362_M3G_L44).  There's an extensive amount of code involved, too big to post here.


                      Is there an example someplace that shows how to reconnect after a dropped connection?  I'm using WICED_STA_INTERFACE.

                      • 8. Re: Keeping power usage to a minimum

                        Not sure if its needed but if you need to attach a large file use the "Advanced Editor" (upper right corner).

                        Thank you for the additional info. We will let you know if we need any other information and see if we can help out.