RTC_ALARM_OR_INTERRUPT wont wakeup after a while

Home Forums mDot/xDot RTC_ALARM_OR_INTERRUPT wont wakeup after a while

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #15150
    Andrew Lindsay
    Participant

    I’m using versions

    libmDot: 15:b50f92f
    mbed-rtos: 116
    mbed: 121

    I have an application that wakes up from deep sleep initially a few times based on either the interrupt or rtc. After more than an hour of inactivity it no longer wakes up on the timer or interrupt and must be reset to bring it back into service.
    Are there any restrictions on rtc times that would stop the wakeup working?

    thanks

    Andrew

    #15200
    Andrew Lindsay
    Participant
    #15208
    Andrew Lindsay
    Participant

    Further investigation on this issue, it looks like the device wont wake up once I disconnect the UDK dev board used to debug the device. Is there anything in the default UART configuration that could cause this to not wakeup?

    Thanks

    Andrew

    #15218
    Mike Fiore
    Blocked

    Andrew,

    Can you clarify exactly what “disconnect the UDK dev board” means? Are you disconnecting a serial cable or the micro USB cable or something else?

    Also, is your UDK dev board populated with the Dragonfly 40-pin connector and the SMC headers or just the mDot header? The UDK with only the mDot header is powered from the micro USB port while fully populated model is powered via the J3 power connector.

    Cheers,

    Mike

    #15227
    Andrew Lindsay
    Participant

    Hi Mike,

    I have a board with the mDot on it, this includes a programming header which is effectively connected to the programming header on the mDot. The board received no power from the UDK as it has its own power source. The UDK is linked to my board via a short cable connecting the UDK programming header to the header on the board.
    I am able to program mDot this way as if it was plugged into the UDK.

    I have an application that uses both the Interrupt wake up and the interrupt/rtc wakeup from deep sleep.
    There is also the scenario where the RTC only wakeup is disable the wakeup pin for a number of minutes.

    The device wakes up, checks if it was woken up by the timer or interrupt, if timer, checks if its time to send a heartbeat message then either sends a message or not. It then goes to deep sleep waiting for either the RTC or Interrupt with a 10 minutes sleep.

    If it’s woken up via the interrupt then it sends a message and goes to deep sleep with RTC wakeup only after 10 minutes.

    This all works fine while connected to the UDK with a serial monitor looking at the output. As soon as the cable between the two boards has been disconnected the mDot refuses to wake and is shown by not receiving any messages when it supposed to wakeup.

    The only way to get it back to life is to press a reset button on my board. If I have then reconnected the cable to the UDK it then starts to send debug messages as normal.
    I can also tell that it has not woken up in the meantime because there is a record of the last time it sent a message based on the RTC and a sequence number that is incremented each time a message is sent.

    Any ideas? I’m going to try to put together a simple example to try to narrow down where the problem could lie.

    thanks

    Andrew

    #15230

    Andrew,

    Is the wake pin floating or pulled low? It should be pulled low with a rising edge used to wake the mDot.

    Leon

    #15233

    Andrew,

    This will provide better clarity about what I thought might possibly be the issue you are seeing.
    http://www.multitech.net/developer/forums/topic/wake-from-rtc-alarm-and-interrupt/#post-14638
    See the entry on date August 30, 2016 at 1:36 pm.

    Leon

    #15285
    Andrew Lindsay
    Participant

    Sorted it now. I did have a pull-up on the input instead of a pull-down. Fixed now and working correctly.

    Thanks

    Andrew

    #15286

    Good deal. We appreciate your input an involvement!

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