PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster)

[vikasgupta]

Hi everyone,

I am currently integrating the PCA2131 Automotive RTC into a Battery Management System (BMS) and experiencing an inconsistent issue with the periodic interrupt generation.

Issue Description: We are trying to generate an interrupt at a defined interval (e.g., every X minutes). The core problem is that the behavior is highly erratic:

• Sometimes, the interrupt triggers exactly as expected.

• Sometimes, the counter appears to run approximately 4x faster than it should.

• Sometimes, the interrupt is missed entirely.

Because this issue occurs randomly, we are struggling to isolate the root cause.

Testing & Observations:

• Hardware: We have tested 3–4 different RTC samples, and this abnormal behavior has been observed across multiple units.

• Clock Configurations: We evaluated the default 32.768 kHz clock, as well as the 16 kHz and 8 kHz configurations.

• Interrupt Intervals: Tested with 1-minute, 2-minute, and 5-minute intervals.

• Result: The timing instability persists across these variations.

Request: For reference, I have attached our schematic and the captured waveforms.

Could you please review the attachments and help us understand what could be causing this? We would appreciate any insight into specific register configurations, known errata, or noise/hardware conditions that could lead to this intermittent timing instability.

Thanks in advance for your support.

[ErikaC]

Hello!

Could you please check the following points?

• The MSF flag (bit 7 of Control_2, address 01h) must be explicitly cleared after every interrupt. 

  • Always write 0 to MSF (bit 7 of Control_2) in your ISR. Use the AND-write method described in Section 7.11.5 of the datasheet (write 0 to clear, 1 to leave unchanged)

• If both MI (bit 1) and SI (bit 0) of Control_1 are set, the result is an interrupt once per second not once per minute.
  • Set only MI = 1, SI = 0 in Control_1 for a periodic minute interrupt. Read back the register to confirm.

Please let me know the result.

[vikasgupta]

I Checked as you suggested me. For that I take screenshot of CTRL_REG_1 and CTRL_REG_2 when alarm trigger and after alarm clear.

[ErikaC]

Hello,

The writes that disable the alarm comparators by setting AEN_x = 1 are commented out, please uncomment all five lines. These writes must execute before re-arming the next alarm.

In the alarm trigger screenshot, the raw register value ctrl2.w = 18 (0x12 = 0001 0010 binary) correctly shows:

• Bit 4 = 1 → AF (Alarm Flag) is SET
• Bit 1 = 1 → AIE (Alarm Interrupt Enable) is SET

However, the struct field ctrl2.b.af is displayed as 0 in the debugger. This means your C bitfield struct definition for Control_2 does not correctly map the af field to bit 4. If any part of the firmware branches on ctrl2.b.af instead of the hardware interrupt line or RTC_ALarm_Flag software variable, it will fail to detect the alarm and miss interrupts entirely  explaining the missed interrupt symptom.

Please verify and correct the bitfield definition of your Control_2 register struct. The af field must be declared at bit position 4.