cancel
Showing results for 
Search instead for 
Did you mean: 

Suspicious behaviour with sleep mode on wait for event from timer.

PMach.3
Associate II

Hello,

I am using a Nucleo-L073RZ board for my application. Reducing power consumption is adamant. Being so, I opted to put the MCU to sleep mode with WFE in some ocasions where some kind of delay is needed, with a reduction of HCLK (64 division). I am using a timer to re-awake the MCU after a certain amount of time.

To test this, I reset a pin before the SEV and set it back on again after the timer's counter reaches the value in its ARR register. You can see below some code, which runs on the infinite loop inside my main.

TIM6->ARR = 3;
 
  while (1)
  {
	  TIM6->SR = ~(TIM_FLAG_UPDATE);		      	/* Clear 1st dummy IT when starting the counter */
	  NVIC_ClearPendingIRQ(TIM6_DAC_IRQn);			/* Clear Interrupt flag */
 
	  RCC->CFGR = RCC_CFGR_HPRE_DIV64;    			/* Decrease the HCLK clock during sleep */
 
	  LD2_GPIO_Port->BRR = LD2_Pin;
 
	  TIM6->CR1 |= TIM_CR1_CEN;						//Enable counter
 
	  __SEV();
	  __WFE();
	  __WFE();
 
	  LD2_GPIO_Port->BSRR = LD2_Pin;
 
	  RCC->CFGR = RCC_CFGR_HPRE_DIV1;
 
	  HAL_Delay(1000);
    /* USER CODE END WHILE */
 
    /* USER CODE BEGIN 3 */
  }

What I noticed was that, the timings work more or less fine. I noticed there is an offset of about 5 ou 6ms.

For example, if I set the ARR to 500, being the HCLK 2.097MH and divided by 64, we get a counter increment period of 30.5us which, times 500, should give a delay time of a little bit over 15ms. In this case, I measure about 20.5ms. For ARR=1000, I would expect double this value and I get 35.68ms.

If I do the same for ARR=100, I am expecting 3ms (8ms, accounting to the overhead) and I get 8.3ms.

In these cases, the values are about 5ms above what I expected. I suspect this is caused by overhead effects, but I think that 5 or 6ms in overhead is too much.

My main problem is: I need to put the MCU in sleep mode for durations that reach as low as 80us to respect timing constraints of my application. I notice I can lower this offset to 1.43ms if I do not divide the HCLK, but that doesn't solve my problem and brings another one: greater power consumption.

Are these timings possible in sleep mode on this MCU?

Thanks in advance.

1 REPLY 1

Post a minimal but complete compilable code exhibiting the problem.

Generally, avoiding Cube helps to have control.

Btw. I wonder how could timer wake up from WFE.

JW