AM2612: Questions about some registers of RTI

Hi Matsumoto-San,

Hideaki Matsumoto said:

When 1ms elapses, is it OK to recognize that Bit0 of RTIINTFLAG becomes “1” even if “Enable Compare Interrupt” is not checked?

Yes. When the compare match occurs (1 ms in your setup), the RTI compare match flag (RTIINTFLAG bit0) is set regardless of whether the “Enable Compare Interrupt” box is checked. The interrupt enable only controls whether a pulse is propagated to the interrupt controller (VIM); it does not prevent the internal match flag from being set.

Hideaki Matsumoto said:

Are the following their understanding correct ?
        - Regarding Compare register value between FRC value of RTI and Compare Event, the next Compare register value is automatically updated (added) when the comparison register value is reached.
        - Since the FRC value and the comparison register value are updated at the same time, there is no need to consider overflow after reaching 32-bit.

            ( Will there be no conflict between FRC value and compare value when returning to 0x00000000 ? )

The compare register value is automatically reloaded from the associated UDCP (Update Compare) register when a compare match happens — this supports hardware periodic interrupts without software updating COMP every cycle. However, the hardware does not implicitly perform “COMP = COMP + previous_value” arithmetic; it simply loads the value stored in the RTI_UDCPx register.
• Because the RTI compare logic is an equality test against a 32-bit FRC, wraparound is handled naturally. When the 32-bit FRC wraps from 0xFFFFFFFF to 0x00000000, equality comparisons still work as expected, so you do not need special overflow handling for a standard UDCP-based periodic timer. (Only when you do manual delta arithmetic like next_comp = current_FRC + N must you make sure to use unsigned arithmetic so wrap is handled correctly.)

With your clock/math:
• RTI_FCLK = 240 MHz, RTICPUCx = 19 → FRC = 240 MHz / (19+1) = 12 MHz → FRC period = 83.333 ns.
• 1 ms requires 12,000 FRC counts. Set RTI_COMP0 = 12000 and RTI_UDCP0 = 12000 for a hardware 1 ms tick.
• A 32-bit FRC will overflow in 2^32 / 12e6 ≈ 357.9 s ≈ 5.97 min. That wrap is normal and equality comparisons are wrap-safe.
• Polling every 500 µs:
• Polling at 500 µs (< 1 ms) means you will detect each 1 ms event (worst-case detection latency = 500 µs). This is safe provided the polling task is never blocked longer than 1 ms. The RTI flag is a level flag (it stays ‘1’ until cleared) — it does not queue multiple matches. If polling becomes slower than the event period (e.g., >1 ms), you can lose events (because the flag will only show ‘1’ once, even if multiple matches occurred).

When reading FRC/UC (or capture registers) do: read FRC first then UC (and for capture reads read CAFRCx then CAUCx). This preserves consistency. The TRM recommends this exact order.

I could not understand if there are specific issues/inconsistency being observed? or this was a general question to understand the RTI Behaviour? Can you please help me understand a bit more?

Regards,
Shaunak