mDot sleep mode(s)
Tagged: mDOt sleep reset
- This topic has 7 replies, 3 voices, and was last updated 8 years, 7 months ago by Mike Fiore.
-
AuthorPosts
-
April 11, 2016 at 9:34 am #12063MichaelParticipant
I tried presenting this on the mbed site, but it may be a mDot issue…
I’ve been experimenting with the example code mDot_DS18B20
https://developer.mbed.org/teams/Thing-Innovations/code/mDot_DS18B20/I’m trying to understand what the “sleep” mode is doing as called at the bottom of main.cpp.
I simplified the code and added a simple integer, count, into the outputted message. My code increments “count” so that each time the mDot transmits, a different value is sent. However, the Gateway always receives “count” as 0.
So, after some debugging, it appears that the “sleep” mode being entered causes the CPU to start from the beginning (reinitializing my count) as if being reset.
1) Is this true?
I tried experimenting with the s-called “deepsleep” value passed – here’s the prototype:
void sleep(const uint32_t& interval, const uint8_t& wakeup_mode = RTC_ALARM, const bool& deepsleep = true);
but it appears that no matter the value I pass for “deepsleep”- “no value” (therefore using the default), a value of ‘0’, or a value of ‘1’, the results are the same – the mDot resets and I lose my “count”.
Any help would be appreciated. Thanks.
Mike
- This topic was modified 8 years, 7 months ago by Michael.
April 11, 2016 at 9:48 am #12067Jason ReissKeymasterUpdate your libmDot library to the latest and pass false as “deepsleep” to enter the STM411 STOP mode which will preserve RAM and continue execution by returning from the sleep call.
The older library only had support for the deepsleep/STANDBY mode in which all RAM is lost and execution start when programs is reloaded.
April 11, 2016 at 10:01 am #12068MichaelParticipantJR,
Awesome, that worked!
Is there a place where this output
[INFO] entering sleep (stop) mode 00000037�
is explained?Thanks,
MikeApril 11, 2016 at 10:07 am #12069Mike FioreBlockedMichael,
I’m assuming you’re talking about the 00000037 part of that line. It’s just leftover debug logging – the value getting printed is the RTC->ISR register.
Cheers,
Mike
April 11, 2016 at 10:25 am #12071MichaelParticipantMike,
Yes, and thanks.
Is there documentation for the library that would explain this kind of output?
Mike
- This reply was modified 8 years, 7 months ago by Michael.
April 11, 2016 at 10:32 am #12075Mike FioreBlockedMichael,
I’m not sure I understand what you mean.
We don’t have any documentation that explains all of the logging coming out of the mDot library. We have tried, however, to make said logging understandable.
Can you clarify what you’re asking for?
Cheers,
Mike
April 15, 2016 at 11:41 am #12164MichaelParticipantMy previous post has as example (00000037�) of what I’m talking about; you identified as some kind of leftover stuff. How would a user know it’s only leftovers?
If you are saying the output is generally easily readable, I’ll accept that and move on.
Thanks
MikeApril 15, 2016 at 1:18 pm #12165Mike FioreBlockedA user wouldn’t know that information is leftovers unless they asked, I suppose.
Logging output should generally be easily readable. If you have any other questions about specific output, feel free to ask!
-Mike
-
AuthorPosts
- You must be logged in to reply to this topic.