TIM1 Capture Compare interrupt of STM32U575 - fails to count pulses of a temperature sensors connected to its channels

[RLanz.2]

Hello

TIM1 Capture Compare interrupt of STM32U575 - fails to count pulses of a temperature sensors connected to its channels.

We use few temperature sensors of the same kind: LMT01 of TI

(https://www.ti.com/lit/ds/symlink/lmt01.pdf?ts=1683467074947&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FLMT01).

Connected are four such temperature sensors to each of the four channels of TIM1.

Each sensor produces the pulses number according to the temperature.

There is a time-window, tCONV, of maximum 54[msec] (it may vary between 46-54, typical is 50) where the sensor performs the conversion itself (of temperature to the required number of pulses to be produced),

followed by a time-window, tDATA, of maximum 50[msec] (it may vary between 44-50, typical is 47) , where the sensor actually produces the pulses.

The individual pulse frequency is typically 88 kHz (it may vary between 82-94khz).

Please see attached a snapshot of the timing diagram.

Also, we have checked with a scope that indeed such pattern is produced by each of the temperature sensors.

But using the TIM1 configured to 100[khz] (>88[khz)), and to generate TIM1 Capture Compare interrupt, it seems to fail to count the pulses correctly: it either calculate less or more (for example: room temperature 25 [Celsius] we get either ~800 or ~1500 pulses, instead of ~1200). Also configured are four channels of TIM1 (please see attached all configuration done in STM32CubeIDE - just missing from the snapshot is settings we did to achieve 100[khz] of TIM1: Prescaler set to 64-1, Counter Period (ARR) set to 10-1, according to the formula: Timer frequency = (timer clock frequency) / (prescaler x auto) and HCLK is 64[Mhz].

We use a simple logic in our software to count the pulses.

This logic is called from HAL_TIM_IRQHandler() via HAL_TIM_IC_CaptureCallback() called for each channel.

Could you please:

1. Relate and confirm if our case of counting pulses is relevant to be handled using the TIM1 with Capture Compare interrupts?
2. Can you review and comment on our setup and configuration as detailed here above?
3. Can you point us to some code samples/detailed "cookbook" to handle correctly Capture Compare Timer functionality?

Thank you

Roni

[AScha.3]

i dont understand, which way you want count pulses by using ONE timer and 4x cc inputs .

you get just a useless delay captured...then you count in callback - right ?

why not kiss : use the pin change INT and simply count in the interrupt the value up,

+ set some (30ms ?) timeout: when >30ms no counts on a pin, get value and reset it to zero, for next value.

[RLanz.2]

Hi Ascha.3

Thanks for your reply!

1. Can you explain what exactly do you mean by in change INT, and elaborate more how according to your suggestion, it will serve the four channels (sensors)?
2. Using "our" method (not so KISS as you say :smiling_face_with_smiling_eyes: ), why shouldn't it work, as we should get 4 CC interrupts - I mean we should be able to distinguish which channel is the "root-cause" of the interrupt - and we also count the value up for each channel?

Thank you

Roni

[AScha.3]

ad 1: set rising/falling detection on 4 or more pins , as you like ->

then process in INT , count++ ... timeout , etc.

ad 2: shure, it will make an int also, but ... why create complex setup, just to get a pin change level ?

[waclawek.jan]

Your problem is the bloated Cube/HAL interrupt system (and maybe also too low compiler optimization setting). Just ditch Cube and write your own interrupt handler.

Another method would be to use timers in External clock mode; they are easily capable counting in megahertzs, but the drawback is that there's only one counter per timer, so you'd need to use 4 timers for the 4 input signals.

JW

[raptorhal2]

My guess is that the timer counter running close to the frequency of 4 signals creates synchronization problems. Up the timer frequency to 1 or perhaps even 10 MHz.

[#7]

Have you found your answer?

[RLanz.2]

No, we could not make the TIM1 Capture Compare work to count the pulses of our temperature sensors.

We temporary use simple interrupts mechanism for that purpose.

But interrupts might be needed for other purposes in our system, and we could benefit from having the TIM1 Capture Compare work for us.

[waclawek.jan]

Have you assigned higher interrupt priority?

Have you used higher optimization settings of compiler?

Have you tried to get rid of Cube's interrupt mechanism, and write your own ISR?

Have you tried to use the external clock mode?

JW