Temporary disabling ETR's

[AS_HAL]

Background: I am designing a high-speed imaging system for an industrial press. I am using an STM32 to synchronize a camera (TIM3) and two flashes (TIM4) based on an external hardware trigger.

The Setup:

• Both timers are in One-Pulse Mode (OPM) and Combined Reset + Trigger Mode (SMS = 1000).
• Both are triggered by the exact same physical edge using HAL_TIMEx_RemapConfig(&htim4, TIM_TIM4_ETR_TIM3_ETR)
• The digital filter is set to 16 µs for both (ClockDivision = DIV4, TriggerFilter = 0xf).

The Goal: When a valid trigger arrives, both timers start automatically. TIM3 fires its pulse almost immediately. TIM4 counts down a configurable delay (via CCR) before firing the flashes.

To prevent mechanical double-triggers from the sensor, I need a firmware "blind window." Once the initial valid trigger is received, I want to completely ignore the ETRF pin for a few milliseconds.

The Catch: I want to disable the ETR input from inside TIM3's HAL_TIM_PWM_PulseFinishedCallback (which fires right after the initial trigger). However, at this exact moment, TIM4 is already running its delay countdown.

Whatever method I use to disable the ETR input must not kill or reset the delayed pulses from TIM4 that are already "in-flight."

My Question for the STM Team: What is the recommended, most robust, and glitch-free method to dynamically disable/mask the ETR input "on the fly" under these conditions?

Thank you

[waclawek.jan]

> I want to disable the ETR input from inside TIM3's HAL_TIM_PWM_PulseFinishedCallback (which fires right after the initial trigger). However, at this exact moment, TIM4 is already running its delay countdown.

I don't use Cube/HAL so don't exactly understand how is your setup set up. What confuses me is, that both timers appear to be set almost identically - namely, that sConfigOC.Pulse = 1; thus both starting the pulse one timer cycle after the trigger, and there's no prescaler - so even if one of them sets the Fast bit, I don't quite see where the delay is coming from.

Nevertheless, if both timers are triggered from the same trigger, once triggered i.e. delay running, the trigger source could be safely disabled.

I personally would disable it right after it *starts* the first pulse, though, as after the first pulse finished, a premature/"false" trigger can start it again, couldn't it.

> STM Team

Just to avoid any confusion: this is a primarily user-driven forum. I am not ST.

JW

[AS_HAL]

Hello Jan

Thanks for the response and for confirming that it is safe to disable the trigger once the timer is running.

To clarify the setup, the TIM4 delay is configured dynamically before the trigger arrives, like this:   __HAL_TIM_SET_COMPARE(&htim4, TIM_CHANNEL_3, FlashDelayValue);
__HAL_TIM_SET_COMPARE(&htim4, TIM_CHANNEL_4, FlashDelayValue);
__HAL_TIM_SET_AUTORELOAD(&htim4, FlashDelayValue+FLASH_LENGTH);  

TIM3 fires instantly (CCR=1), and I enter its interrupt callback immediately. At this exact moment, TIM4 is running and counting up to FlashDelayValue.

You recommended disabling the trigger right after it starts. My main question is: What is the safest register-level method to actually execute this disable without disrupting the running TIM4 counter?

Should I simply disable the Slave Mode Controller by clearing the SMS bits? TIM3->SMCR &= ~TIM_SMCR_SMS; TIM4->SMCR &= ~TIM_SMCR_SMS;

Or is there a better practice to effectively "blind" the timer to new ETR edges while it finishes the current One-Pulse cycle?

Thank you

Alex

[waclawek.jan]

> Should I simply disable the Slave Mode Controller by clearing the SMS bits? TIM3->SMCR &= ~TIM_SMCR_SMS; TIM4->SMCR &= ~TIM_SMCR_SMS;

I don't know if there's a real risk in that this is a two-step process - and it's not the "disable" but the "re-enable" which is potentially risky. What's the chance that this creates a situation, where one timer triggers but the other won't? I guess, it's negligible or outright zero, given the mechanical process behind it is probably slow enough so that there's ample time (in terms of processor cycles) when the trigger signal is "quiet". In that case, I don't see any problem with the above process.

JW

[Pavel A.]

> I want to completely ignore the ETRF pin for a few milliseconds.

Pardon me for jumping in. If the issue is about filtering electrical glitches, why not pull the trigger pin up/down (as needed) with a capacitor for a few ms, to hold it from toggling? Do you need the "blind window" to be variable ?

[AS_HAL]

Hello

Thanks to everyone for the input. I appreciate the suggestions regarding the hardware capacitor and the logic of toggling the SMS bits.

However, for this specific industrial application (high-speed synchronization at 300 m/s), I need a definitive, architectural guarantee regarding the silicon's behavior. I cannot rely on a "negligible risk" or "it should work" scenario, as even a rare spurious glitch or a one-in-a-million race condition could disrupt the inspection process.

My specific concern remains: Is the Slave Mode Controller (which handles the SMS logic) fully decoupled from the Time Base Unit (the actual counter) such that clearing SMS bits mid-cycle is 100% glitch-free for a running timer?

[waclawek.jan]

> Is the Slave Mode Controller (which handles the SMS logic) fully decoupled from the Time Base Unit (the actual counter) such that clearing SMS bits mid-cycle is 100% glitch-free for a running timer?

As I've said, I'm not ST to give you such guarantees.

But, would you use Trigger mode instead of Trigger+Reset, it even wouldn't matter - while TIMx_CR1.CEN is set, it does not matter if there's a trigger which would set it again.

What I was talking about above was not risk during disable, but during re-enable. Since re-enabling the whole "machine" involves writing to two separate registers, there is a chance that one of the timers does see some spurious pulse but the other, enabled later, won't see it - that is, unless the mechanical arrangement guarantees there's no such spurious pulse in a wide enough time window where you can perform that enable.

JW

[AS_HAL]

Thanks, Jan. I appreciate the deep dive into the Reset vs. Trigger behavior and the 'two-step' re-enable risk.

Because this application involves 500 m/s targets where a single spurious reset is a system failure, I have opened an official service request with ST to confirm the deterministic behavior of the Slave Controller logic.

To mitigate the re-enable risk you mentioned, I’m implementing a 'quiet-line' check in firmware to ensure the timers are only re-armed during a stable idle window. I will update this thread once I have the official hardware verification from ST.

[Pavel A.]

For high reliability you can make redundant controllers + arbiter. Like in the textbooks.