Read/write latency while dynamically adjusting counter phase

[Tkmn]

I want to be able to continuously adjust the phase of a timer output via input capture on another signal. I do not want the timer to be automatically triggered or reset by the external signal because I want some processing in the loop to determine how to react to the input capture value. The course I am taking right now is to adjust TIMx->CNT. The problem is that I am experiencing somewhat nondetermistic delays in reading/writing the count at my desired timer clock frequency such that something like TIMx->CNT-- or even TIMx->CNT = TIMx->CNT actually adjusts the phase by 8-12 counts based on input capture and scoped output. Is there a better way to more deterministically down- or up- adjust the timer count than essentially reading and writing back the CNT value? 

[TDK · Accepted solution]

There's no atomic read-modify-write access available, especially with a Cortex M7 core.

I suggest adjusting the ARR value up or down by the difference you want, and then reset it after the timer updates. This will let you effect an exact change to the CNT value. Might have minor side effects depending on if you use the timer update event.

[Michal Dudka]

You can try this configuration. Let "TimA" to be your timer. Set up another timer (TimB) to one-shot mode and to generate TRGO signal (pulse with defined width). Use this signal as gate signal for your TimA. Then you can stop TimA for precise defined number of ticks by starting TimB (its ARR value controls gate pulse period and "freeze" time of TimA).Moreover you can use this "freeze time" to change TIM->CNT value without risk that CNT will change during read-write-modify and your algorithm can compensate this "delay"... 

[Tkmn]

Thank you! I found the adjustment of ARR and reseting it to be the fewest number of interactions to get what I needed.