STM32H7 triggering ADC with TIM6 TRGO

[n2wx]

The ADC (ADC3 if that's relevant) provides for triggering by way of the TIM6 TRGO event. I have the ADC configured to convert with "ExternalTrigConv" pointing to ADC_EXTERNAL_TRIG_T6_TRGO, and the update event's rising edge. In no case am I able to get the thing to trigger though, not off of TIM6, only by software conversion start. I'm sure TIM6 is firing because when I intercept its ISR it's running on time, it's just not triggering the ADC.

The errata for the 32F4xx suggests that one has to enable the DAC RCC clock domain for it to work. This doesn't help on the H7 (and it's not mentioned in the H7 errata).

Has anyone managed to use TIM6 to trigger conversions of the ADC? I can start the s/w conversion in a roundabout way (roundabout because of the HAL locks if I do stuff in ISRs) after TIM6 fires its ISR but I'd rather not couple things so closely.

TIM6 when it's mentioned in the docs is always in relation to the DAC and not the ADC so I wonder if the connection just doesn't exist on the H7 part. Anyone? TIA

[berendi]

I thought you are using DMA, and don't need the interrupt. Of course if you want an interrupt, go clear the flag. If the interrupt is not enabled, no need to clear the flag.

[n2wx]

I'm an old time LL user under a different username and employer, it gives me a sad that HAL is still sick it seems to get worse with every iteration. A plethora of examples using LL (I like some abstraction, LL gets it just right) is really needed and would be mostly portable across the stm32 product line.

Much like this site and its cosmetic changes that slow my browser down and make using the site more difficult the HAL mods while made in good faith detract from the experience and are ill-taken but it's hard to get that point across.

[n2wx]

I am using DMA but I don't want to keep reading stale data in the foreground. Would you do it differently?

For my purposes I find it a better practice to deal with an end of sequence event with an interrupt so I can concentrate my foreground cycles on other stuff, periodically (because I still have HAL peripherals) looking for a "done" flag rather than copying and massaging an array of conversions every time through the superloop.

[berendi]

I'm not against interrupts at all, I've just read here that you are using DMA, and assumed that you won't need both. But I don't know anything about the structure or requirements of your application, so I can't say how I would do it. It depends on the application at hand.

In general, I prefer DMA to interrupts, because the timing aspects are more efficient and predictable. DMA itself has flags and a counter register that can be polled in the main loop, and it doesn't steal a lot of cycles from the CPU. Of course it is valid only as long as the data doesn't need immediate processing.

[n2wx]

Oh I wasn't sure where you were going with this. I'm trying to minimize polling since most polls will be wasted when I'm converting at only 100hz. When I get the interrupt I grab the array containing 6 DMA'd conversions from joysticks and knobs and send them in an IPC message to a function that waits on these messages and turns them into values I send over a radio. The executive that handles message queue dispatching is heavily optimized and I'd lose the advantage of using it if I hook polling code into the superloop. My fault, you couldn't be familiar with the way I have this architected and I didn't mention that it's written around a message queue-oriented executive.

[berendi]

Of course, putting data into a message queue qualifies as "need immediate processing".

[n2wx]

The time-critical bit is actually done when the EOS interrupt happens and I queue the message: The queueing step is when the executive memcpy's the conversion array away from the DMA destination. I share the processor with the vendor's code and he may occupy the processor for more than 20ms so I kind of have to do it this way to keep the samples together and uncorrupted.

The message queue itself doesn't run in a time-critical way, it's services from the superloop in the foreground and could be delayed by everything else in the system. If that happens the user experience deteriorates because the other side of the radio link really would like to have data every 20ms...

[ADunc.1]

Did you ever get this working? I am having the same problem on an STM32H753, using TIM1 and ADC1. The ADC works correctly using software triggering, the PWM output is working on the timer, but no combination of trigger options will begin a conversion under hardware trigger! I used this same feature on an L4 to synchronize ADC measurements with PWM, but I cant for the life of me get it to work on the H7!

[berendi]

Yes, this is working, tested.

[n2wx]

I understand your frustation. It worked perfectly for me with an F303. I did not get it working though and to make it more challenging I was off by one and was actually using TIM7 everywhere (but they're still basic timers on the H743). Nevertheless I couldn't get it to work and I ran out of time to try to use the solution @berendi​ offered. I'm fortunate though because my analog signals are from joysticks and the human won't notice microsecond level software-induced jitter. I'd be losing it though if I was doing DSP and trying to capture real world waveforms.