MSP430FR2633: Inactivity timeout

Hi Rei,

thanks for reaching out to the forum.

I would first ask for some additional info:

Which sample code are you referring too?

What is the delay you would like to have? Why do you set the parameter to 1000?

What is the active mode scan rate?

the "inactivity timeout" is defined in the Tech Guide. Please check that in our documentation.

"Inactivity timeout is the time the CPU continues to scan all the sensors after there is no proximity detection. At the end of the timeout, the MCU re-enters the ultra-low power wake on proximity mode. The timeout period is based on the “Active scan rate” times the “Inactivity Timeout” value."

The default value for this parameter is 32 samples, that means the CPU stays active 32 samples after wake on proximity detection before going back to LPM.

The regular scan in wake on proximity mode is done without involvement of the CPU. Increasing the inactivity time will increase the time the CPU is active and consequently consuming more power.

To question 2, yes the inactivity timeout apply to wake on proximity. It is related to the sensor chosen in the GUI to be used for the proximity sensing.

I hope I understood correctly your question and my answer helps to clarify.

Please feel free to contact the forum if you have additional questions.

Best regards

Kostas

Hi Kostas,

I checked the documentation.
Customers hope to wake up with "Wake on Proximity" and stay active for about 10sec.
Therefore, they set "Inactivity timeout" to 10000 as test. (Active scan rate = 33.)

I understood that this setting consumes more current for 10 seconds after "Wake on Proximity".

Now their issue is "Wake up interval".
Since "Wake up interval" is a regular calibration, I think thatCPU will be active periodically. It seems that the CPU that should sleep after calibration waits for "Inactivity timeout" and the current consumption increases.

Their hope is that CPU sleep immediately after calibrating . (when Inactivity timeout = 10000)

Regards, Rei

Hi Rei,

I think we can find a solution. I will come back to you on that the next days.

regards

Kostas

Hi Kostas,

Thank you as always. I'm waiting for your update.

Regards, Rei

Hi Rei,

I will be out the next days, therefore here a short proposal how this could work.

When exit the WoP on a regular wake up for calibration (g_bConvCounterFlag=true) the request is to have a shorter (g_ui16UISessionTimeoutCtr) time in active mode and not the long inactivity time.

In the CAPT_App.c please modify the following

.............

        case eUIWakeOnProx:
#if (CAPT_WAKEONPROX_ENABLE==true)
            if (g_bDetectionFlag || g_bConvCounterFlag || g_bMaxCountErrorFlag)
            {
                //
                // If a detection, conversion counter, or max count error flag was set,
                // stop autonomous mode and reload an active session
                CAPT_stopWakeOnProxMode(&CAPT_WAKEONPROX_SENSOR, 0);

// ==> add here:

if the wake up is not caused by the (g_bDetectionFlag) and not by the  (g_bMaxCountErrorFlag)

and the (g_bConvCounterFlag) is set, than

set the (g_ui16UISessionTimeoutCtr)= small value (e.g. 10);

else set to    (g_ui16UISessionTimeoutCtr) = g_uiApp.ui16InactivityTimeout as is set already.

                g_bDetectionFlag = false;
                g_bConvCounterFlag = false;
                g_bMaxCountErrorFlag = false;
                g_uiApp.state = eUIActive;
//                g_ui16UISessionTimeoutCtr = g_uiApp.ui16InactivityTimeout;
=========================

Here a simple implementation:

                if (!g_bDetectionFlag)
                {
                    if (!g_bMaxCountErrorFlag)
                    {
                        if (g_bConvCounterFlag)
                            g_ui16UISessionTimeoutCtr=10;
                        else
                            g_ui16UISessionTimeoutCtr = g_uiApp.ui16InactivityTimeout;
                    }
                }
                else
                    g_ui16UISessionTimeoutCtr = g_uiApp.ui16InactivityTimeout;

If the wake up is caused due to the ConvCounterFlag, the SessionTimeout will be short, if it is caused by any of the other events, will remain the same as defined by the InactivityTimeout.

  I have done some basic test and it seems to work.

Further info and an example can be found the end of this chapter

Please let me know if that proposal solves your issue.

Thanks

Regards

Kostas

Hi Kostas,

Thank you for your reply. Your explanation was easy to understand. I didn't know about custom of CAPT_App.c. This seems to be useful in various cases. I sent it to customers. I wait for customers reaction.
Thank you very much.

Regards, Rei