STM32F746: ADC3 does not work with external trigger from timer

[SFahr]

Hi,

I made project that samples audio signals from the ADC at a constant rate. The trigger signal for the ADC conversion is generated by a timer.

Now here's the thing:

The code works fine on my STM32L432 Nucleo, STM32L4R5 Nucleo and STM32F429 Disco, but it does not work with the STM32F746 Disco. It looks like the trigger signal from the timer does not get through to ADC3, because I can work-around by using ADC_SOFTWARE_START and start the conversion manually by setting the SWSTART-Flag in the Timer ISR (in this case everything works fine again).

I checked the Timer and ADC registers with the debugger and their content appears to be correct, I also tried several different timers, but to no avail.

A major difference is that all other MCUs use ADC1 where as the STM32F746 uses ADC3 (as only its inputs are available).

The ADC3 trigger input is configured like this:

	hadcx.Init.ExternalTrigConv 		= ADC_EXTERNALTRIGCONV_T4_TRGO;
	hadcx.Init.ExternalTrigConvEdge 	= ADC_EXTERNALTRIGCONVEDGE_RISING;		

The timer output trigger signal TRGO is configured like this:

	sMasterConfig.MasterOutputTrigger 	= TIM_TRGO_UPDATE;
	sMasterConfig.MasterSlaveMode 		= TIM_MASTERSLAVEMODE_ENABLE;

Any ideas?

[SFahr]

Just found out:

It does not work with TIM4, TIM5 and TIM6, but it does work with TIM1.

It seems like there are some limitations that are not documented.

[waclawek.jan]

Hard to tell from your description, but maybe this erratum

The workaround for  TIM2/TIM4/TIM5/TIM6 is charming and I wonder how does it work...

JW

[SFahr]

Thank you very much for your answer.

As it turns out I had actually downloaded the wrong Errata sheet (for STM32F76xxx instead of STM32F74xxx).

Nevertheless I just tried these workarounds, but they didn't help.

But since it is working now with TIM1 I'm okay with that.

Thanks again.

[waclawek.jan · Accepted solution]

Many errata are written badly - they often omit describing root of the problem or describe it only very vaguely (probably because of guilt/shame), and the workarounds are often incorrect or improperly described with missing vital details (that's poor sloppiness, I guess errata are written by the design engineers who don't have proper application experience and are too proud to ask for applications engineers for help/review/feedback. The culture of pushing Cube, i.e. hiding the real problem by adding mysterious steps in "libraries" instead of properly describing the problem and workaround, is certainly part of the problem.

In this particular case, it appears to be that for the workaround to work you need to enable DAC clock before ADC clock. I can imagine that both DAC and ADC share a common timer-trigger-resynchronizer block, which may go like "after DAC or ADC clock enabled, wait until the next APB clock edge, and start the synchronization machine from there", with bug in the "after DAC or ADC clock enabled" part, working only if DAC is enabled first.

[EDIT] Uhm, no, the Cube example does it just before starting the timer. The underlying principle may be similar, though.

Also, I had a faint recollection, I've read about this already, somewhere... and, indeed... :)

JW

[SFahr]

Enabling the DAC clock actually did the trick!

(So I got me the wrong errata sheet and when I got the right one, I made some mistake when I tried to implement the workaround... now that's worth some guild and shame).

Thanks a lot!

[Amel NASRI]

Hi @SFahr​ ,

Thanks to @Community member​ , this issue is brought to my attention. I confirm it on my side and tracked it internally waiting for an official implementation of the workaround in STM32CubeMX generated code.

Internal ticket number: 146065 (This is an internal tracking number and is not accessible or usable by customers).

-Amel

[waclawek.jan]

Thanks, Amel.

Jan

@Amel NASRI​ 

[Amel NASRI]

Tracked issue fixed in STM32CubeMX 6.9.0.