• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 52 subscribers
  • Views 2251 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2541 in Deep Sleep (PM3) with Watchdog Timer

Hardik Madhu
Prodigy 195 points
Other Parts Discussed in Thread: CC2541

Hello,

We have a device built up on CC2541. Our device goes into sleep (Deep Sleep/PM3) for a very long time. When we want to connect, we wake it up (there is a push button for that) and connect it.

Now, the problem is that we want to use watchdog timer. So, when our device goes into sleep, the watchdog timer will reset our device so we are able to stay into sleep mode.

Can anyone suggest a possible solution for this problem.

Thanx in advance.

  • 0
    Intellectual 805 points

    I don't understand the question - are you asking how to use the watchdog timer in order to generate a wake from PM3? Or are you asking whether the watchdog timer, configured to generate a board reset say every 1-second if not pet, will then cause a wake from PM3 every 1-second, and thus consume an enormous (relatively) amount of power?

  • 0 in reply to codesmith
    Prodigy 195 points

    Hello codesmith,

    Thanks for response. Sorry there was a mistake in asking the question. Here is the modified question:

    We have a device built up on CC2541. Our device goes into sleep (Deep Sleep/PM3) for a very long time. When we want to connect, we wake it up (there is a push button for that) and connect it.

    Now, the problem is that we want to use watchdog timer. So, when our device goes into sleep, the watchdog timer will reset our device so our device is NOT able to stay into sleep mode.

    And from the two scenarios that you stated, my question is second one: 

    codesmith said:

    Or are you asking whether the watchdog timer, configured to generate a board reset say every 1-second if not pet, will then cause a wake from PM3 every 1-second, and thus consume an enormous (relatively) amount of power?

    Hardik

  • 0 in reply to Hardik Madhu
    Intellectual 805 points

    It looks like your question is answered by the data sheet, pg. 159:

    The Watchdog Timer consists of a 15-bit counter
    clocked by the 32-kHz clock source. Note that the contents of the 15-bit counter are not user-accessible.
    The contents of the 15-bit counter are retained during all power modes, and the Watchdog Timer
    continues counting when entering active mode again.

    Combine with information from pg. 64:

    32-kHz is off in PM3

    You will conclude that the Watchdog cannot possibly tick in PM3, but, "continues counting when entering active mode again."

  • 0 in reply to codesmith
    Prodigy 195 points

    Hey codesmith,

    Thanks for pointing it out.

    It was our mistake. A peripheral was waking it up, not the watchdog timer.

    Regards,

    Hardik

  • 0 in reply to Hardik Madhu
    Intellectual 805 points

    As a tangent to this thread, since I didn't see another thread more appropriate after a quick search (although there are threads on PM2), check this out:

    I have empirically proven that the CC2541 Watchdog, when enabled for a 1-second board reset, does not tick in PM2!

    This is great news for us, because we need the security of breaking out of brick mode with the Watchdog, but also need the capability of maintaining a RTC, which is impossible using PM3. And the PM2 power consumption is almost the same as PM3 wrt what we need.

  • 0 in reply to codesmith
    Mastermind 8695 points

    Where do you place the watchdog timer reset in the osal? Should it be scheduled as an App layer osal task event? That's my only thought and it feels wrong.

  • 0 in reply to Peter Borenstein
    Intellectual 805 points

    I put the watchdog pet as the lowest priority event of the lowest priority task, triggered by an osal_timer, which insures that all tasks are running and relinquishing in time to pet and not breaking the "cooperative" tasking system, that the osal_timer system is running on time (within the order of magnitude of the pet), and that osal_memory system is running (at least enough to be freeing and reallocating osal_timers). I put several other checks in the watchdog pet task event as well, failing any refuses to pet.