CC2541 mysterious delay before entering PM2

Dan Lewis1

Other Parts Discussed in Thread: CC2541

Our device exhibits behavior we don't understand when entering PM2.

Once per second the CC2541 in our design wakes up with a sleep timer interrupt, transmits an advertisement on each of three channels, then goes into PM2. In some cases, it first communicates with a peripheral via I2C. We are using the radio in proprietary mode. We are not using the TI BLE stack.

When there is I2C communication before the advertisements, the CC2541 goes to sleep almost immediately after the final advertisement. In the picture, you can see the I2C traffic on D0/D1, the three peaks from the three advertisements. The analog trace is across a 10 ohm resistor out of a bench supply set at 3.00V.

When there is no I2C traffic, it takes 600 µsec to sleep after SLEEPCMD = 6 and PCON = 1. In the picture below, D2 and D3 are IOs that I'm toggling in code right before PCON = 1. The next 600 µsec is after the PCON = 1 statement and before the following statement (we use a NOP), the one executed after waking from PM2. D3 goes low just before the NOP.

The statement after PCON = 1 is not aligned on an address divisible by 4.

The CC2540-41 User's Guide simply says that "When PM1, PM2, or PM3 is entered, a power-down sequence is run."

Any ideas what could be causing the difference, or could be causing the CC2541 to take 600 µsec to power down after PCON is set to 1?

Thanks
Dan Lewis

over 12 years ago

0 Dan Lewis1 over 12 years ago

Intellectual 265 points

I pasted the pictures into my post but they aren't appearing. I'll try attaching them this time...

0 Dan Lewis1 over 12 years ago in reply to Dan Lewis1

Intellectual 265 points

Second picture...

0 Dan Lewis1 over 12 years ago in reply to Dan Lewis1

Intellectual 265 points

I'm trying this again. I am reposting my images with captions this time.

The CC2541 is taking 600 µsec to enter PM2 in one case, entering almost immediately in another. It's the same code; the only difference we can see is that it's doing some I2C communication in one case and none in the other.

We're stumped and would really appreciate some help.

Thanks
Dan Lewis

0 Ian Cathey over 11 years ago in reply to Dan Lewis1

TI__Intellectual 1310 points

Dan,

It's interesting to me that, in both cases, from wakeup to power down takes almost exactly 2ms. Is there anything in your code running that could account for this?

Ian

0 Peder over 11 years ago in reply to Ian Cathey

TI__Expert 6995 points

Hi Dan,

Sounds like you're using the internal 32 kHz RC oscillator with calibration. That calibration sequence takes around 2 ms every time you turn the 32 MHz XTAL on. The calibration can be disabled using the SLEEPCMD.OSC32K_CALDIS bit if you want.

Peder

0 Dan Lewis1 over 11 years ago in reply to Peder

Intellectual 265 points

Thanks, Peder. This one would have taken us a long time to figure out! Setting SLEEPCMD.OSC32K_CALDIS resolved the problem.

Regards,
Dan Lewis

0 Marty Holmquist over 10 years ago in reply to Peder

Prodigy 240 points

Hello,

This sound simular to the issue I'm having. But instead of a 2ms delay, I'm seeing 400ms before PM2 is entered. No matter what event/methods are called the CC2541 stays in a 8mA draw for the 400ms after BLE and other higher current events finish. POWER_SAVING mode is enabled and I've seen other folks state simular issues, but have not heard a common fix.

Let me know what further information you may need to help suggest a place to look. I've tracked the tasks and events and found that following tasks and events are repeating.

LL_ProcessEvent (Task 0 ) Event codes 128 and 256

GAPRole_ProcessEvent(Task 8) Event code 32768

GAP_ProcessEvent(Task 5) Event code 32768

The last two are likely the same event and being passed off between tasks.

Any ideas on where to look would be highly appreciated!

Marty

Bluetooth®︎

Bluetooth forum

CC2541 mysterious delay before entering PM2