• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 80 subscribers
  • Views 1160 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.

Wakeup time from LPM4.5

TL Yang
Prodigy 20 points

Hello,

I have a question regarding the wakeup time from LPM4.5 on RF430F5144.

In my project, this wakeup time is about 12 ms and I want to reduce it to 3 ms. The typical value from datasheet is about 2 ms.

In order to check the wake time, I have made a simple project and done some tests.

1. The most simple case. The program size is 466 bytes and data size is 2 bytes. The MCU be active from LPM4.5 is 2.5 ms.

2. Some global variables are added, but those variables don't be used in the test program. The test program is same with that in CASE 1. The program size is 562bytes, and data size is 172 bytes. The wake up time is 7ms.

3. Some anthor functions are added, but don't be called by the test program. The program size is 3670 bytes and data size is 650 bytes. The wakeup time is 12 ms.

I have spend a long time in this problem, Could anybody help me?

 

  • 0
    TI__Expert 7555 points

    Hi,

    The increased LPM4.5 to active-mode wake-up time you are observing is partially a function of the time it takes to initialize all of your global variables that have initialization values (basically, your .data section of memory).  In LPM4.5, the MCU is basically off.  When exiting LPM4.5, the MCU will go through a full reset.  This means that the boot code will have to execute before your application ever gets to main() during a wake from LPM4.5. 

    A portion of the boot code is .data initialization based upon the cinit tables (if you are using the EABI compiler output with standard settings).  The more data you have in your application, the longer this process takes.  It's also important to note that this execution is done by the CPU and since the device just came out of reset, the CPU is only running at its default clock speed (~1MHz).  This can make the boot time rather substantial.

    If you need to achieve a 3ms wake time, you will have to perform initialization of global variables by hand, so that you can get into your application quickly, init only the critical data, set up all of your clocks, then init the rest of your data later.  Keep in mind that this is an oversimplification of the process- doing this effectively will be fairly involved.  This may not even be feasible if you require all of your data to be initialized immediately.

    I recommend that you review the MSP430 Compiler Optimization Guide (http://www.ti.com/lit/ug/slau132h/slau132h.pdf).  Section 6.8 discusses the different methods of initializing data sections.

    Regards,
    Walter

  • 0 in reply to Walter Schnoor
    Prodigy 20 points

    I got it. Thanks.

  • 0 in reply to Walter Schnoor
    Guru 227245 points

    Walter Schnoor said:
    If you need to achieve a 3ms wake time, you will have to perform initialization of global variables by hand, so that you can get into your application quickly

    Another way t6o speed the (default) process up is to raise CPU speed before initializing the global vars. Usually, the system_pre_init function is used to deactivate the watchdog so it won't bark during a slow var init. However, at this point the CPU speed can also be raised above default (within the range of the default core voltage, since raising it will take additional time). On 5x family, 7-8MHz instead of the default 1MHz (or less, as the FLL takes some time for reaching 1MHz) will significantly shorted the startup time even if the var init process isn't touched.

    In any, case, the new approach of compressing init data may save quite some flash, but it causes a huge slowdown for the startup. This should be configurable!

**Attention** This is a public forum