STM32F0 timers and adjustable delay before DMA burst

[Psi]

I'm trying to figure out the best way to have an adjustable delay, like 2sec to 40us and then a 10us burst of DMA to GPIO and then repeat forever (delay again and dma burst).  It needs to be all done in hardware as the timing between the DMA bursts is critical. The delay will be adjusted in main() along with writes to the memory being used for the DMA copy.
The issue is that a 16bit timer is too small drive that DMA and do a delay that long.
And, importantly there are 4 of these running at once.  So 4 timers doing DMA.
The adjustable delay is unique to each of the 4 timers.

I tried using a 5th timer with 4 compare events to trigger these 4 timers but I couldn't see a way on STM32F072 to do that in hardware. When I tried to trigger the 4 other timers in the 5th timer compare match interrupt the timing was too glitchy.

I could physically link the 4 output compare pins on that 5th timer to the input pins on each of the 4 individual timers, but I'm not sure that helps me start DMA transfers like that.

I've had a look at a few other MCU options, STM32F3's, but I'm not entirely sure what I'm looking for in terms of getting 4 compare matches on a single timer to be an individual TRGO trigger for 4 other timers to start DMA. I can see OCnREF can be used as TRGO but i would need all of them active at once. OC1REF OC2REF OC3REF OC4REF to their own timers and that doesn't look possible  (i'm probably missing something).

ChatGPT isnt getting me anywhere. If anyone has any tips I would be grateful.
Thanks.

[aeg]

How about a fine timer free running continuously with 1us rate and 64ms period, triggering the DMA, and a coarse timer with 32ms period triggering an interrupt that arms the fine timer's compare event? Timing is still set by the fine timer, the ISR only decides whether there will be a DMA burst this period.

Or have another DMA channel loading the timer's compare / duty cycle values.

I don't know the STM32F0 timers off hand so I don't know how practicable this is.

Might need to have different modes of operation for long and short delays.

[Psi]

How about a fine timer free running continuously with 1us rate and 64ms period, triggering the DMA, and a coarse timer with 32ms period triggering an interrupt that arms the fine timer's compare event? Timing is still set by the fine timer, the ISR only decides whether there will be a DMA burst this period.

Hm. yeah, maybe. That is worth investigating. I will map it out on paper.

I need to get my head around how the slower timer would ensure it always triggers with enough time to figure out if a DMA is needed in the next timer cycle and arm the DMA before it's needed.
It might need some intelligence to set compare match interrupts to ensure it always has enough time.

[Psi]

Actually yes, i think that might work.
Because you can set the compare channel for DMA in the previous cycle as long as its after the point when it would incorrectly arm with the current cycle.
So as long as you check often enough you should have plenty of time to set it.

Will have a play around with it. I think that should work on my existing STM32F0.

[Psi]

Hm.. sadly I don't think this approach works. You still need a timer to clock the DMA.
So you'd need 4 timers + a fast timer + a slow timer.
I have enough timers, but you need to link them in hardware so 4 compare matches on the fast timer trigger the 4 other timers to start their DMA transfer, and as far as I can see that isn't possible.   
If i wasn't already doing 4 DMA transfers already I could setup DMAs on each of the compare matches to DMA copy a bit to a register to simply trigger the other 4 timers, but that is too much DMA. Not enough channels.

[az1]

First thing that comes to mind is doing this with an RP's PIO unit.

But since I've been living in Renesas land for a bit, the RA's PWM timers get you six compare+match interrupts each and each interrupt can be bound to its own DMA (DTC) channel + however many dedicated DMA channels.  The RA4M1 (Arduino) gets you 2x 32-bit PWM timers, and 6x 16-bit PWM timers, and 2x 16-bit slower low power timers.  The RA6M5 (Sparkfun Thing+) gets you 4x 32-bit and 6x 16-bit PWM timers and 6x 16-bit LP timers.

Or with STM32, depending on what kind of DMA chaining is available you could simply line up a series of no-op transfers until you get to the coarse delay.

[Psi]

Or with STM32, depending on what kind of DMA chaining is available you could simply line up a series of no-op transfers until you get to the coarse delay.

heh, its a cool idea, but the fact that I have 4 DMAs going at once at only 1 DMA controller means I can't keep one copying zeros to add a delay.

I'm going to have a play tomorrow with a STM32F407 dev board that I have.

I could do it with the STM32F072 by externally connecting 4 compare outputs to the trigger input of the 4 timers doing DMA.
But i would have to chain two 16bit timers together and it would get messy for other reasons.
So my currently plan is probably switching to a STM32F407 or similar once i prove out the concept on the dev board.

