cancel
Showing results for 
Search instead for 
Did you mean: 

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

SCass.3
Associate II

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 

4 REPLIES 4
Michael E
ST Employee

Hello @Community member​ ,

Maybe this wiki article on ADC topic can help you

Regards

Michael

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.

SCass.3
Associate II

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

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
Associate II

Thank you very much @Community member​ 

you were very clear.

Regards

Stefano