NUCLEO-U575 CAPTURE FAIL, is it a silicon level bug?

[dhs]

For the Nucleo-575ZI-Q, while in stop mode 2, I have the capture module enabled, I set CH1 IO Usage as input.

A square wave generator connected to PC1->LPTIM_CH1.
While the Micro is in stop mode 2 an indeterminate number of pulses trigger successive captures.
If the pulses on PC1 were odd CCR1 has the correct data.
If the pulses on PC1 were even CCR1 value doesn't updated at all.

Please note that all pulses arrive while STM32U575 is on stop mode.

I made a very short project isolating the problem, the RTC is used to exit stop mode 2 every second, when waking up only CRR1 is read and returns to stop mode 2.

void FM_MAIN_Main()
{
	uint16_t capture = 0;

	HAL_LPTIM_IC_Start(&hlptim1, LPTIM_CHANNEL_1);
	__HAL_RCC_LPTIM1_CLKAM_ENABLE();

	for (;;)
	{
		  HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET);
		  capture = LPTIM1->CCR1;
		  FM_DEBUG_UartUint16(capture);
		  HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET);

		  HAL_SuspendTick();
		  HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);
		  HAL_ResumeTick();
	}
}

/**
  * @brief LPTIM1 Initialization Function
  *  None
  * @retval None
  */
