Input Capture exact timings and overcapture, console output

[ColaChugger]

Hi,

(this is my first post here, be gentle)

I'm working with a STM32H743ZI.

I'm currently trying to measure some pulses with the input capture unit. Initially I thought that 480MHz should be enough, but then was let down by the fact, that the timers only run on 120MHz. oh well. But its ok. A resolution of 8ns shall be good enough.

I use the DMA to get my values from the TIM5IC to an array. Works most of the time. I tried using the HRTIM as a clock source but only got timing values that are 4 times as large but apparently offer no higher resolution, so i switched back.

Now I'm wondering how exactly the timing on the input capture unit works. When exactly gets the interrupt bit set? I'm gonna analyze the data further and having an accurate statement would certainly help.

Next problem: sometimes the board is a little bit too slow for the pulses i send and an overcapture gets detected. Is it somehow possible to detect when the overcapture bit was set? I didn't find any ideas how to monitor that bit.

Finally my last question:

how can I set up my board to print some messages on the command window? I'm only connecting the board via USB to CubeIDE, so I'm not even sure if thats possible.

I hope you guys can help. thanks in advance.

cheers

[waclawek.jan]

> I use the DMA to get my values from the TIM5IC to an array.

What is TIM5IC, in terms of the TIM chapter in RM?

> When exactly gets the interrupt bit set?

When the capture occurs, i.e. when the content of TIMx_CNT gets stored into the respective TIMx_CCRx. There is a resynchronization at the input of each channel, which may add a few timer cycles to between the input signal and the moment when the capture actually occurs. This is not exactly documented, but shouldn't be more than 1 or 2, unless you've set some filtering at the given channel.

> Next problem: sometimes the board is a little bit too slow for the pulses i send and an overcapture gets detected. Is it somehow possible to detect when the overcapture bit was set?

There is no extra interrupt enable for the overcapture, but the idea is, that overcapture occurs when capture occurs anyway, so in the ISR you simply check not only CCxIF but also the CCxOF flags in TIMxSR.

But if you read out the values using DMA, overcaptures shouldn't really matter, they just indicate that you did not suceed to execute interrupt fast enough, but DMA should've stored the samples. Sure, there's a limit to how fast can DMA read out successive samples, too; read AN4031for the details, plus understand the delays involved by the complex bus structure of 'H7, where it matters.

I don't Cube.

JW

[ColaChugger]

>> I use the DMA to get my values from the TIM5IC to an array.

>

> What is TIM5IC, in terms of the TIM chapter in RM?

Timer 5 input capture. its not referenced as that in RM but TIM5CC refers to capture compare, which is also the output compare that I'm currently not using.

>> When exactly gets the interrupt bit set?

 >

> (...) This is not exactly documented, but shouldn't be more than 1 or 2, unless you've set some filtering at the given channel.

Thats my estimate, too. However I was hoping that there might be some documents that show the mechanics in a more detailed way.

>> Next problem: sometimes the board is a little bit too slow for the pulses i send and an overcapture gets detected. Is it somehow possible to detect when the overcapture bit was set?

>There is no extra interrupt enable for the overcapture, but the idea is, that overcapture occurs when capture occurs anyway, so in the ISR you simply check not only CCxIF but also the CCxOF flags in TIMxSR.

I guess I'll roll with an ISR then.

> But if you read out the values using DMA, overcaptures shouldn't really matter, they just indicate that you did not suceed to execute interrupt fast enough, but DMA should've stored the samples. Sure, there's a limit to how fast can DMA read out successive samples, too; read AN4031for the details, plus understand the delays involved by the complex bus structure of 'H7, where it matters.

Well in my case the DMA is already on the edge. To do some research I sent a defined number of pulses and the H7 detects all the pulses about 50% of the time. I'll take a look at AN4031.

Thanks for your help.

[waclawek.jan]

> Well in my case the DMA is already on the edge.

I see. The hardware has its limits and if you are hitting them, there's probably no escape path. DMA timing/latencies depends on quite a couple of factors, especially in the complex bus system of 'H7. If you'll add more features to the program (potentially accessing the same buses as DMA), it may/will get worse.

JW