PCA2129T Interrupt flag not pulsing

[Thundertwonk]

Hi everyone,

I'm using a PCA2129T to trigger an I2C sub-routine that reads the total lifetime that has been generated by the RTC chip, and stores the result in an EEPROM. I've configured the interrupt output to trigger once every second, when the Minute/Second flag raises. I'm not using a battery, and the supply is always kept at a steady 3.3V. I've configured this setup data using an I2C library that writes these constraints to the chip at startup.

For some reason, the Interrupt pin never fires. I think I'm writing the correct data to the correct location, but I don't know what else could be making it go wrong. I've attached an image of my setup constraints (RTCSetup.PNG), where "utility_setup_data" is the data that is written to the device over I2C, and the "CMD Addr" is the Command location that is sent just before the data is sent.

I've also attached the Schematic layout of the device (RTCSchematic).

Thanks in advance,
Roland

[reyes]

Hi,

From the schematic you sent, I assume the pull-up resistor required in the I2C pins are located near the MCU and not missed from the schematic, correct?

And, I’m also correct in assuming that you don’t have any problem with the I2C communication, the problem is only with the Interrupt, correct?

PCA2129 has two pre-defined timers which are used to generate an interrupt either once per second or once per minute (see Section 8.12.1 of the datasheet for details).

The pulse generator for the minute or second interrupt operates from an internal 64 Hz clock. It is independent of the watchdog timer. Each of these timers can be enabled by the bits SI (second interrupt) and MI (minute interrupt) in register Control_1.

With TI_TP = 1, you are setting the Interrupt generated from the second timer (flag MSF in register Control_2) as a pulsed signal as in Figure 21 of the datasheet.

The pulse generator for the minute/second interrupt operates from an internal 64 Hz clock and generates a pulse of 1⁄ 64 seconds in duration. Your system should be able to find the interrupt pulse with this duration.

A test you can do to find if this is the problem can be trying with TI_TP = 0 so the interrupt is permanently active signal until MSF is cleared:

Regards,

Jose

[Thundertwonk]

Hi Jose,

Yes, I should have specified that there are resistors on SDA and SCL that are pulling the I2C lines up to 3.3V. I have several other I2C devices on this bus, and I can read and write to all of them without any problem, so I know the communication between my device and the PCA2129 is solid. 

In tests that I performed this morning, I set command location 0x00 (Control_1) as 0x00000001, meaning only the second interrupt is enabled, and I set command location 0x01 (Control_2) as 0x10000000, meaning the MSF flag is set when a second or minute interrupt is generated. Also, I set TI_TP to 0, meaning that the INT pin should generate a permanent signal when the seconds count of the Control_1 register is generated.

Unfortunately, the INT pin is still high, and never goes low. I tried reading the seconds registers at 0x03, and I can see that the RTC module counts up each second, and displays the result in BCD (as intended). This leads me to believe the internal clock is indeed operational, so perhaps there's some internal damage somewhere at some point...

As it stands, I'm not sure what else I can do, except change the chip and hope that fixes it.

Best,
Roland

[reyes]

Hi Roland,

I agree with you, there could be some internal damage. I would like to test the integrity of the internal  interrupts logic, so, I would suggest to try a different interrupt, for example, set an alarm every time the second counts is ‘05’, so you should receive an alarm every minute.

• Second_alarm @ address 0xA = 0x05
  • AIE =1 in Register control_2 @ address 0x1
  • I then wait for the AF bit to be set
  
  

When the Second_alarm @ address 0xA is set to 0x5, means that the alarm will be triggered when the actual time from the RTC’s seconds count is equal to ‘05’, it does not means that it will be triggered 5 seconds after you make this setting.

For example, if you set the ‘05’ seconds alarm at the time 10:15:20 (hour 10, minute 15, second 20), it will take 45 seconds to fire the ‘05’ alarm (at actual time 10:16:05). It will NOT fire at 10:15:25 (05 second after the alarm is set).

Jose

[Thundertwonk]

Hi again,

I tried the solution as you suggested, but still no luck. I even tried setting the watchdog timer to generate an interrupt but still nothing.

I think I've found a solution to the problem however...

The I2C lines are pulled up to a different 3.3V supply, which activates before the RTC 3.3V supply (we'll call this 3.3V_I2C). It could be that the RTC is beginning to enter a pseudo-powered state before the 3.3V_I2C supply fully activates, and so is affecting the OSC clock somehow. I did a number of tests with editing my firmware to activate the LDO as quickly as physically possible, but still, no joy. Very strange that all other I2C devices work perfectly. Even more strange that it didn't matter where I setup the RTC module in my I2C state machine - INT never activated!

In the circuit, I'm powering the chip with an LDO that can supply a maximum current of 200mA (this is enough for this device and the rest on this I2C chain by quite a long way), but for some reason, when I connect a separate 3.3V supply (the supply driving the I2C pull-up resistors), the INT pin suddenly starts working with all the proposed solutions. 

So TL:DR, if I connect the RTC module to the same 3.3V supply as is connected to the pull-ups, all is good. This does unfortunately mean I've lost the ability to power cycle the chip in case of SDA error, but I can do this in firmware instead (maybe that'll be a post for another day ).

At any rate, thanks for all your help and suggestions,
Roland

[reyes · Accepted solution]

Hi,

Glad you found the source of the problem.

About the reset/power cycle, there is a way to do this by software in case SCL is not stuck low (only SDA is stuck low), this is done by sending an extra clock pulses if the data line is stuck low. Sending 8 extra clock pulses will re-initialize the slave state machine. If the clock line is stuck, then there is not much that can be done without using a hardware solution.

More details about this on section 3.1.16 of the I2C Specification: https://www.nxp.com/docs/en/user-guide/UM10204.pdf

Jose

[Thundertwonk]

Hi Jose,

I'm really glad that NXP support the practice of clocking SCL and sending a NACK, because that's exactly what I plan to do instead! I'm in the enviable position whereby I wrote our I2C library (as it does specific things on an FPGA), so it will be easy to add this feature. Thanks for sending that additional document too - it will very much help writing the firmware (my job for today).

Best,
Roland