LM5066I: Some devices measure strange values after enabling the output

Hi Christian,

Thanks for reaching out. It looks like very strange to me also. Did you check the difference in the raw hexadecimal data?

Hi Avishek,

thank you for your quick response.

I had a look at the raw hex data and this looks like this:

Raw data of READ_AVG_VIN (DCh) before setting the enable: 2271 (dez), 100011011111 (binary)

Raw data of READ_AVG_VIN (DCh) aftersetting the enable: 1926 (dez), 11110000110 (binary)

Unfortunatelly this did not help me to understand the problem. Currently I'm checking the I2C signals.

Please also read VIN_OV_WARN_LIMIT (57h) and VIN_UV_WARN_LIMIT (58h).

I read the values you requested, but nothing special to see. Also, the I2C signals seem ok, no obvious or possible bit shift due to too thight timings on the signal edges. Also tested with 100 kHz and 400 kHz I2C clock speed without any effect

One strange thing is the NACK signal at the end of the data frame. But I'm not sure if this is just a decoding issue of my tool or if it is intended due to the repeated start condition.

Before enabling

After enabling

Hi Christian,

Is there any update on this issue? 

I couldn't find anything gross.

I also don't have any clear idea why it's happening and this is the first time I am seeing this kind of issue. I am planning to test on the EVM on Monday. Meanwhile may I know the following information?

1. Is happening with only the devices having 0x16 address?
2. If READ_VOUT (8Bh) and MFR_SPECIFIC_13 READ_AVG_VOUT (DDh) are read, is there the same observation?

Hello,

looking forward for your information next week.

1. Yes, its only the device with address 0x16. But I did not yet check what would happen if I change the address of the affected LM5066i. Might try this next week.

2. On the VOUT registers, the same observations can be made. At least after turning on the output voltage, before that no output voltage can be read, which is obvious.

With input voltage of more than 41 V (such as 48 V) after enabling the controller, READ_VOUT register also provides 41 V not 48 V in case of the faulty device with 0x16 address. Am I right? I would like to know whether the same discrepancy is there in both READ_VIN and READ_VOUT or not.

Yes, this effect is also visible on the VOUT-values when the LM5066i is enabled and the voltage is higher than 41 V. The values for READ_VOUT and READ_AVG_VOUT above were aquired with an actual output voltage of 49 V

Thanks, please wait. I will get back to you on Monday. I am on leave for today. 

I have tested today on the EVM and not able to reproduce the issue. I am not observing the anomaly what you are seeing. I was thinking to perform two tests.

• Let's take a faulty board and replace the LM5066 controller with a new one. Then please check whether the issue is getting reproduced or not on the same board.  
• Install the removed device from the faulty board on a good board. Then please check whether the issue is getting reproduced or not on the same board.

I would like to understand that the issue follows the LM5066 controller or some thing else on the system.  

Please ignore the "Resolved"-marking above, I accidentally clicked on it and now it is not possible to remove this marking, is it?

Thank you for your testing. I already came up with this same idea and will do this today. This will take a while as the board has a good thermal connection to a big GND plane and it is in addition coated...

I tested the effect of the I2C address in the meantime, but nothing changed. The I2C address does not seem to have a effect on the behaviour.

• channel 2 initial I2C address 0x15 (all Rs placed) => no failure
• channel 1 initial I2C address 0x16 (all Rs placed) => failure
• channel 1 I2C address 0x57 (one R changed) => no change, failure
• channel 1 I2C address 0x40 (all R removed, all Z) => no change, failure
• channel 1 I2C address 0x15 & channel 2 0x16 (channel 1 and 2 address switched) => no change, channel 1 failure, channel 2 fine
• channel 1 I2C address 0x15 & channel 2 0x16 (channel 1 and 2 address switched), turning on both channel 1 & 2 => no change, channel 1 failure, channel 2 fine

Can you please verify that the timing of my signals seems reasonable?

Can you please also verify, that the measurement of the input and output voltage is not affected by any external circuit or any register setting?

Let me go through in detail and then will get back to you. 

I think there is no impact of VAUX here. Auxiliary pin allows voltage telemetry from an external source. Nothing to do with the VIN and VOUT measurements. 

Well, after I removed the resistor connecting the output voltage to the VAUX pin the problem was gone and the measured voltage of VIN and VOUT was correct. So there is definitely a impact! Maybe a internal clamping diode? Buffer overflow in the LM5066i registers?

Anyway, a hint in the datasheet about this behaviour would be necessary in my opinion

Glad to know that the problem got resolved. Your observation is well noted.  

What do you mean it is "well noted"?

Can you tell me why this is happening? Can you please ask an expert what is happening in the internals of the LM5066i in this case?

Will this be noted in the datasheet?

May I know why the issue was not repeatable in all of your boards or in all three controllers on a single board? 

The boards that were working fine completely as well as the other LM5066i on the same board had a sligtly different assembly of these VAUX voltage divider, so that the voltage on the VAUX pin was lower.

Thanks for your reply. I am wondering how the different assembly is getting related to the device address. Because, the issue was observed only with the devices having 0x16 PMBus address, not with other address. 

The device address does not matter in this case. The other LM5066i have slightly different assembled voltage divider resistors on the VAUX pins, so the voltage on the VAUX pin is a bit lower and the voltage measurement is not affected.

Hello, anything new?

Sorry no other update from side now.