TPS23881: Intermittent Access Failure to TPS23881 Slave2 Device ID in Configuration-A Mode

Charan Kumar Reddy K R

Part Number: TPS23881

Tool/software:

Hi,

We are using the TPS23881 device in our design, configured in Configuration-A mode, where it operates in 8-bit access mode. In this mode, the 8-channel PSE device is logically split into two 4-channel devices, each assigned a consecutive I2C slave address. Slave1 handles ports 1 to 4, and Slave2 handles ports 5 to 8.

Occasionally, we encounter an issue where access to the PSE device fails. Specifically, reading the Device ID from Slave1 succeeds (returns 0x22), while reading from Slave2 consistently fails (returns 0xFF) once the issue occurs. This state persists until the node is power cycled, after which normal operation resumes.

In one instance, we observed that the node had been left idle for over 7 days during which PoE functionality was normal. However, following this idle period, the access failure to Slave2 was observed. We have not been able to reproduce the issue consistently.

Could you please help us understand the possible reasons for this behaviour.

3 months ago

0 Diang Xing 3 months ago

TI__Mastermind 37031 points

Hi Charan,

Could I double check your mask configuration?

Theoretically both of your 8-bits should show the same Device ID.

Could you show your log when you try to read the Device ID register by Slave1 and Slave2?

Best regards,

Diang

0 Charan Kumar Reddy K R 3 months ago in reply to Diang Xing

Prodigy 90 points

Hi Diang,

Yes, the mask configuration is correct. In the normal working scenario, we are able to successfully read the Device ID as 0x22 from both Slave1 and Slave2 of the TPS23881.

However, the issue arises when the node is left idle for a few days. Upon resuming access, we observe that while Slave1 continues to respond correctly with Device ID 0x22, Slave2 stops responding entirely — all register reads return 0xFF, not just the Device ID.

This indicates that the Slave2 interface becomes inaccessible after prolonged inactivity. A power cycle to the node restores normal functionality, but we are unable to reproduce the issue consistently.

We would appreciate any insights into potential causes for this behavior and possible recommendations to prevent or debug it further.

0 Seong Kim 3 months ago in reply to Charan Kumar Reddy K R

TI__Mastermind 46141 points

Hello Charan,

Diang is OoO and will be back on Wednesday, so please give him a few days to respond.

Thank you and best regards,

Seong

0 Charan Kumar Reddy K R 3 months ago in reply to Seong Kim

Prodigy 90 points

Hi Seong,

Thanks for the update.

Regards,

Charan.

0 Seong Kim 3 months ago in reply to Charan Kumar Reddy K R

TI__Mastermind 46141 points

Hello Charan,

Of course!

-Seong

0 Diang Xing 3 months ago in reply to Seong Kim

TI__Mastermind 37031 points

Hi Charan,

Thanks for more information you shared.

So Config A is applied?

During idle time is the PSE powered but output nothing (since no valid PD is connected)?

If you use the broadcast slave address (0x7F), when Slave2 issue happened, can you access both Slave1 and Slave2?

Can you share the schematic and let me know what is the clock frequency you used?

I think it would be more clear for us if we could capture the SDA/SCL by Saleae or scope when issue can be reproduced.

Best regards,

Diang

0 Charan Kumar Reddy K R 3 months ago in reply to Diang Xing

Prodigy 90 points

Hi Diang,

Please find my inline answers.

So Config A is applied? --> Yes, config A is used.

During idle time is the PSE powered but output nothing (since no valid PD is connected) --> Yes PSE was powered .

If you use the broadcast slave address (0x7F), when Slave2 issue happened, can you access both Slave1 and Slave2? --> we are trying to reproduce the issue, we will try this once we hit the issue.

Can you share the schematic and let me know what is the clock frequency you used? --> 312KHz is the clock frequency. Please let me know which part of schematics you need.

I think it would be more clear for us if we could capture the SDA/SCL by Saleae or scope when issue can be reproduced. --> Yes we will probe and share waveforms once we reproduce the issue.

Regards,

Charan.

0 Diang Xing 3 months ago in reply to Charan Kumar Reddy K R

TI__Mastermind 37031 points

Hi Charan,

Thanks for your reply. Will wait for your reproduce.

Charan Kumar Reddy K R said:
Can you share the schematic and let me know what is the clock frequency you used? --> 312KHz is the clock frequency. Please let me know which part of schematics you need.

A schematic like P18, 19,20 of https://www.ti.com/lit/ug/slvubp0a/slvubp0a.pdf will be helpful. 312kHz should be in TPS23881's 10 - 400kHz.

Best regards,

Diang

0 Charan Kumar Reddy K R 3 months ago in reply to Diang Xing

Prodigy 90 points

Hi Diang,

could you please share your Mail ID to share schematics.

Regards

charan

0 Diang Xing 3 months ago in reply to Charan Kumar Reddy K R

TI__Mastermind 37031 points

Hi Charan,

I have reached out in email.

Best regards,

Diang

0 Diang Xing 3 months ago in reply to Diang Xing

TI__Mastermind 37031 points

Hi Charan,

Thanks for the schematic. The 2.4k pull up resistor looks correct to me. I did not see anything abnormal for the I2C circuit.

Hope you can find a way to reproduce this issue and capture the I2C waveforms.

Best regards,

Diang

0 Charan Kumar Reddy K R 3 months ago in reply to Diang Xing

Prodigy 90 points

Hi Diang,

Yes, we are trying to reproduce the issue. We will share the I2C waveform during the issue state.

Regards,

Charan.

0 Diang Xing 3 months ago in reply to Charan Kumar Reddy K R

TI__Mastermind 37031 points

Hi Charan,

I will set this thread as waiting. Please help to rely when you are able to reproduce.

Best regards,

Diang

Power management

Power management forum

TPS23881: Intermittent Access Failure to TPS23881 Slave2 Device ID in Configuration-A Mode