STM32L475RC glitch in fixed timer PWM

[Electronic1]

Hello,

I have a power converter device controlled by a STM32L475RC. One part of the control requires a constant PWM of 70kHz of 300ns (Ton).

Although this pwm is never modified,and doesn't use interrupts or DMA modules, periodically it produces a glitch in its output (like in attached image). Specially when there is high noise of power conversion.

I suppose that another peripheral is producing this error, but I can't figure out which one. (Another timer?, a I2C by DMA communication?,...)

Any one has ever seen some similar, and know which is the cause?

Thanks in advance

/* TIM8 init function */

void MX_TIM8_Init(void)

{

 /* USER CODE BEGIN TIM8_Init 0 */

 /* USER CODE END TIM8_Init 0 */

 TIM_MasterConfigTypeDef sMasterConfig = {0};

 TIM_OC_InitTypeDef sConfigOC = {0};

 TIM_BreakDeadTimeConfigTypeDef sBreakDeadTimeConfig = {0};

 /* USER CODE BEGIN TIM8_Init 1 */

 /* USER CODE END TIM8_Init 1 */

 htim8.Instance = TIM8;

 htim8.Init.Prescaler = 0;

 htim8.Init.CounterMode = TIM_COUNTERMODE_UP;

 htim8.Init.Period = 1143;

 htim8.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;

 htim8.Init.RepetitionCounter = 0;

 htim8.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_DISABLE;

 if (HAL_TIM_PWM_Init(&htim8) != HAL_OK)

 {

   Error_Handler();

 }

 sMasterConfig.MasterOutputTrigger = TIM_TRGO_RESET;

 sMasterConfig.MasterOutputTrigger2 = TIM_TRGO2_RESET;

 sMasterConfig.MasterSlaveMode = TIM_MASTERSLAVEMODE_DISABLE;

 if (HAL_TIMEx_MasterConfigSynchronization(&htim8, &sMasterConfig) != HAL_OK)

 {

   Error_Handler();

 }

 sConfigOC.OCMode = TIM_OCMODE_PWM1;

 sConfigOC.Pulse = 24;

 sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH;

 sConfigOC.OCNPolarity = TIM_OCNPOLARITY_HIGH;

 sConfigOC.OCFastMode = TIM_OCFAST_DISABLE;

 sConfigOC.OCIdleState = TIM_OCIDLESTATE_RESET;

 sConfigOC.OCNIdleState = TIM_OCNIDLESTATE_RESET;

 if (HAL_TIM_PWM_ConfigChannel(&htim8, &sConfigOC, TIM_CHANNEL_1) != HAL_OK)

 {

   Error_Handler();

 }

 sBreakDeadTimeConfig.OffStateRunMode = TIM_OSSR_DISABLE;

 sBreakDeadTimeConfig.OffStateIDLEMode = TIM_OSSI_DISABLE;

 sBreakDeadTimeConfig.LockLevel = TIM_LOCKLEVEL_OFF;

 sBreakDeadTimeConfig.DeadTime = 0;

 sBreakDeadTimeConfig.BreakState = TIM_BREAK_DISABLE;

 sBreakDeadTimeConfig.BreakPolarity = TIM_BREAKPOLARITY_HIGH;

 sBreakDeadTimeConfig.BreakFilter = 0;

 sBreakDeadTimeConfig.Break2State = TIM_BREAK2_DISABLE;

 sBreakDeadTimeConfig.Break2Polarity = TIM_BREAK2POLARITY_HIGH;

 sBreakDeadTimeConfig.Break2Filter = 0;

 sBreakDeadTimeConfig.AutomaticOutput = TIM_AUTOMATICOUTPUT_DISABLE;

 if (HAL_TIMEx_ConfigBreakDeadTime(&htim8, &sBreakDeadTimeConfig) != HAL_OK)

 {

   Error_Handler();

 }

 /* USER CODE BEGIN TIM8_Init 2 */

 /* USER CODE END TIM8_Init 2 */

 HAL_TIM_MspPostInit(&htim8);

}

// 70KHz (Ton 300ns)

HAL_TIM_PWM_Start(&htim8, TIM_CHANNEL_1);

[Electronic1]

Hi again,

I have been following my research and I can add that during these "glitch time" there is an uncontrolled drop of some ports like gpio A 1. Although there hadn't been any microcontroller reset detected

[MM..1]

Dont your code use STOP mode?

[TDK]

I would guess your chip is resetting. The spikes do not line up as they would if the timer were not being interrupted.

> Specially when there is high noise of power conversion.

What does this mean exactly?

[Electronic1]

I can confirm that chip is not resetting.

>Specially when there is high noise of power conversion.

This refers to electromagnetic noise produced by power converter. As the power converter produces more power the magnetic devices increase the noise they produce,

And in this situation more pulses of this PWM output are lost

[Electronic1]

No, I am just using Run mode, in our application low power modes aren't required.

[TDK]

Not sure. I don't see what else would interrupt the counter besides a reset. Although a reset only taking ~6us would be very quick. Maybe take a look at the power rail and ensure that is sufficiently stable.

[waclawek.jan]

> I can confirm that chip is not resetting.

How?

JW

[Electronic1]

A reset proces would imply a restore of the state machine, which would imply long waits and ports would follow up all the initialization process.

[Electronic1]

I have checked the power rail but it seems stable