STM32F407 has two 32bit timers which is good for other aspects of the project. And i can already see that i may run out of memory space on the SMT32F0 before the project is done. So i think moving to something bigger/better now is probably a good idea.

[aeg]

OK, if I understand correctly, you're using a timer to generate the DMARQ to clock the GPIO writes, but you also need timing to kick off the burst.

For 40us burst interval, could you construct a 50us buffer that contains the 10us burst + 40us of silence, and run the DMA continuously in circular mode?

For 2sec burst interval, could you construct a 1ms buffer that has 990us of silence + the 10us burst at the end, run the DMA continuously in circular mode, then use the DMA wrap interrupt to refresh the end of the buffer with either the burst or silence depending whether there's another upcoming burst?

[Psi]

if I understand correctly, you're using a timer to generate the DMARQ to clock the GPIO writes, but you also need timing to kick off the burst.

The timer update event triggers DMA clocking which writes a word to GPIO. And there's 4 of those running.

For 40us burst interval, could you construct a 50us buffer that contains the 10us burst + 40us of silence, and run the DMA continuously in circular mode?
For 2sec burst interval, could you construct a 1ms buffer that has 990us of silence + the 10us burst at the end, run the DMA continuously in circular mode, then use the DMA wrap interrupt to refresh the end of the buffer with either the burst or silence depending whether there's another upcoming burst?

The DMA transfer is around 33khz so you'd need 132KB of mostly empty memory per timer to DMA that.

A free running timer with 4 compare channels hardwired externally to 4 timer inputs to trigger them doing the DMAs seems like the easiest option.
Everything should stay in sync automatically, but it means the free running timer needs to be 32bit.

[pcprogrammer]

I have not checked against real hardware, but with the delay being set in the main loop, is adjusting the timer settings including the prescaler not an option to do the 40us up to the 2s trigger for the DMA.

In my project here: https://github.com/pecostm32/STM32F303_Sine_Square_Generator I use DMA to make the square and the sine waves. In the main loop the settings are adjusted to change the phase between the signals.

[Psi]

I have not checked against real hardware, but with the delay being set in the main loop, is adjusting the timer settings including the prescaler not an option to do the 40us up to the 2s trigger for the DMA.

You'd need 8 timers to do that.  4 for the DMAs and another 4 to trigger them.
Changing the timer settings to adjust the delay would make them specific to that DMA transfer.
I'm also not sure if charging the timer settings while active causes clocks to be skipped during the change over. So could have small sync issues.

[aeg]

The DMA transfer is around 33khz so you'd need 132KB of mostly empty memory per timer to DMA that.

Typo for 33MHz? 33kHz is 30us per cycle, which is greater than 10us.

[az1]

I still suspect you'll have an easier time with an RP, but if you're tied to STM a couple of the new H5s have a "PLAY" their programmable logic peripheral.

If you're okay with DMA contention (and with the F072 I assume you are), on an RA I'd do (per instance):

- Set GPTn (PWM timer) to saw tooth mode
- Set up DMAC memory-to-GPIO transfer, start on GPTn compare A
- Set up DTC:
  - Activate on GPTn overflow
  - Stop DMAC xfer
- Start GPTn.
- Update compare A and overflow values as needed.

That would take one PWM timer, one DMAC channel, and one interrupt per instance.  If you want to use 16-bit timers you should be able to chain them with or without an interrupt handler.

I'd also give some thought to what you're outputting.  If you can generate it with a PWM timer or DAC (on any platform) that would give you a good route to sidestep DMA contention.

[Psi]

Cant use a Raspberry Pi as this is an actual product.

I think this will work fine on the STM32F4 that i'm playing with atm.

[Psi]

The DMA transfer is around 33khz so you'd need 132KB of mostly empty memory per timer to DMA that.

Typo for 33MHz? 33kHz is 30us per cycle, which is greater than 10us.

Yeah, i'm still playing around with the values and seeing what works and what's needed.

[pcprogrammer]

I have not checked against real hardware, but with the delay being set in the main loop, is adjusting the timer settings including the prescaler not an option to do the 40us up to the 2s trigger for the DMA.

You'd need 8 timers to do that.  4 for the DMAs and another 4 to trigger them.
Changing the timer settings to adjust the delay would make them specific to that DMA transfer.
I'm also not sure if charging the timer settings while active causes clocks to be skipped during the change over. So could have small sync issues.

Does the DMA not have a free running option? Have a timer run in a set loop of the needed interval (40us to 2s) and when it triggers the reload, it also triggers the DMA to, in one go, send so many words of data to the GPIO's. The pace of the DMA would be determined by the memory and bus speed, but I'm not sure if it is guaranteed and jitter free.

This way you only need 4 timers and 4 DMA channels.

[Psi]

