CC3200MOD: Debugging device failing entertry into sleep

Aaron,

Thanks for your advice, I am excited to try your suggestion. 

But I'm not sure where to put it.  I do not see that function called anywhere in the RTOS idle_profile example, it only appears in idle_profile_nonos.  Seems like the RTOS project uses "lp3p0_pm_ops->set_up_wkup_srcs = cc_set_up_wkup_srcs;"

Where do you suggest I put this line?  Is it okay to simply call it once after platform_init()?

-Jon

I've gone ahead and put Aaron's suggested line into my code, just after platform_init, and it seems to be a great fix.  I've had a test running for about 12 hours, and not only does it look like device has remained in low power state, but I have not seen any disconnects (before adding this line I'd see at least 1 disconnect/reconnect every hour).

Thanks Again Aaron.  If you have any thoughts on why this line has improved connection stability of my device I'd be interested to hear it.

-Jon

Aaron,

It looks like I talked too soon in thinking this issue was solved. Although that 21 hour test showed promising results, I have run further testing and have found the issue still remains.

It's interesting to note that this always seems to correlate with a "[WLAN EVENT]Device disconnected" and "[WLAN EVENT] STA Connected".  I have seen device go through this disconnect/reconnect and still return to low power, so it's not a direct correlation.  But once it stops entering sleep, it does not enter sleep again until processor is reset.  Also, I should mention that every time this disconnect/reconnect happens, when I reconnect with AWS I find a "[SOCK ERROR] -close socket (83) operation remote side down from secure to unsecure". (83 is not always 83, but is within range 80-86).  This does not seem to affect device operation, but I'm not sure if it could be contributing to intermittent low power operation or not.

Do you have any other thoughts on what this may be?
Is there any reason I should have to call the WakeupSourceEnable function multiple times?
Should I go back to the original idea of modifying middleware to add debug messages to help figure out what is prevent device from entering sleep?

I look forward to your advice,
-Jon

Aaron, can you clarify what you mean by message poll loop?  I'm not sure what layer of the application you're referring to, I'd greatly appreciate if you can refer to specific function calls/API.

Thank you,
-Jon

Aaron,

We are using AP mode for part of the application, and I understand that requires more power.  But the test I'm performing is only using STA mode, as that is where device will spend the majority of its time.  I am positive that the device isn't switching to AP mode during my testing.

When I test my code on the Launchpad, I find <1mA when operating normally in STA mode.  When the issue occurs, I find ~10mA.  When I switch to AP mode, I find about 63mA.  (Note all these numbers refer to base current, not including current spikes).

Is there any polling and/or debug prints I can put into my code to help us figure out the root cause of why the device won't go back to sleep after disconnect/reconnect?

-Jon

Yes, I have run the idle_profile example, but it never seems to experience the random disconnect/connects.  I've been running a test since your message yesterday and have not seen any disconnects and current remains low.

I'd really like to add some debug messages into my code to help us understand the issue and/or show you additional code that might help uncover the issue.  Do you have any thoughts?

-Jon

If you are not using the OS version, you manually should re-enter LPDS in your main loop when execution resumes from a wake event (e.g disconnect or connect event)

I don't understand your response here.  I'm using FreeRTOS just as idle_profile does. 

Just as in idle_profile example, my call to go to sleep looks like this:
void vApplicationIdleHook( void )
{
    cc_idle_task_pm();
}

It's worth noting that I have used test code to prove when the issue occurs this code is still being executed.  This shows it is something within cc_idle_task_pm that is not letting processor go to full LPDS.

-Jon