Generate a single pulse of 12ns with stm32u5

[lucascalam]

Hi there.

I’m trying to generate a 12 ns pulse for a time-of-flight (ToF) application.

I’m using an STM32U5 microcontroller, and I’d like to know whether one of the general-purpose timers (TIM2/TIM3/TIM4/TIM5) can produce a pulse that narrow. With a 160 MHz timer clock, the time resolution is about 6 ns, so in principle it seems feasible, but I may be overlooking something.

Thanks!

[Ozone]

I think you will need to get deeper into the reference manual of your MCU.
Most STM32 devices have a dozen or more timers, usually on different peripheral busses, while not all those busses support the same clock frequencies.
In most devices I worked with, the peripheral busses support only a maximum of core-clock/2.
I have no specific knowledge of STM32U5 devices, though.

[lucascalam]

hello @T_Hamdi , the frequency of the clock is set to 160MHz. 

I checked also the value with  LL_RCC_GetSystemClocksFreq().

Additonally, in the measurement I got the following: (see IMG_0794.jpeg).

 which shows that the period between pulse is 1.25us. In the code, I set the period to 200 ticks:

LL_TIM_SetAutoReload(TIM2, 200);

therefore, we can confirm that the frequency is properly set (otherwise, the period would be different not  1.25us).

I have no clue what might be causing this issue.

[LCE]

Looks at least that you're quite close with 62.5 ns (?).

Check the timer registers, compare to ref manual. Is the "compare" register really set to 2 (or does this have the typical +1, wouldn't make sense in this case...) ?

The basic timer functions like this are not to hard to do with direct register settings.

[waclawek.jan]

What's your hardware, a "known-good" board like Nucleo or Disco, or your own?

Do you measure directly at the PA1 pin? What is connected to that pin?

JW

[MM..1]

Preloading with one pulse mode is absurd, and too place in while 

LL_TIM_EnableCounter(TIM2);

[waclawek.jan]

Yes, they all are mistakes, but neither of them should result in cca 10x longer pulse.

JW

[MM..1]

Yes some tips: 

A. Clock for timer isnt 160 check

B. 

LL_TIM_SetOnePulseMode(TIM2, LL_TIM_ONEPULSEMODE_SINGLE);

Period 200 isnt used. Timer is stopped after CCR

C. while(1) restart it seems around 1us repeat

Clock for timer or full SYSCLK not start PLL right and run without it...

[LCE]

I was curious, can't remember to have used the timer for an output pulse.
Just working with a L073 at 32 MHz, so I programmed TIM3 to work at 32 MHz, with a 1 tick high output every 10 timer ticks - and I see the same on the scope.

/* 32 MHz timer,
 *	pulse output
 *	TEST only
 *	TIM3, output compare ch1
 *	-> PC6
 */
void TimPulseInit(void)
{
	/* peripheral clock enable */
	LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_TIM3);

	TIM3->CR1	= 0;
	TIM3->CR2	= 0;
	TIM3->SMCR	= 0;
	TIM3->CCER	= 0;
	TIM3->DIER	= 0;
	TIM3->SR	= 0;
	TIM3->EGR	= 0;
	TIM3->OR	= 0;
	TIM3->CNT 	= 0;

	TIM3->PSC	= 0;	/* max input clock */
	TIM3->ARR	= 9;	/* rep clock * 10 */

	/* 1 tick pulse length */
	TIM3->CCR1	= 1;
	/* 110 = PWM mode 1 */
	TIM3->CCMR1	= TIM_CCMR1_OC1M_2 | TIM_CCMR1_OC1M_1; // | TIM_CCMR1_OC1PE | TIM_CCMR1_OC1FE;
	/* enable output */
	TIM3->CCER 	= TIM_CCER_CC1E;

	/* TIM3 enable */
	TIM3->CR1  |= TIM_CR1_CEN;
}

Here's the UART output showing TIM registers in hex:

TIM3->
CR1  0001
CR2  0000
SMCR 0000
DIER 0000
SR   001F

PSC   0000
ARR   0009
CCR1  0001
CCMR1 0060
CCER  0001

[lucascalam · Accepted solution]

In the end, I realized I hadn’t been interpreting my results correctly. The pulse shown earlier in IMG_0794 was actually inverted, the relevant pulse was the low portion, not the high one. This means the pulse width was around 200 ticks.

This behavior occurs because, in the selected PWM mode combined with one-pulse mode, the output goes low when the counter transitions from TIMx_CCR to TIMx_ARR. Therefore, for example, if we want a 2-tick low pulse, setting CCR = 198 and ARR = 200 should produce the expected result.

Sorry for the confusion, and thanks to everyone for the support.

Cheers!

[waclawek.jan]

Oh, so the positive pulse was just a coincidental value between timer overflow/stop until code executing the function call and that call to execute. It must have been quite jittery, wasn't it?

JW