I have not checked against real hardware, but with the delay being set in the main loop, is adjusting the timer settings including the prescaler not an option to do the 40us up to the 2s trigger for the DMA.

You'd need 8 timers to do that.  4 for the DMAs and another 4 to trigger them.
Changing the timer settings to adjust the delay would make them specific to that DMA transfer.
I'm also not sure if charging the timer settings while active causes clocks to be skipped during the change over. So could have small sync issues.

Does the DMA not have a free running option? Have a timer run in a set loop of the needed interval (40us to 2s) and when it triggers the reload, it also triggers the DMA to, in one go, send so many words of data to the GPIO's. The pace of the DMA would be determined by the memory and bus speed, but I'm not sure if it is guaranteed and jitter free.

This way you only need 4 timers and 4 DMA channels.

I'm not sure that i understand what you mean.
The DMA copies are clocked by the timer events, not by the clock that runs the timer.

[az1]

Cant use a Raspberry Pi as this is an actual product.

I think this will work fine on the STM32F4 that i'm playing with atm.

Doesn't have to be Raspberry Pi.  Renesas stuck DTC and EventLink in just about everything (RA, RX, etc), NXP's FlexIO made it into tons of products (Kinetis, S32K, and MCX), and STM's got "PLAY" on their newest H5s.  A potentially big advantage is that you'd avoid whatever overhead is associated with an interrupt handler (which is part of what's causing your jitter).

In case it got lost in the acronym salad, the example I gave was for the Renesas RA.  Another option there would be to eschew interrupts altogether and have your timer's output waveform defined by one capture value (and optionally another compare value) and enabled based upon another compare value (on the same timer or a different one).  No interrupts and no DMA bus contention should cut down on the jitter dramatically.

On the Pi you'd do something like this (which is just way more elegant than beating some archaic timers into submission):

https://www.digikey.com/en/maker/projects/raspberry-pi-pico-and-rp2040-cc-part-3-how-to-use-pio/123ff7700bc547c79a504858c1bd8110

And in STM land:

https://www.st.com/resource/en/application_note/an6401-introduction-to-programmable-logic-array-play-for-stm32-mcus-stmicroelectronics.pdf

I'm not sure that i understand what you mean.
The DMA copies are clocked by the timer events, not by the clock that runs the timer.

I think the idea was to have the compare interrupt start the DMA xfer and let the size of the xfer determine the duration.  The number of transfers you'd fit into a period of time is dependent upon the DMA clock speed.

[pcprogrammer]

I have not checked against real hardware, but with the delay being set in the main loop, is adjusting the timer settings including the prescaler not an option to do the 40us up to the 2s trigger for the DMA.

You'd need 8 timers to do that.  4 for the DMAs and another 4 to trigger them.
Changing the timer settings to adjust the delay would make them specific to that DMA transfer.
I'm also not sure if charging the timer settings while active causes clocks to be skipped during the change over. So could have small sync issues.

Does the DMA not have a free running option? Have a timer run in a set loop of the needed interval (40us to 2s) and when it triggers the reload, it also triggers the DMA to, in one go, send so many words of data to the GPIO's. The pace of the DMA would be determined by the memory and bus speed, but I'm not sure if it is guaranteed and jitter free.

This way you only need 4 timers and 4 DMA channels.

I'm not sure that i understand what you mean.
The DMA copies are clocked by the timer events, not by the clock that runs the timer.

I think the idea was to have the compare interrupt start the DMA xfer and let the size of the xfer determine the duration.  The number of transfers you'd fit into a period of time is dependent upon the DMA clock speed.

What az1 wrote is basically what I mean. Only instead of a compare trigger the DMA, it is the timeout that triggers it. (Update interrupt)

 If I remember correctly there is a way of doing this with the STM32F103 DMA, but the details have escaped me.    Now looking at the DMA section in the reference manual (RM0091) for the F0 range, it seems to have it too and needs the MEM2MEM bit set. Not sure if it is possible to do this from memory address to peripheral address. Only issue with this that the DMA needs to be reset after it ends, so an interrupt handling on DMA finish is needed.

[Psi]

The problem is that the timing between each DMA burst needs to be fixed as well as the timing relationship between one DMA to all the others.
So as soon as you introduce an interrupt to reset/restart anything you risk introducing a few missing clocks.
I'm not entirely sure how much of this timing error I can tolerate so I'm aiming for zero atm.

[pcprogrammer]

The problem is that the timing between each DMA burst needs to be fixed as well as the timing relationship between one DMA to all the others.
So as soon as you introduce an interrupt to reset/restart anything you risk introducing a few missing clocks.
I'm not entirely sure how much of this timing error I can tolerate so I'm aiming for zero atm.

Based on that, a FPGA looks much more suited for the job.

Even with triggering a DMA channel from a timer, there is no absolute guarantee on how much delay there is before the DMA transaction is executed. When two or more DMA transactions are triggered at the same time, the priority order of the DMA channels makes it that the highest one in the row is executed more or less directly and the next one is delayed, and so on.

With a FPGA you can get it all done in parallel and be assured of correct timing.

[az1]

The problem is that the timing between each DMA burst needs to be fixed as well as the timing relationship between one DMA to all the others.
So as soon as you introduce an interrupt to reset/restart anything you risk introducing a few missing clocks.
I'm not entirely sure how much of this timing error I can tolerate so I'm aiming for zero atm.

If you had everything working tolerably on the F0 your timing requirements aren't as rigid as you think.  With DMA concurrent requests mean you're going to have bus contention – only one transfer can run at a time.  Multiple DMA controllers won't solve this because they're typically sharing the same bus.

A programmable logic peripheral may give you better timing guarantees (but you'd have to look at the bus matrix to see how it all fits together).  If you can fit all of your logic into a timer you avoid all of that because the timer will operate on the pin directly.  And of course an FPGA gives you the best guarantees.

[Jeroen3]

I once did create a multiplexed 7-segment driver with SPI IO-expander fully with timers and DMA, in the F072.
I think I did this by chaining three timers together. You can try this, it will be a fun puzzle.
_{(commercially it makes no sense spending the time to find errata in the F072 timer chaining)}

The mention of using a raspberry pi is valid here i think. The RP2040 has those small configurable hardware parts that you may be able to utilise for this?
Otherwise, just get a dedicated RP2040 

Or, you get one of those dual core parts. I also once put the multiplexing array logic in the co-processor in one of those dual core NXP parts.

[Psi]

The problem is that the timing between each DMA burst needs to be fixed as well as the timing relationship between one DMA to all the others.
So as soon as you introduce an interrupt to reset/restart anything you risk introducing a few missing clocks.
I'm not entirely sure how much of this timing error I can tolerate so I'm aiming for zero atm.

.. your timing requirements aren't as rigid as you think... 

Yeah, i'm just trying to make it as good as it can be before in-field testing. I don't think a FPGA is needed.
the speed of a DMA operation should be fast enough even if there's a tiny delay where one DMA has to wait for another.

Ive almost got it working on a SMT32F407.  One 32bit timer using 4 compare channels to trigger 4 other timers to do a burst of DMA.
Timing should remain in sync as the 32bit timer will just run continuously and updates to compare channels can be done in the background to get precise delays between the DMAs

[Psi]

FFS, CubeMX you piece of shit.

I've been banging my head against a wall all day trying to figure out why DMA channel 3 callbacks and ints wont fire and keeps hanging the cpu.
And then I find this in my startup_stm32f072vbtx.s file that cubeMX generated.

Why on earth would it generate the file with only 1 DMA handler functional and the other two like this?  Reserved for what.

I put the correct handler names in there and now my problem is fixed.

Code: [Select]

  .word WWDG_IRQHandler                /* Window Watchdog interrupt                             */
  .word PVD_IRQHandler                /* PVD and VDDIO2 supply comparator interrupt            */
  .word RTC_IRQHandler                /* RTC interrupts                                        */
  .word FLASH_IRQHandler              /* Flash global interrupt                                */
  .word RCC_CRS_IRQHandler            /* RCC and CRS global interrupts                         */
  .word EXTI0_1_IRQHandler            /* EXTI Line[1:0] interrupts                             */
  .word EXTI2_3_IRQHandler            /* EXTI Line[3:2] interrupts                             */
  .word EXTI4_15_IRQHandler            /* EXTI Line15 and EXTI4 interrupts                      */
  .word TSC_IRQHandler                /* Touch sensing interrupt                               */
  .word DMA1_CH1_IRQHandler            /* DMA1 channel 1 interrupt                              */
  .word 0                              /* Reserved                                              */
  .word 0                              /* Reserved                                              */
  .word ADC_COMP_IRQHandler            /* ADC and comparator interrupts                         */
  .word TIM1_BRK_UP_TRG_COM_IRQHandler /* TIM1 break, update, trigger and commutation interrupt */
  .word TIM1_CC_IRQHandler            /* TIM1 Capture Compare interrupt                        */
  .word TIM2_IRQHandler                /* TIM2 global interrupt                                 */
  .word TIM3_IRQHandler                /* TIM3 global interrupt                                 */
  .word TIM6_DAC_IRQHandler            /* TIM6 global interrupt and DAC underrun interrupt      */
  .word TIM7_IRQHandler                /* TIM7 global interrupt                                 */