mDot sleep mode(s)

Home Forums mDot/xDot mDot sleep mode(s)

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #12063
    Michael
    Participant

    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 ago by Michael.
    #12067
    Jason Reiss
    Keymaster

    Update 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.

    #12068
    Michael
    Participant

    JR,

    Awesome, that worked!

    Is there a place where this output
    [INFO] entering sleep (stop) mode 00000037�
    is explained?

    Thanks,
    Mike

    #12069
    Mike Fiore
    Blocked

    Michael,

    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

    #12071
    Michael
    Participant

    Mike,

    Yes, and thanks.

    Is there documentation for the library that would explain this kind of output?

    Mike

    • This reply was modified 8 years ago by Michael.
    #12075
    Mike Fiore
    Blocked

    Michael,

    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

    #12164
    Michael
    Participant

    My 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
    Mike

    #12165
    Mike Fiore
    Blocked

    A 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

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.