CC2538: Power mode 2 issue

Hi rei,

When the sleep timer overflows, it will start counting again from zero.  Given that no unexpected values of ui32Diff are supplied, I do not see a reason for the capture event to be missed.  The only consideration is whether SleepModeTimerCompareSet ever takes an elongated amount of time waiting to write the ST0 through ST3 registers.

void
SleepModeTimerCompareSet(uint32_t ui32Compare)
{
    //
    // Wait for ST0, ST3 regs to be ready for writing
    //
    while(!(HWREG(SMWDTHROSC_STLOAD) & SMWDTHROSC_STLOAD_STLOAD))
    {
    }

    HWREG(SMWDTHROSC_ST3) = (ui32Compare >> 24) & 0x000000ff;
    HWREG(SMWDTHROSC_ST2) = (ui32Compare >> 16) & 0x000000ff;
    HWREG(SMWDTHROSC_ST1) = (ui32Compare >>  8) & 0x000000ff;
    HWREG(SMWDTHROSC_ST0) = ui32Compare & 0x000000ff;
}

How often does this issue occur and is it mitigated by using larger msec values?  Is this observable on TI hardware like the SMARTRF06EBK?

Regards,
Ryan

Hi Ryan,

Thank you very much. I'll check with the customers.

Regards,

Rei

Hi Ryan,

We checked with the customer and the system enters PM2 once every 20 ms. 3 out of 16 units have this problem, and we don't know if we can reproduce it on the evaluation board.

I think this is a HW factor as it only happens on certain products.

We will check the supply voltage and clocks and get back to you.

Regards,

Rei

Thanks for the update Rei!  I recommend the customer cross-reference the CC2538EMK/CC2538EM-RD board designs and even submit their own designs to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS for an expert to review if they have any further hardware-related doubts or concerns.

Regards,
Ryan

Hi Ryan,

Thank you for your reply. This is a very urgent issue that was discovered during mass production shipping. If it is not resolved, I will request here.

We are checking the hardware, and also checking the software. We think that the factors of this issue are following.

・Design error in the power supply and clock, affecting the CC2538 and the clock.
　->Now we are confirming.
・The workaround for errata has not been applied.
・Inappropriate value is stored in the compare value.
　->Now we are checking the timer and compare value when not recovering from sleep.
　->Checking the Fault handler registers when not recovering from sleep.

I have some questions about these.

Q1:
About the "SysCtrlDeepSleep" API in Foundation firmware. (sys_ctrl.c in driverlib) and Errtta.
Are workarounds implemented in the API? I think it applies, however have difficulty understanding the description.

Errata: 1.5 Possible Incorrect Value of Clock Dividers after PM2 and PM3

void
SysCtrlDeepSleep(void)
{
#ifndef NO_CLOCK_DIVIDER_RESTORE
    bool  bRestoreSys;
    bool  bRestoreIO;
    uint32_t ui32Reg;

    ui32Reg = HWREG(SYS_CTRL_CLOCK_STA);
    bRestoreSys = (ui32Reg & SYS_CTRL_CLOCK_STA_SYS_DIV_M)==0;
    bRestoreIO  = (ui32Reg & SYS_CTRL_CLOCK_STA_IO_DIV_M)==0;
    if(bRestoreSys || bRestoreIO)
    {
        ui32Reg = HWREG(SYS_CTRL_CLOCK_CTRL);
        ui32Reg |= bRestoreSys? 0x1:0x0;
        ui32Reg |= bRestoreIO? 0x100:0x0;
        HWREG(SYS_CTRL_CLOCK_CTRL) = ui32Reg;
    }
#endif
    
    //
    // Enable deep-sleep.
    //
    HWREG(NVIC_SYS_CTRL) |= NVIC_SYS_CTRL_SLEEPDEEP;

    //
    // Wait for an interrupt.
    //
    CPUwfi();

    //
    // Disable deep-sleep so that a future sleep will work correctly.
    //
    HWREG(NVIC_SYS_CTRL) &= ~(NVIC_SYS_CTRL_SLEEPDEEP);

#ifndef NO_CLOCK_DIVIDER_RESTORE
    if(bRestoreSys || bRestoreIO)
    {
        ui32Reg = HWREG(SYS_CTRL_CLOCK_CTRL);
        ui32Reg &= bRestoreSys ? ~SYS_CTRL_CLOCK_CTRL_SYS_DIV_M : 0xffffffff;
        ui32Reg &= bRestoreIO ?  ~SYS_CTRL_CLOCK_CTRL_IO_DIV_M : 0xffffffff;
        HWREG(SYS_CTRL_CLOCK_CTRL) = ui32Reg;
    }
#endif
}

