• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 53 subscribers
  • Views 2656 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to enter Power mode 1 in CC2540 (urgent)?

Micfox Micfox
Prodigy 240 points

This question has been asked but there is not workable solution to it.  Therefore, I need to ask it again:

I am developing my own application based on the Keyfob-demo project.   It  is expected that the keyfob (peripheral) is supposed to measure the RSSI between the master and itself after a given period of sampling time. During the sampling time, the keyfob should go into sleep ( power mode 1 is sufficient but if it can go into the power mode 2, it would be better). I have the following codes for the rssi sampling section ( it was in a event handling process. The flag value for this event  is KFD_RSSI_READ_EVT_T):

.....

  rssi_sampling_counter = 0;
      uint16 simpleBLEConnHandle;
      
      //halSleep(10);
    
    GAPRole_GetParameter(GAPROLE_CONNHANDLE,&simpleBLEConnHandle);

     HCI_ReadRssiCmd(simpleBLEConnHandle );
     
       #if defined ( POWER_SAVING )
        osal_pwrmgr_device( PWRMGR_BATTERY );
      #endif
     
         osal_stop_timerEx( keyfobapp_TaskID,  KFD_START_DEVICE_EVT);
        osal_stop_timerEx( keyfobapp_TaskID,KFD_BATTERY_CHECK_EVT);
        osal_stop_timerEx( keyfobapp_TaskID, KFD_ACCEL_READ_EVT);
        osal_stop_timerEx( keyfobapp_TaskID, KFD_TOGGLE_BUZZER_EVT);
        osal_stop_timerEx( keyfobapp_TaskID, KFD_ADV_IN_CONNECTION_EVT);
        osal_stop_timerEx( keyfobapp_TaskID, KFD_PERIODIC_EVT);
        osal_stop_timerEx( keyfobapp_TaskID, KFD_RSSI_READ_EVT_T);
        osal_stop_timerEx( keyfobapp_TaskID, KFD_BUTTON_EVT);
   
     
     
     
          halSleep(10);
     
   osal_start_timerEx(keyfobapp_TaskID,KFD_RSSI_READ_EVT_T, rssi_sampling_period);

.....

