mDot sleep problems

Home Forums mDot/xDot mDot sleep problems

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #22266
    Mark Makarychev
    Participant

    Hello.

    I’m having trouble putting my mDot to sleep/waking from sleep. I’m using code from the Dot-Examples project (dot-util files) in my own project, and none of the sleep functions from dot-util.cpp seem to work.

    I first tried sleep_wake_rtc_only (deepsleep = false, delay_s = 10) – sleep_save_io executes ok, but sleep_configure_io doesn’t seem to pass (controller just hangs and never gets to my debug comment after that line of code).

    Next I tried sleep_wake_rtc_or_interrupt – not only did it not wakeup after 10 seconds using RTC, but dot->setWakePin() doesn’t seem to work as well… getWakePin always returns DI8. For example:

    
    dot->setWakePin(XBEE_DIO7);  
    logInfo("interrupt on %s pin", mDot::pinName2Str(dot->getWakePin()).c_str());
    

    prints DI8 instead of DIO7. And using a PPS signal on DI8/DIO7 to try to wake the mDot from sleep also doesn’t work. In another topic I read that grounding PA_0 might help, but the code below seems to have no effect:

    
    DigitalOut wakePin(PA_0);
    wakePin = 0;
    sleep_wake_rtc_or_interrupt(sec, false);
    

    I’m out of ideas and didn’t find this problem on the forum, so I hope someone here can shed some light on this weird behavior.

    I’m using libmDot-mbed5 3.0.0 (revision 62:225e2dd) and mbed-os 5.4.7 (2996:fc18365). Also I have a Timer object that I use in my project’s main code – can this affect the RTC behavior?

    #22270
    Martin Pelletier
    Participant

    Hi Mark,
    your libmdot and mbed are correct!!

    i dont know if it could help you!!
    But my code here works…

    mDot* dot;
    Main()
    {
    static DigitalIn ATBIn(XBEE_CTS);
    InterruptIn event(XBEE_CTS);
    ATBIn.mode(PullDown);
    While (1)
    {
    dot->sleep(intervalSleep, mDot::RTC_ALARM_OR_INTERRUPT, false);
    //note: wake up on rising edge only
    }
    }

    Regards,
    Martin

    #22285
    Mark Makarychev
    Participant

    Hello Martin,
    I added the DigitalIn, InterruptIn, and .mode(PullDown) lines to my code, but the sleep/wake still doesn’t seem to work.

    #22286

    Hi Mark,

    Does the example code work for you when not integrated into your project?

    Have you tried the sleep API directly in your project?
    dot->sleep(delay_s, mDot::RTC_ALARM, deepsleep);

    The setWakePin() configures the pin and sets a variable then getWakePin() reads the variable back. Looks like you can query but not set. I don’t see an obvious reason why.

    Kind regards,
    Leon

    #22288
    Mark Makarychev
    Participant

    Hello Leon,

    The example code works fine on its own (both interrupt and RTC wake the mDot successfully), so the problem is not in the mDot itself. Calling the API directly from the main project acts the same as when calling it from mdotUtil (sleep not working, setWakePin not setting).

    It seems to be some bug that occurs when my project interacts with the API, but I can’t seem to find why it’s acting the way it is… I guess I’ll just have to continue thoroughly inspecting my code until I find the problem. Is there any commands or settings I can use to get feedback from the library? For example – what error codes are risen before the controller hangs, or what happens when I call setWakePin? Is TRACE the lowest level of logging available?

    Thanks,
    Mark.

    #22289
    Mark Makarychev
    Participant

    Whats even more interesting that it seems to sleep/wake just fine upon Join Error:

    [INFO] Configure radio for TX
    [WARNING] Radio Busy, cannot open Rx Window
    [ERROR] Failed to join network
    [ERROR] Failed to join network -4:Join Error
    [INFO] entering sleep (stop) mode 00000037
    ▒(here it wakes successfully!)
    [INFO] Send join request RxDelay: 0 Rx1Offset: 0 Rx2Freq: 869525000 Rx2Dr: 0
    [INFO] Configure radio for TX

    Although I can’t find “[INFO] entering sleep (stop) mode 00000037” anywhere, to see how it’s going into sleep – is this part of the mbed-os library?

    dot_util contains something close, but it’s obviously not what’s being printed (confused why I don’t see anything along the lines of “…until next free channel”)

    ret = dot->joinNetwork();
            if (ret != mDot::MDOT_OK) {
                logError("failed to join network %d:%s", ret, mDot::getReturnCodeString(ret).c_str());
                // in some frequency bands we need to wait until another channel is available before transmitting again
                uint32_t delay_s = (dot->getNextTxMs() / 1000) + 1;
                if (delay_s < 2) {
                    logInfo("waiting %lu s until next free channel", delay_s);
                    wait(delay_s);
                } else {
                    logInfo("sleeping %lu s until next free channel", delay_s);
                    dot->sleep(delay_s, mDot::RTC_ALARM, false);
                }
            }
    #22294
    Mark Makarychev
    Participant

    Never mind – found what was wrong!

    When I was updating the mDot library to V3.0.0 and all my code with it, I added the dot_util files as well (from the example), but only transferred the functions I thought I needed from them. But what I forgot is that my project doesn’t use the dot_util files anymore, as it uses its own “util” file. The “dot” in the dot_util file was not initialized (lacked the “mDot::getInstance(plan)” line), since it was being initialized and used in my other “util” file, and apparently a “dot” without an instance can successfully returns DI8 every time you call getWakePin!

    I guess this is another example of when not deleting old code can lead to hours of troubleshooting, ha ha!

    But as a side note – I’m still interested where the line ““[INFO] entering sleep (stop) mode 00000037” comes from in the message above…

    #22295

    Hi Mark,

    I’m happy to hear you figured it out.

    The “[INFO] entering sleep (stop) mode 00000037″ message comes from our library. More specifically it is in the code for the Dot object.

    Kind regards,
    Leon

    #22297
    Mark Makarychev
    Participant

    Oh, OK.
    Thanks!

    #22305
    Mark Makarychev
    Participant

    One more quick question, if you don’t mind. Time to time I get the following error on saving configurations for the mDot:

    [INFO] Saving configuration
    [ERROR] SPIFFS_write failed -10015

    This error also comes from the library – correct? What does it mean/what can be causing it? It doesn’t seem to affect how the mDot works (in any way I can see at least), but it doesn’t sound like something good (especially since SPIFFS probably stands for SPI Flash File System)…

    #22306

    Hi Mark,

    Here is the full set of SPIFFS responses and yes, it is the SPI flash file system.
    #define SPIFFS_OK 0
    #define SPIFFS_ERR_NOT_MOUNTED -10000
    #define SPIFFS_ERR_FULL -10001
    #define SPIFFS_ERR_NOT_FOUND -10002
    #define SPIFFS_ERR_END_OF_OBJECT -10003
    #define SPIFFS_ERR_DELETED -10004
    #define SPIFFS_ERR_NOT_FINALIZED -10005
    #define SPIFFS_ERR_NOT_INDEX -10006
    #define SPIFFS_ERR_OUT_OF_FILE_DESCS -10007
    #define SPIFFS_ERR_FILE_CLOSED -10008
    #define SPIFFS_ERR_FILE_DELETED -10009
    #define SPIFFS_ERR_BAD_DESCRIPTOR -10010
    #define SPIFFS_ERR_IS_INDEX -10011
    #define SPIFFS_ERR_IS_FREE -10012
    #define SPIFFS_ERR_INDEX_SPAN_MISMATCH -10013
    #define SPIFFS_ERR_DATA_SPAN_MISMATCH -10014
    #define SPIFFS_ERR_INDEX_REF_FREE -10015
    #define SPIFFS_ERR_INDEX_REF_LU -10016
    #define SPIFFS_ERR_INDEX_REF_INVALID -10017
    #define SPIFFS_ERR_INDEX_FREE -10018
    #define SPIFFS_ERR_INDEX_LU -10019
    #define SPIFFS_ERR_INDEX_INVALID -10020
    #define SPIFFS_ERR_NOT_WRITABLE -10021
    #define SPIFFS_ERR_NOT_READABLE -10022
    #define SPIFFS_ERR_INTERNAL -10050
    #define SPIFFS_ERR_TEST -10100

    With the library version you are using, if your code is accessing the SPI flash part from more than one thread, it can become corrupted and errors can occur. We have added a mutex to protect flash memory in cases where designers wish to access it from more than one thread. That support is in revision 113:53cb35474afb as listed at:
    https://os.mbed.com/teams/MultiTech/code/libmDot-dev-mbed5/shortlog/

    To recover your flash memory, I recommend you create support case via the support portal found at https://www.multitech.com/support/support. They will be able to provide what you need to erase and restore the flash memory.

    Kind regards,
    Leon

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