Q2:
If software is a factor, it may be that the timer counting exceeds the compare value before it is set.
Regarding the Foundation firmware Example(sleepmode), SleepModeTimerCompareSet is set after 10000.

ui32Val = SleepModeTimerCountGet();
SleepModeTimerCompareSet(ui32Val + 10000);

Do you know the minimum number of compare value that can be set before cc2538 enter to sleep?

I appreciate your help.

Regards,
Rei

Q1: The SysCtrlDeepSleep API applies the workaround for Errata 1.5 so long as NO_CLOCK_DIVIDER_RESTORE is not defined.

Q2: You already documented this from the User's Guide: "When setting a new compare value, the value must be at least 5 more than the current sleep timer value."  You appear to be using values in the mid-hundreds which should be fine.

Regards,
Ryan

Hi Ryan,

Thank you very much. Currently, customers are trying different settings. When they disable "32kHz RCOSC Calibration", the problem is no longer reproduced. They wants to use a 32-kHz internal oscillator without calibration.

What is the accuracy of the 32-kHz RC Oscillator when the calibration is disabled?
I understand that the calibrated accuracy is 5.10 32-kHz RC Oscillator in DS.

Regards,
Rei

The 32 kHz RC oscillator is greatly inaccurate when uncalibrated and varies widely across temperature and supply voltage changes.  It is not recommended for operation and thus is not specified in the datasheet.  Since the calibrated 32-kHz RC oscillator frequency is the 32-MHz XTAL frequency divided by 977, please make sure that this external crystal is operating properly.

Regards,
Ryan

Hi Ryan,

Thank you for your reply. We have checked the clock. They are using the same crystal and capacitance as CC2538EMK.
So we think the cause is something else, but I will contact "Design Review".

By the way, we have experimented and found that if we don't calibrate it, it wake-up from PM2 fine. If customer's application does not require the accuracy of 32kHz RC oscillator, we would like to use it without calibration. I'm assuming that the 32kHz RC oscillator is only supplied to the Sleep Timer, WDT, and MAC Timer. Is this correct?

I'm sorry to ask about something so small and I'm grateful every day for your support.

Regards,
Rei

Your analysis of low frequency oscillator usage is accurate, this is further explained in Section 7.2.2 of the TRM.

Regards,
Ryan

Hi Ryan,

Thank you very much for your help. We will also consider using it with the calibration disabled.
Now we are investigating the mechanism that don't wake-up from PM2. So customers have a question about their usage.

1. CC2538 Power-On
2. Active mode 500ms (32MHz External crystal & 32kHz Internal Oscillator)
3. Power mode 2: 20ms
4. Active mode: 1ms
5. Power mode 2: 20ms
6. Active mode: 1ms　
7. Repeat 3~6

Enable calibration. 32 kHz RCOSC Calibration is stated to require 2ms.
TRM:7.2.2.1 32 kHz RCOSC Calibration

In their usage, Active mode is only 1ms. Calibration is done every time it switch to 32 MHz XOSC. In other words, it is calibrated every time it wake-up from PM2. Is this correct?

I would expect that if Active mode is only 1 ms, calibration may not complete. According to TRM, when WFI is asserted before the calibration is complete, it is calibrated during the transition to PM2. Therefore, we think that the transition time to PM2 will be longer and the value of compare will be exceeded during the transition.

Regards,
Rei

You are correct that calibration would occur every time the MCU wakes up, and that the variable transition time may be extended to allow for calibration to finish, but I don't understand how an extra 2 ms of transition would cause the wakeup from PM2 after 20 ms to be missed.  The calibration would need to take much longer than estimated in order to cause an issue.  What is the behavior if you add a small (few ms) delay before entering PM2 or if you extend the amount of time spent in PM2?

Regards,
Ryan

Hi Ryan,

Thank you very much. We have tested it. When we set 3ms active time, the problem does not occure. (More experiments are needed) When PM2 is set to 1ms, the frequency of problems increases.

I also consider 20ms to be sufficient time for calibration, but it have the problem. So the design of the external 32MHz clock and the calibration time will be the focus of the discussion. Customers don't expect that much accuracy from a 32kHz oscillator, because they only use SleepTimer and WDT. Therefore, customers are thinking of using it with calibration disabled.

Question 1:
For example, we do one calibration at startup and then disable the calibration.
Will the calibrated state be retained?

Question 2:
We are thinking of enabling calibration periodically (e.g. once an hour).
Is this usage OK?