static void MX_LPTIM1_Init(void)
{

  /* USER CODE BEGIN LPTIM1_Init 0 */

  /* USER CODE END LPTIM1_Init 0 */

  LPTIM_IC_ConfigTypeDef sConfig = {0};

  /* USER CODE BEGIN LPTIM1_Init 1 */

  /* USER CODE END LPTIM1_Init 1 */
  hlptim1.Instance = LPTIM1;
  hlptim1.Init.Clock.Source = LPTIM_CLOCKSOURCE_APBCLOCK_LPOSC;
  hlptim1.Init.Clock.Prescaler = LPTIM_PRESCALER_DIV1;
  hlptim1.Init.Trigger.Source = LPTIM_TRIGSOURCE_SOFTWARE;
  hlptim1.Init.Period = 65535;
  hlptim1.Init.UpdateMode = LPTIM_UPDATE_IMMEDIATE;
  hlptim1.Init.CounterSource = LPTIM_COUNTERSOURCE_INTERNAL;
  hlptim1.Init.Input1Source = LPTIM_INPUT1SOURCE_GPIO;
  hlptim1.Init.Input2Source = LPTIM_INPUT2SOURCE_GPIO;
  hlptim1.Init.RepetitionCounter = 0;
  if (HAL_LPTIM_Init(&hlptim1) != HAL_OK)
  {
    Error_Handler();
  }
  sConfig.ICInputSource = LPTIM_IC1SOURCE_GPIO;
  sConfig.ICPrescaler = LPTIM_ICPSC_DIV1;
  sConfig.ICPolarity = LPTIM_ICPOLARITY_RISING;
  sConfig.ICFilter = LPTIM_ICFLT_CLOCK_DIV1;
  if (HAL_LPTIM_IC_ConfigChannel(&hlptim1, &sConfig, LPTIM_CHANNEL_1) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN LPTIM1_Init 2 */

  /* USER CODE END LPTIM1_Init 2 */

}

/**
  * @brief RTC Initialization Function
  *  None
  * @retval None
  */
static void MX_RTC_Init(void)
{

  /* USER CODE BEGIN RTC_Init 0 */

  /* USER CODE END RTC_Init 0 */

  RTC_PrivilegeStateTypeDef privilegeState = {0};

  /* USER CODE BEGIN RTC_Init 1 */

  /* USER CODE END RTC_Init 1 */

  /** Initialize RTC Only
  */
  hrtc.Instance = RTC;
  hrtc.Init.HourFormat = RTC_HOURFORMAT_24;
  hrtc.Init.AsynchPrediv = 127;
  hrtc.Init.SynchPrediv = 255;
  hrtc.Init.OutPut = RTC_OUTPUT_DISABLE;
  hrtc.Init.OutPutRemap = RTC_OUTPUT_REMAP_NONE;
  hrtc.Init.OutPutPolarity = RTC_OUTPUT_POLARITY_HIGH;
  hrtc.Init.OutPutType = RTC_OUTPUT_TYPE_OPENDRAIN;
  hrtc.Init.OutPutPullUp = RTC_OUTPUT_PULLUP_NONE;
  hrtc.Init.BinMode = RTC_BINARY_NONE;
  if (HAL_RTC_Init(&hrtc) != HAL_OK)
  {
    Error_Handler();
  }
  privilegeState.rtcPrivilegeFull = RTC_PRIVILEGE_FULL_NO;
  privilegeState.backupRegisterPrivZone = RTC_PRIVILEGE_BKUP_ZONE_NONE;
  privilegeState.backupRegisterStartZone2 = RTC_BKP_DR0;
  privilegeState.backupRegisterStartZone3 = RTC_BKP_DR0;
  if (HAL_RTCEx_PrivilegeModeSet(&hrtc, &privilegeState) != HAL_OK)
  {
    Error_Handler();
  }

  /** Enable the WakeUp
  */
  if (HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, 0, RTC_WAKEUPCLOCK_CK_SPRE_16BITS, 0) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN RTC_Init 2 */

  /* USER CODE END RTC_Init 2 */

}

[dhs]

@Sarra.S In this project, I cannot use DMA. While the microcontroller is in stop mode 2, hundreds of captures can be produced, but only the last one is of interest to me. If the number of captures is odd, the value of the CCR1 register is correct; however, if the number of captures is even, the value of CCR1 fails and shows the last capture that occurred before entering stop mode.

[dhs]

@Sarra.S 

How can I escalate this issue to another authority? The fault is very easy to replicate. I did it on several boards and with different processors, and the effect is disastrous for the quality of the microcontroller.

[Sarra.S]

Hello @dhs, 

I have escalated this case to the U5 team to further investigate (Internal ticket 197340). 

[dhs]

Hi,

I'd like to follow up on the issue I reported regarding LPTIM capture on the STM32U575 while in Stop Mode 2.

To summarize: I’m using the capture module (LPTIM3) with capture interrupts disabled while the MCU is in Stop Mode 2. Pulses arrive and captures occur during this low-power mode. When the system wakes up, I read the last capture value, expecting it to reflect the most recent event.

However, I’ve found that the capture register only updates correctly if the number of captured edges was odd. If the number was even, the register value remains unchanged. This causes erratic behavior and makes it impossible to rely on the last capture value alone.

I have reproduced this in several ways and can provide minimal example projects if needed.

Could you please update me on the status of this case?

Why use capture without interrupts in Stop Mode?
The goal is to measure signal frequency (e.g., from a flow sensor) while keeping the microcontroller in Stop Mode 2 to minimize power consumption.

To achieve this:

The LPTIM capture module is enabled and clocked from a low-speed clock (32.768 Hz).

Interrupts are disabled, so incoming edges do not wake the MCU.

Instead, captures occur silently in the background while the MCU sleeps.

Later, when the system wakes up (e.g., once per second), I read the last capture value, which ideally reflects the timestamp of the most recent pulse.

By combining:

The timestamp of the last edge,

And the number of pulses received during the sleep interval (using a counter),

I can compute the average frequency without needing the MCU to be active for every event. This is ideal for applications like battery-powered flow meters, where minimizing wakeups is critical.

Unfortunately, due to the suspected silicon issue, this method only works reliably when the number of edges during sleep is odd. If the number is even, the capture register doesn’t update, which breaks this low-power measurement approach.

This is why being able to trust the last capture value without needing interrupts is essential in these types of ultra-low-power designs.

Thanks,
Daniel