Adc start conversion on Tim1_CC4 (Input capture compare) doesn't work.

[SCass.3]

Adc start conversion on Tim1_CC4 (Input capture compare) doesn't work.

I'm using STM32G051k8, Input capture compare works fine on Tim 1 Ch4 (I @read a correct input value) but doesn't generate an Adc start events.

Can you help me?

Thank you in advanced.

Best regards 

[Michael E]

Hello @Community member​ ,

Maybe this wiki article on ADC topic can help you

Regards

Michael

[SCass.3]

Hello Hello Michael I read the wiki article but the problem persist.

The Ch4 of Timer 1 when is configured in input capture compare mode doesn't trigger a Adc start. If I configure the external trigger of adc as TIM1_TRGO2 (Reset,gated etc.) there aren't any problems Adc start the conversion.

If I move the setting of external trigger to TIM1_CC4 the adc doesn't trigger a conversion even if the Tim1 Input capture compare is working regular because the irq of capture compare in tim1 is active and i can read correctly a value on the TIM1_CCR4 register.  

Do you have any suggestion?

Regards

Stefano

[waclawek.jan]

This is most probably case of incorrect documentation and the ADC is *not* triggered by TIMx_CCx event, but the TIMx_OCx signal, i.e. the signal which goes to the output pins from the Output stage of given TIMx channel.

This has several ramifications:

• TIMx_CHx Input Capture does not work as a trigger, only Output Compare
• output of given channel must be enabled in TIMx_CCER.CCxE
• in timers which have TIMx_BDTR, this signal follows the rules of bits in this register (i.e. for basic operation TIMx_BDTR.MOE has to be set)
• no related TIMx_CHx pin has to be enabled in the GPIO matrix
• this issue applies to timer-to-timer triggers, too, and maybe also other tim-to-***
• one would expect this to be clearly documented not only in chapters of all peripherals which are "slaves" to these TIM-originated triggers, but also in the Interconnect chapters/Apnootes (the Interconnect chapters are a bad joke generally with severe defficiencies)

ST perpetuates this error (in some STM32 families using "TIMx_CHx" instead of "TIMx_CCx", not making it any better) ever since the first STM32F1. There are numerous threads in this forum, through the years, involving ST insiders.

JW

@Imen DAHMEN​ 

@Vincent Onde​ 

[SCass.3]

Thank you very much @Community member​ 

you were very clear.

Regards

Stefano