Annoying glitch on Timer Output compare channel

[LVan .31]

For a project I am using a number of timers to generate and/or monitor digital signals in a custom protocol. I stumbled upon a glitch in a timer Output Compare channel which I would like to share to find whether this is recognized and if there is a possible solution.

One of the timers is used in Encoder mode to detect the start and stop of the applicable protocol. Only when one of the signals is high, a rising edge on the other signal identifies the start of a message where a falling edge while the other signal is high identifies the end of a message. When detecting a start, one Output channel 3 is set high (output compare functionality). When detecting a stop the Output Compare channels is set low again. Doing so I generate a signal which is high while a message is present.

The protocol is shown in this picture. The top line is a clock signal and the second line a data signal. As shown, only during the first and the last clock, the data signal changes. During the clocks in between the data signal is constant. The start and stop is detected and results in the third line, the message valid signal.

The glitch is present on the rising edge of the Output Compare channel as shown in the image below (zoomed in, using the logic analyzer at 800MHz)

The glitch occurs ~25ns after the start of the signal and the duration is ~6ns.

Some more info:

• The glitch only occurs when setting the speed of the IO to medium, high or very high. Using speed low the glitch does not occur.
• Enabling pull-up or pull-down on the pin has no effect.
• The glitch is only present in the actual signal. I also use the output compare as a trigger output of another timer and from this I know the glitch is not present in the internal OCREF signal
• I only tested with an STM32H563 and don't know if the glitch is also present in other series.
• Only tested with the timer in encoder mode (which according the documentation) should not have any effect on the OC or PWM behavior of the timer

Hope someone can shed light on this

 

 

[TDK]

Can you share your timer channel configurations? Register values would be best.

[LVan .31]

Below are the register settings as shown in STM32CubeIDE

Also I use DMA to constantly change the value of CCR3 which is what the DMA Burst statement below is for.

The timer starts at 0, when the rising edge is detected the count goes to 1 which matches CCR3 and the output is toggled. Also the DMA is triggered to set CCR3 to 0. Now on the next falling edge the count goes to zero which matches the new value of CCR3 and the output is toggled again and so on.

		if (HAL_TIM_DMABurst_MultiWriteStart(	&halInstance,
												TIM_DMABASE_CCR3,
												TIM_DMA_CC3,
												(uint32_t*)&mainCtrPrimaryData,
												TIM_DMABURSTLENGTH_2TRANSFERS,
												sizeof(mainCtrPrimaryData))	!= HAL_OK){Error_Handler();}

		if (HAL_TIM_OC_Start		(&halInstance, TIM_CHANNEL_3)	!= HAL_OK){Error_Handler();}
		if (HAL_TIM_OC_Start		(&halInstance, TIM_CHANNEL_4)	!= HAL_OK){Error_Handler();}
		if (HAL_TIM_Encoder_Start	(&halInstance, TIM_CHANNEL_ALL)	!= HAL_OK){Error_Handler();}

 

[LVan .31]

Mea Culpa, Mea Maxima Culpa,

I caused noise over some noise but the source of the noise was me.

The channel with the glitch is connected to another timer input through a wire. As it seems now, this wire picked up noise causing the glitch.

Changed the wire, moving it away from other wires and the glitch is gone.

I am very much aware about wiring issues in a proto setup but did not think of this since when the glitch was there, not other signals had an edge that could cause it which is the case most of the time.

Never too old to learn.....

[LVan .31]

And further investigation learned that it actually was not a wiring issue but a pin issue. The channel showing the glitch is connected to another timer as a trigger. The input pin of this other timer was pin PE5 on a Nucleo board. The nucleo documentation says this pin may be used. But since this pin may optionally be used as a trace pin, I decided to change the pin for PC12 which and this finally entirely removed the glitch