Question 3:
We are checking the datasheet.
5.8 32-MHz Crystal Oscillator
Power-down guard time : min 3ms

What does this time mean? Does it mean that the power down time (PM2 time) needs to be more than 3ms in order to oscillate again? Thank you for the support in the other thread. We are also considering an external 32kHz crystal.

Regards,

Rei

Hi Rei,

You're correct in your interpretation of the power-down guard time. Unfortunately, we need to do some more research on the calibration frequency and longevity. I'm asking around about this internally, but this is an older part so it may take a bit longer. Hope to have an answer soon.

Best,

Hi Nathan,

Thank you for your answers. I look forward to your response.

Best regards,

Rei

Hi Nathan, Ryan,

I appreciate you checking. Now customers want to use cc2538 without calibration and solve this.
After evaluation, they believe that this usage will not cause any problems, but they want to know the mechanism of this problem. We hypothesized about this problem.

e2e.pdf

If there are any other possible factors, please tell me it.
I will continue to look forward to your response about calibration.(Question 1 and 2)

Thank you very much for your support.

Best regards,
Rei

Thanks for the detailed summary Rei.  I believe the calibration state would be retained and that re-calibrating periodically would be fine given that temperature and voltage drift are not a concern, but do not know this for certain and am still waiting on other experts to confirm.

Regards,
Ryan

Hi Nathan, Ryan,

Thank you so much. Your information will save us.
With your information, we are getting closer to a solution, but customers still have questions.

When we use it without calibration, the fluctuations are large. My customers are going to calibrate once in a period of time, but they don't know how much time they should keep active.

Question 1:
CC2538 datasheet 5.10 32-kHz RC Oscillator
Calibration time typ 2ms
Do you have any information about maximum calibration time?

Question 2:
They want to detect that the 32-kHz RC Oscillator calibration is finished. Would you tell me how to detect it?

Question 3:
In the User's Guide, section 7.2.2.1 32 kHz RCOSC Calibration,
「During calibration, a divided version of the 32 MHzXOSC is used. The result of the calibration is that the 32 kHz RSOSC is running at 32.753 kHz. 」

In other words,
・During calibration, a divided version of the 32 MHz XOSC is used.
・During sleep, it is using the calibrated 32 kHz RC Oscillator.

When Calibration is finished during Active, which 32 kHz Clock is used?
"Divited version of 32MHz XOSC" or "Calibrated 32kHz RC Oscillator"

Customers are using piinmux to output and observe a 32kHz waveform. Duty cycle of the 32kHz clock is different between Active and PM2. By observing this, we may know when the calibration is finished.

Regards,
Rei

Hi,

For Q3, we may have figured it out with our experiment.

We experimented with increasing the Active time; after about 1.6ms in Active mode, I found the timing of the 32kHz duty cycle change. This timing would indicate that the 32kHz clock has been switched. After calibration indicates that a "calibrated 32kHz RC oscillator" is used.

If you have any information about Q1 and Q2, please tell me.

Regards,

Rei

Hi Nathan, Ryan,

Do you have any information on Q1 and Q2?
I would appreciate any response.

Regards,

Rei

Hi Rei,

1. Unfortunately we don't have a maximum calibration time for that part.

2. I think you can use the 32 kHz clock as a source to a timer to count to 1.6 or 2 msec or whatever you decide to use as your cutoff. You'll need to account for the +/-18% accuracy in that though, so to account for an expected 2 msec delay, you would need to wait at least 2.36 = 2 * 1.18 msec to ensure that you're still working fine in the worst case scenario.

Best,

Nate

Hi Nathan,

Thank you so much for your support. I'm very sorry, I can't understand about Q2.
We know from our experiments that 32kHz clock source is switched after the calibration is finished.

We think that the Calibration time (about 1.6ms, typ2ms) varies for each individual device. If we can detect it when the clock source changes, we can confirm it and enter to PM2.

Is it possible to detect that the calibration is finished? For example, looking at the registers.

Regards,

Rei

Rei,

The only clock source change is from the 16-MHz RC oscillator to the 32-MHz crystal oscillator after exiting LPM, it then takes ~2 ms to complete calibration.  There is no register available to determine the exact time calibration finishes.  As Nathan explained, you will need to wait a maximum of 2.36 ms in active mode to ensure that calibration is fully executed.

Regards,
Ryan

Hi Ryan, Nathan,

Thank you very much. I understood that it cannot detect that the calibration is finished.

Thanks again for your support. I’ll keep you posted.

Regards,

Rei