TPS65994AE: TPS65994BH I2C_IRQ pin always low

Michael,

I suspect the issue is when loading firmware from the EEPROM, the PD asserts the 'App Loaded' interrupt before your configuration is loaded. 

Can you read-back the 0x14 and 0x15 registers of both ports to see what is being asserted? 

Thanks,

Chris

Hi Chris,

I tried to set EC GPIO to output pin and control I2C interrupt to set high and its worked, and set back to input then pulled low again, and IO Config setting Pin Multiplexed to GPIO and Disable was OK. I also read 0x14 & 0x15, all of bits are 0.SHELL_TYPEC_INT_PIN_ALWAYSKEEPLOW.csv

I agree there are no I2C Events. I have more follow-up questions that can help debug this:

• What base firmware image are you using? Should be something like F609.10.xx 
• Is there a 10k pullup on the IRQ line? 
• What I2C1 addresses are you using for the PD controller(s)? Looks like there are 3 device addresses being written to. 

Hi Chris,

What base firmware image are you using? Should be something like F609.10.xx

A: F909.12.15

Is there a 10k pullup on the IRQ line?

A: Yes.

What I2C1 addresses are you using for the PD controller(s)? Looks like there are 3 device addresses being written to. 

A: 0x20 and 0x24

Michael,

The E2E states you are using a TPS65994AE. Is that the case? Your base image is for TPS65994BH. Is your project a TPS65994BH?

Thanks,

Chris

Hi Chris,

Yes, it's TPS65994BH, because the case can't choose BH, so I choose AE and type BH in title.

Understand! I will take your project (make sure latest is still what you shared 7 days ago) and I will recreate the issue with your base image + project on an EVM. If it can be recreated on the EVM, we can fix it. If it cannot, then that would point to a hardware issue on your board. Give us a few days to work on this problem. 

Thanks,

Chris

Logs: https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/x58_5F00_0207_5F00_F909.12.15.sal

Hi Chris,

It's not a hardware issue, the IO Config setting Pin Multiplexed to GPIO and Disable was OK. the interrupt pin was always high. Here is the pjt file which setting GPIO10 disable, please help to check.x580_TBT5_F909p12p15_30DA_v3118_20250217.pjt

TI is was closed today. Sorry about delays.

Michael,

I understand disabling the GPIO function causes the GPIO to work. However I cannot replicate the issue on an EVM with the same PJT and the same base firmware image. There were only two differences. 

• Hardware - I ran my test scenario on an EVM and it worked fine with no issue. GPIO always stayed high. 
• Test Procedure - I have no details on this so from the discussions it sounds like system boots and the I2C1_IRQ is held LOW. 

If there is something wrong with my test sequence please let me know in exact detail what steps you are doing and I can try to recreate. Please let me know what else I can do to help you debug this issue. 

Thanks,

Chris

Hi Chris,

According to our test results, the interrupt pin could be always high by setting PD f/w, so we think it's can be fixed by PD f/w,
please help to check the PD f/w setting.

We have some question about this issue:
1. F/W setting disable all of the values for interrupt mask for I2C1 & I2C2, and the interrupt state is clear, why interrupt pin still keep low?
2. We know the test on your EVM is pass, but disable the GPIO pin by PD f/w on our hardware board can worked too. so it's not like the external signal or device to keep interrupt pin low.
3. We test in UEFI mode is ok, the interrupt pin default is high, but when system into OS, it's may always keep low, and f/w disable GPIO is pass both in UEFI and OS, our test environment is Win11 24H2.
4. We think the f/w setting to disable GPIO and setting as IRQ with disable all of the values for interrupt mask for I2C1 & I2C2 are same because both of the f/w setting should not notify interrupt, but the result is not match.

The attachment is the part of our hardware circuit.X58_TI TBT5 Sch.pdf

BR,

Michael

Michael Lin said:

F/W setting disable all of the values for interrupt mask for I2C1 & I2C2, and the interrupt state is clear, why interrupt pin still keep low?

We reproduced this and did not see same behavior on EVM. We cannot answer this except external factor. 

Michael Lin said:

We know the test on your EVM is pass, but disable the GPIO pin by PD f/w on our hardware board can worked too. so it's not like the external signal or device to keep interrupt pin low.

In my test, I have I2C1_IRQ enabled. Not disabled.

Michael Lin said:

We test in UEFI mode is ok, the interrupt pin default is high, but when system into OS, it's may always keep low

So if OS if off (system is off) then the IRQ goes LOW? This seems like not a PD issue then. If you run a simple test of powering on the PD controller and keep rest of system off, if IRQ is HIGH, then its not a PD issue. 

Michael Lin said:

We think the f/w setting to disable GPIO and setting as IRQ with disable all of the values for interrupt mask for I2C1 & I2C2 are same because both of the f/w setting should not notify interrupt, but the result is not match.

Incorrect. IRQ is an alternate GPIO function. IRQ GPIO set with all values disabled is still an IRQ function pin. Disabled is disabled. 

Thanks,

Chris

Hi Michael,

Would you like to try clear all interrupt events by write 0x50 bit2 to "1"?

And if it still cannot work, you can check below.

Could you try the pjt on other project to see the same phenomenon with interrupt?

And also try other project's pjt on this project to see  the same phenomenon with interrupt?

Thanks!

Zoe's idea is good. Also is there any other device (not controller) sharing the I2C_IRQ lines?