CC1110 PM

Hi Uriw,

To the first question:

The reason it does not enter PM2 is that the timing is wrong. The errata says:
"NOTE: The following code assumes the chip is already running at the HS RC oscillator
with the highest clock speed setting possible and this has to be handled by the
application. The code marked blue below is timing critical and should be done in the
order as shown here with no intervening code."

Without knowing you implementation, I would guess that you have not made sure you are running on the HS RC oscillator prior to executing the code. To be sure that the HS RC osc is stable and used as the clock source, please read back the OSC bit in CLKCON. The whole trick with the errata is to align a DMA write to the SLEEP register so that the first thing that happens after waking up is that the SLEEP bits are set to 0. Wrong timing and this will happen prior to the device going to sleep and thus it enters PM0 instead.  Since the errata is for rare occasions of a hang-up, your code will work fine for a long period, but might eventually freeze.

To question number 2:

Nope..you will need to follow the errata to be 100% safe from the fact that the part may hang in power mode. I'll let the author of the design note know so that this can be fixed. Thanks for pointing this one out.

Regards,

Kjetil

Hi Kjetil,

Thanks for your advise, checking CLKCON.SRC solved the problem.

Another question: During Tx (10dBm, 915MHz, 250kBaud GFSK), our power consumption reaches 48mA, much more than the spec (my understanding is that it should be 36mA). Any idea where to look?

Thanks,
Uri

Uri,

A poorly designed balun could give a higher than expected current consumption. What is the ouput power when you program for +10 dBm?

Is it only in TX you see this large deviation from expected current consumption? Try other modes of operation to check if it is related to TX only or not.

I'm implementing a sensor software application directly over TI-MAC 1.2.1 and using the power saving feature.

When my sensor doesn't find a valid coordinator to associate to, it goes in PM2 for about 3 minutes, after that it wakes up and repeat the same operations.

The power saving is enabled during sw initialization:

osal_pwrmgr_device(PWRMGR_BATTERY);

The application task after wake up try to connect to a valid coordinator and if failed it goes in PM2:

osal_pwrmgr_task_state( osal_self(), PWRMGR_CONSERVE );

osal_start_timer( APP_EVENT_T1, CFG.INACTIVE_SLEEP_T1 ); CFG.INACTIVE_SLEEP_T1 is equals to 30000ms ( a counter let me to repeat this 6 times: 30sx6 = 180s= 3 minutes).

The code works fine but sometimes the software execution freezes, my question is why this happen?

Note that the halsleep function in hal_sleep.c file of TI-MAC applies the DN106 design note rules as regards the power mode entering and oscillator settings. The RC oscillator settings prior to enter PM2 haven't to be performed by application sofware because this is done directly by halsleep function.

Do you have any ideas? Thanks in advance.

void halSleep( uint16 osal_timeout )
{

...

/* set main clock source to RC oscillator for Rev B and Rev D */
          HAL_SLEEP_SET_MAIN_CLOCK_RC();
...

if ( ((uint16)(*( __idata uint16*)(CSTK_PTR)) >= 0xF000) )
          {
            HAL_EXIT_CRITICAL_SECTION(intState);

            /* AN044 - DELAYING EXTERNAL INTERRUPTS, do not relocate this line.
             * it has to stay as close to PCON.IDLE = 1 as possible.
             */
            EXTERNAL_INTERRUPT_DELAY();

            /* set CC2430 power mode */
            HAL_SLEEP_SET_POWER_MODE(halPwrMgtMode);
            /* wake up from sleep */

            HAL_ENTER_CRITICAL_SECTION(intState);
          }

          /* restore interrupt enable registers */
          HAL_SLEEP_IE_RESTORE(ien0, ien1, ien2);

          /* disable sleep timer interrupt */
          HAL_SLEEP_TIMER_DISABLE_INT();

          /* set main clock source to crystal for Rev B and Rev D only */
          HAL_SLEEP_SET_MAIN_CLOCK_CRYSTAL();

...

Have you been able to determine where the software freezes?

Is it possible to instrument your code to perhaps set/clear a GPIO output based on the state?