Dead EEPROM in LTC3880?

Hello! I need help with the LTC3880 chip.

We assembled a batch of boards and during testing it turned out that LTC3880 did not work. The test showed that the chip does not respond to requests via the PMBUS at the specified address, but responds at the global address 0x5a. The MFR_ADDRESS reg (0xE6) contains 0x80 (addressing disabled).

Only commands 0x00 (PAGE) and 0x10 (WRITE_PROTECT) are available for writing. After power up the command 0x10 returns 0x02. After writing to this command of ​​0x00 the rest of the commands become available for writing. I tried to change the parameters and save them with the 0x15 (STORE_USER_ALL) command, but after reset or power off all the parameters ​​returned to their original values.

To portion of commands the chip responds with NACK - both reading and writing are not available. Statuses and identification are read normally, but data (input voltage, temperatures, etc.) is mostly garbage.

Here are some examples (all operations were performed at address 0x5a):


RD 0x00         - 0x00             // PAGE
WR 0x00 0x01    - OK
RD 0x00         - 0x01
WR 0x00 0x00    - OK

RD 0x10         - 0x02             // WRITE_PROTECT
WR 0x10 0x00    - OK
RD 0x10         - 0x00

RD 0x19         - 0xb0             // CAPABILITY
RD 0x20         - 0x19             // VOUT_MODE
RD 0x21         - 0xa1bf           // VOUT_COMMAND

WR 0x21 0x1000  - OK
RD 0x21         - 0x1000

CMD 0x15        - OK

RD 0x88         - 0x7bff           // READ_VIN
RD 0x89         - 0x8000           // READ_IIN
RD 0x8b         - 0x0000           // READ_VOUT
RD 0x8c         - 0x8000           // READ_IOUT
RD 0x8d         - 0x6ccc           // READ_TEMPERATURE_1 (external)
RD 0x8e         - 0x5571           // READ_TEMPERATURE_2 (internal)

RD 0x79         - 0x3847           // STATUS_WORD
RD 0x7a         - 0x00             // STATUS_VOUT
RD 0x7b         - 0x00             // STATUS_IOUT
RD 0x7c         - 0x80             // STATUS_INPUT
RD 0x7d         - 0x10             // STATUS_TEMPERATURE
RD 0x7e         - 0xe1             // STATUS_CML
RD 0x80         - 0x03             // STATUS_MFR_SPECIFIC

RD 0xb0..0xb4   - NACK            // USER_DATA_xx

RD 0xb6         - NACK             // MFR_INFO

RD 0xd8         - 0x8a             // MFR_CHANNEL_ADDRESS
RD 0xe6         - 0x80             // MFR_ADDRESS

RD 0xdb         - 0xa985           // MFR_RETRY_DELAY (L11: 189)
RD 0xdc         - 0xc9e4           // MFR_RESTART_DELAY (L11: 3781)
RD 0xdd         - 0xc693           // MFR_VOUT_PEAK
RD 0xde         - 0x7bff           // MFR_VIN_PEAK

CMD 0xe3        - OK               // MFR_CLEAR_PEAKS
(After this command, the peak values remain the same.)

RD 0xe5         - 0x0403           // MFR_PADS
RD 0xe7         - NACK             // MFR_SPECIAL_ID

CMD 0xfd        - NACK             // MFR_RESET
CMD 0x03        - NACK             // CLEAR_FAULTS


What is it? Defective chips, dead EEPROM, or am I doing something wrong?

  • 0
    •  Analog Employees 
    on Oct 30, 2020 4:38 AM 1 month ago

    Hello,

    AS you said, the MFR_ADDRESS reg (0xE6) contains 0x80 (addressing disabled). Then the device can not respond to the specific device address. It will only respond at the GLOBAL address like 0x5A and 0x5B.

    How many LTC3880 do you have in the system and do you use the external ASEL pin to set the device address? The default value of MRR_ADDRESS should be 0x4F.

    Best regards,

    John

  • Hi John! Thanks for the answer.

    The system has two LTC3880s. ASEL is configured for addresses 0x43 and 0x45. But the chip responds only to the address 0x5a, not to 0x5b (and not to 0x4X of course).
    A previous batch of LTC3880 purchased from another seller worked fine on these boards.

  • 0
    •  Analog Employees 
    on Nov 3, 2020 7:37 PM 1 month ago in reply to punzik

    Hello,

    Have you ever tried to use LTpowerPlay to communicate with LTC3880s on board? We recommend to use LTpowerPlay to communicate with LTC3880 to see what feedback we can get from LTPP. That will help us to find the root cause.

    Best regards,

    John

  • 0
    •  Analog Employees 
    on Nov 3, 2020 10:39 PM 1 month ago in reply to punzik

    Hello,

    Here are some suggestion on this address issue:

    One possibility is corrupt EEPROM. This prevents the part from completing reset, and things like MFR ADDRESS and WRITE PROTECT would be random values, and the part will be missing on the bus.

     

    When the EEPROM is corrupt, the LTC3880 will be at address 0x7C. Therefore, it is a good idea to see if the PMBus master can get an ACK from 0x7C, perhaps reading some register like PAGE or STATUS BYTE.

     

    However, one experiment they did was to fix WP, fix MFR ADDRESS, STORE USER ALL, and power cycle. This should have fixed any EEPROM corruption.

     

    There is also the issue of lack of VIN. Without VIN and only VDD33, you can communicate but the part is not initialized and will have the wrong address. This is fixed by running the program without vin script in LTPP.

     

    Since the probably you don’t have LTPP:

     

    # This script enables programming of LTC Current Mode Controllers when VIN has not yet been applied

    # This applies to any current-mode controller or micro module

    0x5B,WB,0xBD,0x2B,

    0x5B,WB,0xBD,0xC4,

    # Communication and Programming should now be possible for all current mode controllers and uModules

    # Even if VIN is not applied

    #

    # NOTE: AFTER VIN is applied, You MUST issue a MFR_RESET command to insure proper operation thereafter!

     

    So they can do that in code and see if the device then shows up at the expected address.

    Best regards,

    John

  • Hello,

    The chip does not respond at address 0x7C, it responds only at 0x5A.

    > However, one experiment they did was to fix WP, fix MFR ADDRESS,
    > STORE USER ALL, and power cycle. This should have fixed any
    > EEPROM corruption.

    I tried this, but the address is not saved. After power cycle the address is again 0x80.

    VIN is Ok, I checked that first.
    I can't run your script because the chip is not responding at address 0x5B.

    Here is a photo of the chip. Is the top-marking all right?