Wake from RTC alarm and interrupt

[Javier Pedrido]

Hi everyone,

I’m trying to wake my mdot from deep sleep from an interrupt (PA_0) and from RTC alarm. I’m using mdot 2.0.3, mbed-rtos 117, and mbed 121. Waking up from PA_0 works OK but the RTC alarm never wakes up the mdot. My code is:

int main() {
InterruptIn wake(PA_0);
mDot* dot = mDot::getInstance();
logInfo(“version: %s”, dot->getId().c_str());
dot->setLogLevel(mts::MTSLog::INFO_LEVEL);
dot->sleep(10, mDot::RTC_ALARM_OR_INTERRUPT);
return 0;
}

Am I doing something wrong?

Thanks in advance,
Javier

[Andrew Lindsay]

You dont need to define the InterruptIn pin.

[Javier Pedrido]

Thanks Andrew, but even if I remove that line still doesn’t wake up with RTC alarms.

[Javier Pedrido]

FYI, reverting to mbed 116 and keeping rtos 117, mdot 2.0.3, fixed this problem.

[Javier Pedrido]

Well, that combination broke p2p data transmission, I guess having wake on interrupt and rtc is not an option right now.

[Andrew Lindsay]

It seems that the version requirements are pretty specific. Previous versions of the library required mbed-rtos r110 otherwise join wouldnt work.

Multitech need to get their act together to produce a stable library.

Andrew

[Javier Pedrido]

Is there some documentation on what versions should be used with mdot 2.0.3?
Javier

[Mike Fiore]

Andrew,

I apologize for the inferior experience you’ve had. We have had to recommend specific versions of the mbed and mbed-rtos libraries due to bugs or serious changes in the mbed libraries. Those kinds of issues are more obvious because we can only release binary builds of the mDot library. We are working hard to improve the mDot library and keep it compatible with the latest mbed versions.

Cheers,

Mike

[Mike Fiore]

Javier,

Version 2.0.3 of the mDot library is compatible with mbed 121 and mbed-rtos 117.

Are you developing with your mDot in a UDK2 (approximately 4″ square white board) or a MDK (a little bigger than the mDot)?

Cheers,

Mike

[Javier Pedrido]

Mike, I’m using a MDK.

[Javier Pedrido]

FYI, If I use mDot::RTC_ALARM or mDot::INTERRUPT it works OK. The problem is just with mDot::RTC_ALARM_OR_INTERRUPT.

[Javier Pedrido]

Mike, did you manage to manage to reproduce this issue? Regards, Javier.

[Mike Fiore]

Javier,

Apologies for the slow response – I didn’t realize you had replied to my question.

I wrote up a simple app to test this situation using mbed 121, mbed-rtos 117, and libmDot 15. Here’s the contents of main:

#include "mbed.h"
#include "mDot.h"
#include "MTSLog.h"

int main()
{
    mDot* dot = mDot::getInstance();
    dot->setLogLevel(mts::MTSLog::INFO_LEVEL);
    logInfo("version: %s", dot->getId().c_str());
    dot->sleep(10, mDot::RTC_ALARM_OR_INTERRUPT);
    return 0;
}

I tested this on a mDot on my MDK. It woke up properly via the RTC alarm and a rising edge on PA_0.

A couple things to try:

It’s possible the RTC got put into a bad state if you programmed your mDot while it was sleeping. I have seen this happen before. To resolve it, completely remove power from the MDK/mDot (aka unplug the USB). Another way to prevent this from happening is to hold the device in reset while programming (hold the reset button until you’ve dragged and dropped the binary).

If you still have issues, you can open a support case at http://support.multitech.com.

Cheers,

Mike

[Mike Fiore]

Javier,

I just had another thought. It might be worthwhile to make sure there’s nothing wrong with the RTC on that mDot. Can you test on another mDot? Here’s the main for a simple app that will make sure the RTC is functioning properly.

#include "mbed.h"

int main() {
    printf("initializing RTC\r\n");
    // 1/3/2016 00:00:00 GMT - 1451779200
    set_time(1451779200);

    while (true) {
        printf("time %d\r\n", time(NULL));
        wait(1);
    }

    return 0;
}

Cheers,

Mike

[Javier Pedrido]

Mike, I will try that and I will let you know. Thanks for the help, Javier.

[Javier Pedrido]

Mike,

I have two mDots, I’ve installed your program, unplugged them, plugged them again and both failed to wake up from RTC, they just printed one time:

[INFO] mDot Ready
[INFO] version: 2.0.6-1-g3959fe1
[INFO] entering deepsleep (standby) mode 00000037

The result of the other test was:

time 1451779202
time 1451779203
time 1451779204
time 1451779205
time 1451779206
time 1451779207
time 1451779208
time 1451779209
time 1451779210
time 1451779211
time 1451779212
time 1451779213
time 1451779214
time 1451779215
time 1451779216
time 1451779217
time 1451779218
time 1451779219
time 1451779220
time 1451779221
time 1451779222
time 1451779223
time 1451779224
time 1451779225
time 1451779226
time 1451779227
time 1451779228

I’m openning a support case.

Javier

[Leon Lindenfelser]

Javier,

