IRTC Tamper Interrupt Triggering Continuously (~3000 Events/sec instead of Expected 1 Event/sec)

[Divij_Arora]

I am working with the IRTC tamper detection on KM35Z75M. I have configured TAMPER0 with filtering enabled and an interrupt callback. The input signal is a GPIO toggled every 500 ms (i.e., ~1 Hz signal), so I expect the tamper counter to increment by 1 count per second.

I have done the filter config as 

IRTC_Init(IRTC_MODULE_COMP_OFF_CONFIG,

          IRTC_TAMPER_PIN_POL_HIGH_CONFIG(TAMPER_FILT_CLK_64HZ,3),

          IRTC_TAMPER_PIN_DI_CONFIG,

          IRTC_TAMPER_PIN_DI_CONFIG,

          IRTC_TAMPER0_MASK);

ISR Implementation

static void irtc_callback(IRTC_CALLBACK_TYPE type, void *data)
{
if(type == IRTC_TAMPER0_CALLBACK)
{
IRTC_ClrIsrFlag(IRTC_TAMPER0_MASK);

tTAMPER_LOG* tmp = (tTAMPER_LOG*)data;

if (tmp->source == TAMPER0_PIN)
{

if((RTC_FILTER01_CFG & RTC_FILTER01_CFG_POL0_MASK) == 0x00)
{
IRTC_SetTamperPinActiveLow(TAMPER0_PIN);
tamperhigh_count++;
}
else
{
IRTC_SetTamperPinActiveHigh(TAMPER0_PIN);
tamperlow_count++;
}
}
}
}

I see tamperhigh_count and tamperlow_count increasing at approx 3000 per second.

Attaching the code.

Any guidance or reference example for proper tamper edge detection would be very helpful.

[Celeste_Liu]

Hello @Divij_Arora ,

Thank you for the detailed description.

Based on the KM35 iRTC tamper mechanism, the behavior you are seeing is more consistent with repeated tamper status handling than with true 1 Hz edge counting. The external tamper input is first processed by a programmable filter, and a tamper event is generated only after the input remains stable in the configured active polarity for the programmed filter duration. For TAMPER0, CLK_SEL0 = 64 Hz and FIL_DUR0 = 3 mean that the input must remain asserted for 3 cycles of the 64 Hz filter clock before detection, which is approximately 46.9 ms. This filter is intended for noise/glitch suppression and debounce, not for edge counting.

The reference manual also states that once a tamper event is detected and stored, a new event from the same tamper source will not be stored again until the CPU acknowledges the tamper status. In addition, the tamper interrupt status is cleared only after the corresponding tamper status bits are cleared, and the tamper status bits themselves are cleared by writing 1 to TMPR_STS .

With this mechanism, dynamically switching the TAMPER0 polarity inside the ISR (toggling between active high and active low) is not a suitable method for implementing “one count per signal transition.” The reference manual clearly states that:

Therefore, my recommendation is:

If the goal is tamper detection:
Configure TAMPER0 with a fixed polarity (either active high or active low) and do not change the polarity dynamically inside the interrupt handler. After a tamper event is detected, follow the iRTC tamper handling flow to read the tamper queue / timestamp information and then clear the corresponding tamper status.

If the goal is edge counting on a 500 ms toggling signal:
We do not recommend using the iRTC tamper module for this purpose. The iRTC tamper function is intended for security event detection and timestamp logging, not as a general-purpose GPIO edge counter. For counting rising/falling edges of a 1 Hz square wave or similar signal, a GPIO/PORT interrupt or a timer/counter peripheral such as LPTMR, QTMR would be a more appropriate solution.

The MCUXpresso SDK does include a driver_examples/irtc example for the twrkm35z75m platform; however, this public example mainly demonstrates RTC time and alarm functionalities.

Hope it helps.

BR

Celeste