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.

CC2531/TIMAC: Device reaches a dead-state when using osalApi_PowerMgr()

Other Parts Discussed in Thread: TIMAC, CC2531, Z-STACK


I'm having a problem with sleep mode with TIMAC Version 1.5.0 (May 09, 2013).

What my application does:
- activate WDT mode at 1s interval
- keep resetting WDT every 500ms
- go to low power mode using `osalApi_PowerMgr(TRUE)`
- keep sampling sensors (motion sensor) at 100ms interval
- send HF event packet on motion detection
- send HF alive packet every 30 minutes

My observations:
- normally, the device has 0,2-2mA (depending on sensors) in low power mode and I see peaks in the power consumption every 100ms (sampling) and 500ms (WDT reset)
- after 4-10 hours of operation, the device seems to be in dead-state...
  - stops showing those peaks
  - no reaction on sensors (motion), no HF event packet send
  - stops sending HF packet every 30 minutes
  - I see a flat current consumption around 0,2-2mA
  - the WDT does not pull a hardware RESET (could be off due to PM3, i.e. 32khz XOSC clock OFF??). Before dead-state, the WDT is active and working (tested by for(;;))
  - when hitting a button/switch (interrupt), the device continues with its normal operation  
- when adding `osal_pwrmgr_task_state(myTask , PWRMGR_HOLD)`, the device does not go into low power mode at all, and the dead-state does not occur
- when I activate UART-based debug output (seconds ticker), the dead-state does not occur   
 


 
My questions:
- what does the function osalApi_PowerMgr(TRUE) do exactly?
  - Does it activate PM2 or PM3?
  - does it deactivate tasks?
  - which idle intervall is nedded before going into lowPowerMode?
 

Thanks & best regards,

Timo

  • I forgot the most important question :
    How can I prevent the dead-state, i.e. how can I use a low-power-mode while still events like sampling and WDT timer reset are active?
  • You can define POWER_SAVING to make device enter sleeping mode automatically. There is no need to set WDT.
  • Dear YK Chen,
    I did not get your point.
    POWER_SAVING is defined, but I have to activate/deactivate lowPowerMode with osalApi_PowerMgr(), right?
    And, my application shall use the WDT. According to the userGuide of the CC2531, I have to activate the WDT and reset the timer within the WDT period in all power modes except PM3.
  • I miss one point. You have to set  "#define MSA_PWR_MGMT_ENABLED TRUE" in msa.h except define POWER_SAVING. For end device, if you define POWER_SAVING and define MSA_PWR_MGMT_ENABLED to TRUE, it would go to sleep automatically when there is no task to do in task queue.

  • Yes ok. I think what you are proposing is to use osalApi_PowerMgr(1) which I do.

    But, I do not have the problem that I can not activate the powermode. I'm using osalApi_PowerMgr() / osal_pwrmgr_device() from the TIMAC package and it seems to work, i.e. the device is powering down when I set the flag pwrmgr_attribute.pwrmgr_device by calling osalApi_PowerMgr().

    I have the problem that my device is dead after 1-10h of operation, and seems to be in powermode PM3. I assume it is PM3, because I can't see that the WDT-timer-reset-event is handled by looking at the power consumption on a scope, but the WDT does not pull the MCU's reset which is only the case in PM3, right?

    That's why I asked if the module OSAL_pwrMgr.c does anything like setting the device to PM3 if not events are upcoming.
    Or put in other words, can you think of any reason why OSAL puts my device in PM3?
    Do you have any idea what I can check to find the reason my device is in that dead-state?
  • Hello Timo D,

    In TIMAC OSAL implements a power management module which performs the task of determining when to put the device into sleep. To use this functionality you have to enable the compile option POWER_SAVING and also in the msa.h file "MSA_PWR_MGMT_ENABLED" should be set to "TRUE". After this OSAL will determine if its ok to enter sleep or not. Please refer to the document "Power Management for CC2530". Allthough this document mentions Z-Stack to illustrate how power management is implemented same principle is used in the TIMAC project as well. 

    So, you should not have to call the OSAL_pwrMgr API's to get device in to sleep mode. For TIMAC project you should just enable compile option POWER_SAVING and configure the MSA_PWR_MGMT_ENABLED to true. After this you should see the device going into sleep and wakiing up periodically to get messages from the parent (for which you would need to set MSA_DIRECT_MSG_ENABLED to true on the child node. 

    Also, I would recommend to use the latest TIMAC release TIMAC-1.5.2 for your project. 

    Hope this helps.

  • Hello Suyash,

    thank you for your reply. I think all my questions asked above are clear now. Unfortunately, there are some questions left. Actually, this was my first posting to the dead-state problem. As I figured some things out meanwhile, I posted another question in :

    "OSAL power-manager / halSleep() puts device in deep-sleep / PM3, why?"
    e2e.ti.com/.../1968302

    I would be very pleased if you could take a look there too.

    And, regarding your advices above:
    > you should not have to call the OSAL_pwrMgr API's to get device in to sleep mode.
    I call osalApi_PowerMgr() with TRUE or FALSE when an event has occured and the device has to do something like control peripherals, TX, RX or put the device into sleep after those actions. This seems to work as expected. If I don't do this, I figured that e.g. LED blinks don't work correctly.

    >Also, I would recommend to use the latest TIMAC release TIMAC-1.5.2 for your project.
    Yes, I upgraded to this version meanwhile.

    Best regards,
    Timo
  • Hey Timo,

    Power management should be enabled and stay enabled unless your application requires otherwise. Your timers should wake up the device when it is time to do something, ie blink an led. When this is completed and all other tasks are completed the device will go into pm2, assuming the timers are still active. I would make sure your timers are started successfully as well as making sure your timers stay active.