I have tried to terminate all the timer evenst in the keyfob demo application layer except the rssi sampling one before it goes into sleep. However,  there is still some peaks showing up in every 200 - 300 ms according to the oscilloscope graph. I read the past threads on this issue and some users suggested that the keyfob can only go to sleep where there is no active tasks on-hold. But in my case, the RSSI sampling timer cannot be stopped, right? Otherwise, how can the keyfob knows when to measure the rssi value?  So does it mean the keyfob can never go into the power mode 1 in my case? I am deperately looking for help on this issue. Please advise and I will appreciate any constructive response to my urgent request. Thanks.

  • 0
    Prodigy 240 points

    additionally, I have turned on the POWER_SAVING macro in the compiling environment  to enable the power saving functions.  But it still cannot enter the power mode 1. Please advise.

  • 0
    Guru 31280 points

    Hi,

    1. What is the value of rssi_sampling_period
    2. For debugging purposes, can you disable KFD_RSSI_READ_EVT_T scheduling
      and check whether you still getting these peaks on oscope? 
  • 0 in reply to Igor Sherer
    Prodigy 240 points

    question 1 - it depends on what the master set. It is changed in the test. Currently, it is 10 seconds.

    question 2 - I have commented that line. I still get those peaks at the period of 100 ms.

    I wonder if there is anything running underneath about the rssi sampling for those peaks on the oscilloscope?

  • 0 in reply to Igor Sherer
    Prodigy 240 points

    I use the following macro to force the node into the power mode 2. However, it will make the connection drop:

    In hal_sleep.h:

    #define HAL_SLEEP_SET_POWER_MODE( mode )                                       \
      st( SLEEPCMD &= ~PMODE;                                                      \
          SLEEPCMD |= (mode);                                                      \
          while (!(STLOAD & LDRDY));                                               \
          {                                                                        \
            halSetSleepMode();                                                     \
          }                                                                        \
        )
    #else // HAL_SLEEP_DEBUG_POWER_MODE

    // Debug: Don't set power mode, just block until sleep timer interrupt.
    #define HAL_SLEEP_SET_POWER_MODE( mode )                                       \
      st( while( halSleepInt == FALSE );                                           \
          halSleepInt = FALSE;                                                     \
        )

    #endif // !HAL_SLEEP_DEBUG_POWER_MODE

    Then in the  function  - static void peripheralStateNotificationCB( gaprole_States_t newState )

    static void peripheralStateNotificationCB( gaprole_States_t newState )

    {

    .....
      if ( gapProfileState != newState )
      {
        switch( newState )

     {

        case GAPROLE_STARTED:

    ....

    case GAPROLE_CONNECTED:

     #if defined ( POWER_SAVING )
            osal_pwrmgr_device( PWRMGR_BATTERY );
             osal_pwrmgr_powerconserve();
          #endif
                   
            //  ProxReporter_SetParameter(PP_FLIGHT_MODE_NOTIFICATION,sizeof(uint8), &flight_mode_enabled);

            osal_stop_timerEx( keyfobapp_TaskID,  KFD_START_DEVICE_EVT);
            osal_stop_timerEx( keyfobapp_TaskID,KFD_BATTERY_CHECK_EVT);
            osal_stop_timerEx( keyfobapp_TaskID, KFD_ACCEL_READ_EVT);
            osal_stop_timerEx( keyfobapp_TaskID, KFD_TOGGLE_BUZZER_EVT);
            osal_stop_timerEx( keyfobapp_TaskID, KFD_ADV_IN_CONNECTION_EVT);
            osal_stop_timerEx( keyfobapp_TaskID, KFD_PERIODIC_EVT);
            osal_stop_timerEx( keyfobapp_TaskID, KFD_RSSI_READ_EVT_T);
            osal_stop_timerEx( keyfobapp_TaskID, KFD_BUTTON_EVT);
            /*
              if (gapProfileState ==GAPROLE_CONNECTED)
            {
                     halSleep(100);
              GAPRole_TerminateConnection();
      //        putchar ('t');
            }
            */
             
             
            halSleep(1000);
                   
                   
      HAL_SLEEP_SET_POWER_MODE( HAL_SLEEP_TIMER  );

    osal_start_timerEx(keyfobapp_TaskID,KFD_RSSI_READ_EVT_T, rssi_sampling);
       
      

    }

    ....

    }

    My question is simple - Please advise whether the bluetooth connection can be held or not when the keyfob (slave) goes to  the power mode 2???

    If yes, please advise why the connection is broken. If no, please advise how to get the button press interrupt (on the keyfob) to trigger the reconnection. Thanks.

  • 0 in reply to Micfox Micfox
    Prodigy 240 points

    Please advise... I need the power mode 2 workable urgently.  The TI staff asked me to post my question on the TI forum but actually no TI staff  is answering it???

  • 0 in reply to Micfox Micfox
    Intellectual 400 points

    Welcome to the real world!!

    I hope you have worked out the problem you had with your design.
    (Jesus, you posted this "Aug 12, 2012 6:03 AM" ages ago!!! and still no response from anyone!!!)

    It's clear that we (developers) are seen as a SURE THING.. In other words, captured audience. We have bought the Dev-tools and a copy of IAR IDE (probably evaluation kits too) and they already have our money banked. Now you have a problem, they don't want to know. If you need help, you must explain exactly what it is through a post here and wait until they can be bothered to reply. And it is not just TI staff at fault since we're using (the only available) IAR Compiler, IAR staff should be here to support us too but any IAR staff who might be here is here to gather information so that they can go fix the bugs in the IAR-IDE.... 

    This whole BLE development with TI's CC254x products is monopolized by these two companies TI and IAR and when things go wrong, it is the developers problem!!!

    If you are unfortunate enough not to come across a post by someone else who has experienced the same problem as you have then you are probably better off searching the Internet for answers as Google often returns more hits than you are ever likely to find here.  GitHub for example.

    I have given up posting stuff around here. Yes, I come back time and time again but only to search for existing articles relating to issues I might have, however in general, they have our cash and we are on your own... Next time, I suggest you do your research and if the product is monopolized then stay well clear!! That's what I have learned from my experience of developing with TI BLE products. 

  • 0 in reply to Joe Bloggs
    TI__Mastermind 34660 points
    Hello all. To summarize power management, it is essentially handled by stack in the main processing loop (osal_run_system()):

    #if defined( POWER_SAVING )
    else // Complete pass through all task events with no activity?
    {
    osal_pwrmgr_powerconserve(); // Put the processor/system into sleep
    }
    #endif

    This means that all you have to do to enable power management is to enable the POWER_MANAGEMENT preprocessor define.

    The stack will take care of what power mode is entered in the following manner:
    - if there is less than 2 ms before the next scheduled wakeup (osal event or BLE event), the device will not go to sleep since this is not power efficient
    - if there is more than 2 ms before the next schedule wakeup and there are any active BLE events (connection / advertising), the device will go to PM2
    - if there is more than 2 ms before the next wakeup and there no active BLE events, the device will go into PM3

    Therefore, in your code, I would recommend removing any calls to hal_sleep or anything else meant to modify the power management. You should just allow the stack to handle it.

    To answer some questions from this thread...
    - the peaks you are seeing may correspond to the BLE connection events (assuming you are in a connection since you are trying to calculate an RSSI)
    - yes, a connection can stay up in PM2

    Also, to respond to Joe...
    Thank you for reviving this thread. I'm sorry it wasn't answered in the past. In the past year, we have been devoting significantly more time to E2E and actually have a very high response and answer rate at this time. Again, I'm sorry it wasn't this way in the past. Please feel free to PM me with any open questions you have and I will try to resolve them as soon as possible.