Dears,
Why this bit will set to assert?
I have check setting this bit default is 0b, but sometimes I can see FIRS TO ALERT is assert when boot.
May I know the reason and how to avoid this bit assert?
BR
Eric
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Dears,
Why this bit will set to assert?
I have check setting this bit default is 0b, but sometimes I can see FIRS TO ALERT is assert when boot.
May I know the reason and how to avoid this bit assert?
BR
Eric
Hi Eric,
The use of first to assert Bit is when many devices are asserting SMBALERT#. This bit provides a way for the host to know which device was the first to have a problem.
Are there any other devices in your system? If yes, do you see this bit being asserted in any other devices as well? Also do you see the SMB_ALERT# (pin 15) going LOW?
The STATUS_BYTE (78h) /STATUS_WORD (79h) can tell you exactly which fault is asserting the First to Assert bit.
SMBALERT_MASK Bit can be set to avoid setting "First to Assert". But this will also mask the SMB_ALERT# (pin 15) signal.
Thanks & Regards,
Aishwarya
Hi Aishwarya,
In currently design use two multiphase controller shared the same PMBUS and no connect other devices in this bus.
Here is step:
1. I check host register find SMB_ALERT going LOW
2. Check output voltage was ok
3. Connect GUI and see the FIRS TO ALERT is assert
4. Click clear faults then check host register SMB_ALERT going HIGH
5. Try to shutdown and power on many times can see FIRS TO ALERT is assert from GUI
6. Check setting this bit default is 0b
I still not sure what cause FIRS TO ALERT assert.
BR
Eric
Hi Eric,
SMB_ALERT# & hence "First to ALERT" can go low due to multiple reasons other than the output voltage:
Can you please send me the value of follwoing registers (79h) & (78h)?
Hi Aishwarya,
I try a couple times finally see the First to ALERT.
(79h) & (78h) was 0x03 both.
BR
Eric
Hi Eric,
As per data from 79h & 78h, it looks like the error info is in 7Eh (STATUS_CML). Status CML has show error due to multiple reasons as listed below. But these will not cause interruption to power conversion & that's why you see Vout to be stable.
You can check the STATUS_CML register to find out the cause of error.
Thanks & Regards,
Aishwarya
Hi Aishwarya,
7Eh was 0x01, from the register table has show [Other communication error occurred].
So it's seems like I can't find out the cause of error?
BR
Eric
Hi Eric,
Other communication error can include multiple possibilities. You can check for some of the conditions mentioned in the datasheet under CML_Other.
Thanks & Regards,
Aishwarya
Hi Aishwarya,
Is there any possibility this situation:
Due to we use TPS536C7 "B1" version, but we don't have B1 config only B0 config.
So we use B0 config import to B1 silicon, maybe some setting need to set?
Earlier we use A0 config import to A0 silicon is ok have not see this error occur and I can make sure no change HW design between A0 and B1.
BR
Eric
Hi Fang,
I need to check the difference b/w these versions with the backend team. I will get back to you on this in sometime.
Regards,
Aishwarya
Hi Fang,
The changes b/w the different versions cannot be compared because it involved different kinds H/W & F/W changes. You can email me the config files that the customer uses & I can compare it with the B1 config files that I have to see the difference.
Regards,
Aishwarya
Hi Eric,
I checked the B1 Silicon with the B1 config files & I see the same fault. I also checked your config files. There is no issue with it.
However, the problem is as follows:
The high level GUI while BOOT up is reading/writing in some registers which are not meant to be read from or written into. If you read the STATUS from the Low level GUI (w/o Opening the High level GUI at all), you will see the registers to be fine.
You can confirm it on your system as well.
Thanks & Regards,
Aishwarya