TPS65313-Q1: sporadic reset after random time

Hi Anber,

I am waiting for the error update.

regards,

Niko

Hi,

sadly we could not see any error after the reset, but that is supposed to be due to power loss of the TPS after reset (for safety reasons the system gets disconnected from power supply in case of TPS reset).

From cyclic status read-out we did not see any error so far, also cyclic Abist seems to be working without errors. (the status read-out reads all status data, e.g. if we had seen a clock warning, the system had indicated this without a reset; we also did not see an overtemperature warning, so should also not exceed the temperature - test is at room temperature with TPS load <100mA)

The "SYNC_IN" pin is floating in our application, so the TPS internal clock source should be used - are there known issues with the internal clock?

If only Buck1 over/undervoltage error are setup as reset sources, are there additional TPS hardware sources that can force a reset? 

Regards,

Florian

Hi Florian,

I am looking into this and will get back to you tomorrow.

regards,

Niko

Hi Florian,

can you double check that all the clock monitors are disabled? Also would it be possible to try to disconnect the SPI lines to the PMIC?

regards,

Niko

Hi Niko,

not all clock monitors are disabled. The configuration of CLK_MON_CTRL is as following:

DIG_CLK_MON3, DIG_CLK_MON5, DIG_CLK_MON6 are enabled, others are disabled - can a clock monitor failure directly result in a transition to reset / off state?

Disconnecting the SPI in hardware is hard - would it also be sufficient to not to communicate with the PMIC?

Best regards,

Florian

Hi Niko,

we could realize a setup with separate power lines in order to get the OFF_STATE_L read out.

The result is that the readout indicates "SYSCLK_ERR" (only this bit is set) - is this due to the enabled clock monitors? What can be done to avoid this issue? 

Best regards,

Florian

Hi Florian,

I am currently looking into this. If you are getting SYSCLK_ERR in the OFF_STATE_L register it means the analog clock monitor has detected an issue. Is ther START_UP_TO bit also set in this register? 

regards,

Niko

Hi Niko,

START_UP_TO bit is not set.

Best Regards,

Florian

Hi Florian,

thanks for the information. Could you try running the system without periodically running the ABIST/LBIST? I would like to see if the problem occurs with these functions or if it is something else.

regards,

Niko

Hi Niko,

without ABIST/LBIST we have also seen the reset in the past - but we have no information from the status registers collected that time due to a power cycle.

Hope this helps

Best regards,

Florian

Hi Florian,

Niko is having intermittent issues connecting to E2E. I have relayed your response to him so he can review it and reply to you.

Kind regards,

Conner Gillette

Hi Florian,

could you tell me the full OPN of the device so I can take a look at the specific settings? Could you also read the DEV_REV register (command 0x1)?

regards,

Niko

Hi Niko,

DEV_REV is 0x21, DEV_ID is 0x10; Part Number is O31310QRWGRQ1

Do you need some additional information?

Best regards,

Florian

In addition I tried to read the printing from the IC, it looks like:

TPS653

1310

TI 28Z

C8E4 G4

regards,

Florian

Hi Florian,

thank you for this information. Could you now try running the device with no SPI communication at all to the PMIC. My expectation is that the device won't go to OFF-state if there is no SPI communication.

regards,

Niko

Hi Niko,

you are right, we started a test two days ago, with no communication to PMIC(so also no Init, watchdog not handled, ESM not handled, etc.) and have not seen a reset / transition to off-state so far - (during other tests the longest runtime was 25-28h).

regards,

Florian

Hi Florian,

I would  like to move this discussion to email. Is this OK for you?

regards,

Niko

Hi Niko,

that is okay for me, AnBer can give you the Email-Address.

Regards,

Florian

Hi Florian,

With the holidays here, many device experts are currently out of the office. When they return they will look into this and provide a response. Please expect some delay accordingly.

Thanks,
Field

Hi Florian,

let's continue via email.

regards,

Niko