mDot sleep mode(s)
Tagged: mDOt sleep reset
- This topic has 7 replies, 3 voices, and was last updated 9 years ago by
Mike Fiore.
-
AuthorPosts
-
April 11, 2016 at 9:34 am #12063
Michael
ParticipantI 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 9 years ago by
Michael.
April 11, 2016 at 9:48 am #12067Jason Reiss
KeymasterUpdate 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 #12068Michael
ParticipantJR,
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 Fiore
BlockedMichael,
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 #12071Michael
ParticipantMike,
Yes, and thanks.
Is there documentation for the library that would explain this kind of output?
Mike
-
This reply was modified 9 years ago by
Michael.
April 11, 2016 at 10:32 am #12075Mike Fiore
BlockedMichael,
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 #12164Michael
ParticipantMy 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 Fiore
BlockedA 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
-
This topic was modified 9 years ago by
-
AuthorPosts
- You must be logged in to reply to this topic.