There is an errata with the STM32F411. The wake pin needs to be low upon going into standby mode. If the wake pin is in the wrong state (high), when entering standby mode, it will not wake. This is an issue only if both RTC and interrupt are enabled as wake up sources.
See secion 2.1.5
http://www.st.com/content/ccc/resource/technical/document/errata_sheet/0a/98/58/84/86/b6/47/a2/DM00037591.pdf/files/DM00037591.pdf/jcr:content/translations/en.DM00037591.pdf

Leon

[Javier Pedrido]

Leon, but I dont have anything connected to mdots when I do the tests and they were powered off before the tests.

Javier

[Javier Pedrido]

Hi, if I run the following program without anything connected and starting with a powered off mdot:

`DigitalIn wake(PA_0);
DigitalIn other(PA_7);
mDot* dot = mDot::getInstance();
dot->setLogLevel(mts::MTSLog::INFO_LEVEL);
logInfo(“version: %s”, dot->getId().c_str());

while (true) {
logInfo(“Hola %d %d”, wake.read(), other.read());
osDelay(2000);
}`

I get:

[INFO] mDot Ready
[INFO] version: 2.0.6-2-ge3d307b
[INFO] Hola 1 0
[INFO] Hola 1 0
[INFO] Hola 1 0
[INFO] Hola 1 0

Is it ok that PA_0 is allways 1?

Javier

[Leon Lindenfelser]

Javier,

PA_0 needs to be 0 not 1. That is the problem.

Leon

[Javier Pedrido]

Leon, so it’s hardware problem? Javier

[Leon Lindenfelser]

Javier,

It’s an errata on the processor with a simple work around. The errata for the processor states…
“The various wakeup sources are logically OR-ed in front of the rising-edge detector which generates the wakeup flag (WUF). The WUF needs to be cleared prior to Standby mode entry, otherwise the MCU wakes up immediately.
If one of the configured wakeup sources is kept high during the clearing of the WUF (by setting the CWUF bit), it may mask further wakeup events on the input of the edge detector. As a consequence, the MCU might not be able to wake up from Standby mode.”

So if the processor is configured to wake from, both RTC and the wake pin, then deepsleep/standby is initiated while the wake pin is already high, wake functionality will not work correctly.

To avoid this, make sure the wake pin is low when you enter deepsleep/standby. Wake it by raising the wake pin… or the RTC timer.

FYI: On the MDK, the wake pin is the RTS signal coming from the XR21V1410 chip. If you attach to the serial port and are manipulating RTS, you will see that RTS is logically inverted by the XR21V1410 chip.

Leon

[Javier Pedrido]

So, if I run the program without using the MDK and nothing attached to PA_0 will it wake from RTC? Is it possible to wake from deep sleep when attached to the MKD? I tried this and it didn’t wake up.

mDot* dot = mDot::getInstance();
dot->setLogLevel(mts::MTSLog::INFO_LEVEL);
logInfo(“version: %s”, dot->getId().c_str());

DigitalOut wake(PA_0);
logInfo(“Hola %d”, wake.read());
wake.write(0);
logInfo(“Hola %d”, wake.read());

dot->sleep(10, mDot::RTC_ALARM_OR_INTERRUPT);

Javier

[Leon Lindenfelser]

Javier,

Q: So, if I run the program without using the MDK and nothing attached to PA_0 will it wake from RTC?
A: As long as the wake pin is low(pulled down) when deepsleep/standby is entered.

Q: Is it possible to wake from deep sleep when attached to the MDK?
A: Yes, but you need to attach to the virtual serial port with RTS active so RTS is driven low from the XR21V1410 chip.

I like your code above where you read and output the state of the wake pin. I recommend you use that to make sure the wake pin is low before going into deep sleep… at least until you pass this hurdle.

Leon

[Javier Pedrido]

Thanks, Leo, I disconnected the MDK from the computer and connected it to a battery and It worked. I will try it connected to the computer with RTS active later (I don’t know how to do it 🙂 ).

Thanks again,
Javier

[Leon Lindenfelser]

When you plug the MDK with mdot into a computer, it should enumerate two ports. I’m assuming you are already using one of the two for communication to the mdot. The one that connects to the XR21V1410 is the one you need to control RTS on. If you are using Windows, you should see it in the device manager.

[Javier Pedrido]

Thanks, Leon, I also got it working connected to computer 🙂

[Leon Lindenfelser]

Fantastic, thanks for choosing MultiTech!

[Andrew Lindsay]

I’ve got some something that might be connected. I’m using the mDot::INTERRUPT and mDot::RTC_ALARM deep sleep options in the same application. The idea is that once it has been triggered and sends data, it uses the RTC_ALARM to sleep for 5 or 10 minutes before allowing itself to be woken again.
Once it wakes from deep sleep via the RTC it will sleep using INTERRUPT until it is triggered by the input.
What I am seeing is the mDot goes into deep sleep from the RTC_ALARM but can be immediately triggered by the input pin which is not what I’m expecting.

Is there something I’m doing wrong?

**UPDATE** After posting this, I notice it is not every time this happens. So, is there a reason the RTC_ALARM would not sleep properly. Is it due to a wrong state on the INTERRUPT input?

Thanks

Andrew

[Leon Lindenfelser]

Hi Andrew,
Please provide an app that we can run to duplicate this issue and let us know what version of mbed, mbed-rtos and libmDot you are using to build it. Also, are you building off line or on line?
Leon

[Author]

Posts