STM32L1 STOP mode and resume

[dflogeras]

Hi,

I have a project in which the main loop basically does the following

Code: Select all

while( 1 ) {
  chWaitSem( &sensor_data ); // Posted in EXT handler
  i2cMasterTransmitTimeout( ... ); // Read sensor data samples
  process();
}

I noted on my scope that I spend a lot of time waiting, so I decided I might try using a low power mode of the processor while just loafing. I added the following at the end of my main loop:

Code: Select all

    if( palReadPad( GPIOB, 14 )) {  // For safety to disable sleeping if desired
      PWR->CR |= (PWR_CR_LPSDSR | PWR_CR_CSBF | PWR_CR_CWUF);
      PWR->CR &= ~PWR_CR_PDDS;
      SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;
      __WFI();
    }

After doing this, I noted that my i2c transactions were going at 1/16th the speed they were programmed for (after the first sleep). This is because on resume, the uC is using MSI as a clock source. So I added a call to stm32_clock_init() right after __WFI() returns to re-initialize the clocks and PLL to the way they were.

However, after resuming, i2c was no longer working. I made it work again by adding i2cStop() before going to sleep, and i2cStart() after resuming. I was just wondering if this is a recommended way of using STOP mode, and if not what should I be doing. Are there any other things I should consider stopping and restarting before/after STOP mode? The only other HAL driver I am using currently is the call to extStart() which I assume is OK and doesn't require re-initialization.

[Giovanni]

You should not change clock settings while peripherals are active so stopping/restarting is the correct approach. EXT is an exception because it is not affected by clocks.

Giovanni

[dflogeras]

Thanks,

So now that I have the approach, I am seeing about a ~300uS delay between my EXT interrupt, and my wakeup. That is, I put a palSetPad( ... ); inside of my interrupt handler (as well as one directly after __WFI() ) to measure my wakeup latency.

Does anyone know why this might be? The RM says the STM32L15x should wakeup from STOP on EXTI in 8uS. I recall a thread where barthess was waking up in this order of magnitude, but I am almost 40x longer:

viewtopic.php?f=3&t=165&start=0

[Giovanni]

Probably the PLL setup time, see the datasheet.

Giovanni

[dflogeras]

You are right, but because I was measuring improperly

Due to a second interrupt I was actually measuring the total time to wake-up, set the clocks/PLL, restart the drivers, and then resume my main-loop. I corrected that and now the time from EXTI interrupt until setting the GPIO is closer to 28uS. So 8uS for the hardware and 20uS for the OS to dispatch the interrupt to my callback which seems reasonable given that the system clock is running @ 1MHz at that point.

It's a non issue for me, since I can program my accelerometer's high-water mark to be a sample sooner and give myself a bit more time to read its buffer before it overflows. I just wanted to know why I was seeing what I was seeing.

Thanks,
Dave