Configuring STM32F439 timer to pulse at specific counts.

EBDRS · ‎2024-06-19

I wanted to use the STM32F439 timers, any of them but timer 8 seems to be the best one with my current peripherals, to act as a trigger source. Basically, the timer would drive a pin low, and at specific counts of the timer, drive the pin high for ~50ns, then reset low. The counts that change the output would be software defined. The trigger would also be software defined. An external oscillator is used to ensure accuracy. The load should only be about 10 pF and 5.5 uA.

Would it be better to bit-bang the output with internal timers instead?

Michal Dudka · ‎2024-06-20

It is "pulse box". Importatnt question is what is acceptable minimum gap between pulses ? If about 20 clock ticks (130ns) then it can be done by timer in PWM mode with reconfiguration its periody by DMA. If gap must be shorter, then you will not be able to reconfigure timer "in time" and you have to go harder way.

With SPI you are able to create any pattern with your clock granularity (6.6ns), but in some cases you need to be clever, especialy in case of high number of pulses and long pulse patterns. You have limited memory space and in "brute force" SPI mode you need 1bit for every clock cycle. 22000 cycles long gap takes 2.75kB of RAM and in case of high number of pulses you can run out of memory. In that case you have to choose clever method. Use CPU to interpret data and load them into SPI manualy. Few years back one our student do something similar on FPGA (with 1ns resolution) but his used principle can be done even on MCU.

BTW: If you need more resolution you can choose STM with HRtimer and you will get resolution up to 0.3ns

Be please little more specific... how many pulses ? And minimal needed gap ?

View solution in original post

Melc_dB · ‎2024-06-20

Hello @EBDRS ,

Do I understand well? : When the software decides it launches the timer. The timer start counting X us, then rise output during 50us, then reset the output and wait for the next trigger. And X is programable.

If I am right, the good solution would be using Output Compare in one pulse mode with TIM OC Polarity Low.

Then program timing with:

TIM8->ARR (auto reload register)

TIM8->CCRX (capture compare register, channel X)

Hope that will help

Best regards

Melchior

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

EBDRS · ‎2024-06-20

The timer would be counting in the nanoseconds, or clocked with an oscillator at a specific frequency. The output would pulse with a rise, stay risen for 50ns or a specific amount of clock cycles, then drop again. This will happen multiple times. The space between each pulse is programmable.

Michal Dudka · ‎2024-06-20

It depends. If all pulses in one (n pulse) burst can have the same width and same period, then there is simple solution:
PWM mode with repetition counter.

If each pulse in "burst" should have different width or different period (space between pulses) or both, then it is more complicated You have to reconfigure timer parameters each period. That can be done by DMA, but still there are some minimal values for each single period (time needed to timer reconfiguration).

which one you need ?

waclawek.jan · ‎2024-06-20

> The timer would be counting in the nanoseconds

That would imply gigahertz clock. The 'F439 clock is max. 180MHz, the timer can't output pulses with better granularity than 1/180MHz.

> or clocked with an oscillator at a specific frequency

Which oscillator?

> The output would pulse with a rise, stay risen for 50ns or a specific amount of clock cycles, then drop again. This will happen multiple times. The space between each pulse is programmable.

This is what's called PWM, that's the basic property of timers.

> Would it be better to bit-bang the output with internal timers instead?

What do you mean by "bit-bang with internal timers", exactly?

I recommend you to read the Timer chapter in Reference Manual, and also get a cheap Disco or Nucleo board, and experiment, to understand what are the possibilities.

JW

EBDRS · ‎2024-06-20

> That would imply gigahertz clock. The 'F439 clock is max. 180MHz, the timer can't output pulses with better granularity than 1/180MHz.

The clock would be about 150 MHz, so several ns every clock.

> Which oscillator?

A crystal oscillator for accuracy, I am currently calculating the most accurate I can get with the internal dividers and multipliers.

> This is what's called PWM, that's the basic property of timers.

This is probably the way I am going to do it, and hopefully reprogram the period between cycles fast enough to not matter if it's inaccurate. Alternatively, I may use multiple output pins if possible; if tying the outputs together is dangerous, they are running straight into a level converter, so using diodes + a pulldown resistor is possible.

> What do you mean by "bit-bang with internal timers", exactly?

Basically, just control a GPIO and count the clock cycles between setting it to rise and fall, then count the clock cycles for the next pulse. In theory, if the delay for setting the GPIO is consistent, then it should negate itself; being off by a clock cycle or 2 is also ok.

> I recommend you to read the Timer chapter in Reference Manual, and also get a cheap Disco or Nucleo board, and experiment, to understand what are the possibilities.

Doing so, thank you.

EBDRS · ‎2024-06-20

The period would be different, but the width would be the same.

EBDRS · ‎2024-06-20

The frequency I want would be 149.855. I can get 149.856 with a 4.032 MHz crystal, and M = 3, N = 223, P = 2. The line would be ground until I want to send a pulse, then it would be high for 50ns, or ~7.5 cycles, rounded up to 8.

Looking more into it, I think the best option for me is to use an SPI connection. The max speed of the SPI is the system clock, which is 149.856, divided by 4 or 8 depending on which SPI I use. I could send null bytes until I want a pulse, then send a certain character depending on the pulse width and period. The character would either have 2 or 1 consecutive bits high, depending on which SPI I use. Approximately 3000 characters would be sent over the connection.

Does this seem like a viable option?

Melc_dB · ‎2024-06-20

Do you want to use the SPI peripheral to generate the pulse? T don't know why, but i don't think that is a good option, why not using Timer?

May be you could tell us more about the purpose of the pulses ?

Do you want to trigger each pulse or send bursts of multiple pulses ?

Do you want multiple identical pulses in a row or have each pulse potentially different ?

Is the exact number of pulse matter ?

Regards

Melchior

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

EBDRS · ‎2024-06-20

> Do you want to use the SPI peripheral to generate the pulse? T don't know why, but i don't think that is a good option, why not using Timer?

An SPI clocked at the correct speed seemed to be the closest thing to what I wanted. I would only use the MOSI signal from it.

> May be you could tell us more about the purpose of the pulses ?

I am simulating another device that is supposed to send ground until it pulses high at certain points for 50 ns. These points are random but measurable.

> Do you want to trigger each pulse or send bursts of multiple pulses ?

I want to trigger at specific counts of the clock cycles. So the first pulse may start at 20 clock cycles, then the second would be 2000, then 50, etc.. The high portion of the pulse is 50 ns, or about 8 clock cycles, long.

> Do you want multiple identical pulses in a row or have each pulse potentially different ?

Each pulse is identical in the width of the high, but different in the width of the low.

> Is the exact number of pulse matter ?

Yes.

I have attached a picture of what I wanted to do. Basically, for at least 22000 clock cycles of a 149.855 MHz clock, the MCU would output a pulse of a high signal high for 8 cycles, then have a low signal of programmable, varying width. The number of high pulses and all low widths would be known ahead of time.