STM32H733 TIM ETR reduces input clock level

[LCE]

Heyho,

and one more problem with my custom board with a STM32H733ZGT6 (LQFP-144, almost same as H723 on Nucleo).

I'm using TIM5 for input capture, with CH1 (GPIO A0) and ETR (A4) as external clock input.

The setup code is the same as on H723-Nucleo and H735-Disco, although I'm using another input capture channel, on these boards all is working fine.

Problem:

the 50 MHz input clock on ETR drops to < 2Vpp at the STM32 pin.

Clock signal comes from VCO with 3.3Vpp, has 33R at output, and the ETR pin also has a 33R serial resistor.
Voltage drops at each resistor.

The same clock signal is routed to other IOs, also via 33R, no voltage drop there.

All connections and resistor values checked and okay.

Here's the timer setup, same as on working ST boards:

void TimVcoSyncInit(void)
{
	GPIO_InitTypeDef GPIO_InitStruct = { 0 };

	/* set handle and pointer
	 *	### THIS depends on used TIMx ###
	 *		eTAS8: TIM5
	 */

	__HAL_RCC_TIM5_CLK_ENABLE();

	pTimVcoSync 	= TIM5;
	hTim5.Instance 	= pTimVcoSync;

	hTimVcoSync.Instance = pTimVcoSync;

	/* register reset */
	pTimVcoSync->CR1	= 0;
	pTimVcoSync->CR2	= 0;
	pTimVcoSync->SMCR 	= 0;
	pTimVcoSync->CNT 	= 0;
	pTimVcoSync->DIER	= 0;				/* no interrupts, DMA set later */
	pTimVcoSync->SR		= 0;

	pTimVcoSync->PSC	= 0;				/* max = 1/2 CPU clock */
	pTimVcoSync->ARR	= 0xFFFFFFFF;		/* auto-reload */

	pTimVcoSync->EGR	= 0;
	pTimVcoSync->CCMR1	= 0;
	pTimVcoSync->CCMR2	= 0;
	pTimVcoSync->CCMR3	= 0;
	pTimVcoSync->CCR1	= 0;
	pTimVcoSync->CCR2	= 0;
	pTimVcoSync->CCR3	= 0;
	pTimVcoSync->CCR4	= 0;
	pTimVcoSync->DCR 	= 0;
	pTimVcoSync->DMAR	= 0;

/* ECE external clock mode 2, divide by 2 if clock > 25.6 MHz
 * external clock prescaler ETPS[1:0] depends on CPU clock / I2S clock:
 *		"External trigger signal ETRP frequency must be
 *		 at most 1/4 of CK_INT frequency."
 */
	pTimVcoSync->SMCR = TIM_SMCR_ECE;
	/* sync clock frequency is 51.2 MHz -> divider ON */
	pTimVcoSync->SMCR |= TIM_SMCR_ETPS_0;

/* input capture TIM5 channel 1
 */
	pTimVcoSync->CCMR1	 = TIM_CCMR1_CC1S_0;	/* channel 1 input capture */
	pTimVcoSync->CCER	 = TIM_CCER_CC1E;		/* channel 1 capture enable */

/* Configure GPIO pins : Timer 5
 *	PA4		----> ETR 	-> external clock 	-> VCO / audio clock
 *	PA0		----> Ch1 	-> input capture	-> PTP PPS
 */

	GPIO_InitStruct.Mode 		= GPIO_MODE_AF_PP;
	GPIO_InitStruct.Pull 		= GPIO_NOPULL;
	GPIO_InitStruct.Speed 		= GPIO_SPEED_FREQ_VERY_HIGH;

	GPIO_InitStruct.Pin 		= TIM5_ETR_Pin;
	GPIO_InitStruct.Alternate 	= GPIO_AF2_TIM5;
	HAL_GPIO_Init(TIM5_ETR_GPIO_Port, &GPIO_InitStruct);

	GPIO_InitStruct.Pin 		= TIM5_CH1_Pin;
	GPIO_InitStruct.Alternate 	= GPIO_AF2_TIM5;
	HAL_GPIO_Init(TIM5_CH1_GPIO_Port, &GPIO_InitStruct);

// timer & DMA enabled later with:
	/* timer DMA request enable, counter reset */
	pTimVcoSync->DIER = TIM_DIER_CC1DE;

	pTimVcoSync->CNT = 0;

	/* TimVcoSync enable */
	pTimVcoSync->CR1 = TIM_CR1_ARPE | TIM_CR1_CEN;

[LCE]

Now it's getting crazier, but I'm just guessing that the above problem might be related to the next:

The pin next to TIM5_ETR = PA4 in H733 / LQFP-144 is DAC1_OUT2 = PA5.

And PA4 can also be used as DAC1_OUT1.

Strangely, DAC1_OUT2 = PA5 is not working, showing a constant level of ~0.7V, which is the same offset I see now on the clock input TIM5_ETR = PA4.

I have checked the board, there is no connection between the pins or traces.

All working on Nucleo H723 and H735 Disco...

[waclawek.jan]

> All working on Nucleo H723 and H735 Disco...

Have you tried to enable the DAC on PA5 and TIMx_CHx on PA4 there?

Disconnect the 33R resistor leading to PA4. Any difference in DAC working?

Read out and check/post GPIOA and DAC registers content.

JW

PS. VDDA and all other power pins and grounds are connected properly?

[Michal Dudka]

Clarify your measurment method. Ordinary scope probe have 10pF capacitance in 1:10 configuration and 50pF in 1:1 configuration. That capacitance forms low pass filter with you 33R+33R=66R series resistance and lowering amplitude to 2.7V in case of 10pF or to 1.6V in case of 50pF. Moreover any another capacitance (trace parasitic etc.) have similar effect.

[LCE]

I have a direct comparison, the same clock goes via a 50R resistor to I2S_CKIN, that signal looks as it should, 0 .. 3.3 V. And that trace is even longer.

[AScha.3]

>PA5 is not working, showing a constant level of ~0.7V, which is the same offset I see now on the clock input TIM5_ETR = PA4

So power off and find the short...check with DMM or so.

IF no short - make simple test program: toggle PA5 hi-lo-... , does it 0...3v3 ?

(+ what happens on PA4 then ? )

[waclawek.jan]

Oh, and how's VDDA connected and what's its voltage?

JW

[LCE · Accepted solution]

Welcome to LCE's most *** and simple mistake until now, both killing the clock input and making the DAC (channel 2) not work:

	/* enable DAC, DC output, no trigger, no DMA */
	DAC1->CR |= DAC_CR_EN1;

 I thought I had checked and adapted everything to the new PCB using DAC channel 2 - but I forgot that each DAC channel has its own channel ENABLE bit.
So setting bit DAC_CR_EN2, and oh wonders still happening:
- the DAC is working
- the clock, using the same pin as DAC channel 1 would be on, has no more level loss

Still maybe some new interesting insight, at least for me:

Even when the DAC's GPIO is NOT configured for the DAC, or configured as some other alternate function, enabling the DAC channel still has some effect on the unused GPIO.

Thanks guys for your help!

And because it's such a complicated peripheral, here's how you set up the H7 DAC without any extras, so nice and simple: 😉

void DacInit(void)
{
	GPIO_InitTypeDef GPIO_InitStruct = { 0 };

	/* Peripheral clock enable */
	__HAL_RCC_DAC12_CLK_ENABLE();

	GPIO_InitStruct.Pin 	= DAC_OUT_Pin;
	GPIO_InitStruct.Mode 	= GPIO_MODE_ANALOG;
	GPIO_InitStruct.Pull 	= GPIO_NOPULL;
	HAL_GPIO_Init(DAC_OUT_GPIO_Port, &GPIO_InitStruct);

	/* DAC direct register settings */
	DAC1->CR = 0;

	/* reset right aligned 12 bit registers */
	DAC1->DHR12R1 = 0;
	DAC1->DHR12R2 = 0;

	/* enable DAC, DC output, no trigger, no DMA */
	DAC1->CR |= DAC_CR_EN2;
}

Mind the correct channel! 😉

[waclawek.jan]

Thanks for coming back with the solution.

> most *** and simple mistake

I make such mistakes by the dozen. They are IMO as inevitable as software bugs. One should strive to be prepared for them (i.e. have a toolbox of things to try at hand), and to learn from them.

> Even when the DAC's GPIO is NOT configured for the DAC, or configured as some other alternate function, enabling the DAC channel still has some effect on the unused GPIO.

ST generally fails to document these surprising connections properly. The DAC output in some (all?) STM32 is connected *directly* to the pin, in parallel with the GPIO matrix. This is often (always?) the case with the functions which are in the "Additional functions" in the pin table in Datasheet; although sometimes they override the GPIO (and sometimes they are not even properly marked as such, e.g. the USB pins in 'F4).

JW

[LCE]

> I make such mistakes by the dozen. They are IMO as inevitable as software bugs.
> One should strive to be prepared for them (i.e. have a toolbox of things to try at hand),
> and to learn from them.

Yes, same here, and nothing new...

Only the first thought is usually "OMG, I'm sooo stooopid", but afterwards I'm quite happy that things are working well by changing only 1 bit! :D