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.

TPS544B25: TPS544B25 memory verification obscurity

Part Number: TPS544B25

Hi,

Our customer who programs TPS544B25  bz our programming tools noticed as about verification error at register 0x40. We found out error in our verification procedure when we verified also non-volatile bit. Neither after modification the customer is able to verify the device. We tried to program customer's script file using TI's Fusion Digital Power Designer and USB Interface Adapter and found that a value 0xA002 is read from the register at address 0x40, but Fusion Digital Power Designer interprets this value as 0x9A02. My question is why your SW doesn't announce verify error, shall we omit verification of register at address 0x40?

Best regards,

Frantisek

  • Hi Frantisek,

       The address 0x40 is VOUT_OV_FAULT_LIMIT. Is this happening on a single device or have you checked other devices?

    Regards,

    Gerold

  • Hi Gerold,

    This happens on many devices at customer as well as at us.

    Best regards,

    Frantisek

  •  

    Can you please double check the values you are reporting for Register 40h (VOUT_OV_FAULT_LIMIT) ?

    I suspect that you are flipping the bytes of the command values due to the SMBus and PMBus definition of a WORD as Low-byte, High-byte.

    0x029A  would be a value of 1.30V, and if stored and power-cycled, that would be read back as 0x02A0 because Command 40h (VOUT_OV_FAULT_LIMIT) does not have NVM back-up for the lower 4 bits, and the part will round the value during a store/restore.

    (The details of the command on are page 50 of the datasheet)

    Neither 0xA002 nor 0x9A02 are valid values for VOUT_OV_FAULT_LIMIT.  VOUT_OV_FAULT_LIMIT.  The maximum valid value for VOUT_OV_FAULT_LIMIT is 922d / VOUT_SCALE_LOOP

    VOUT_SCALE_LOOP = 1 (0.5-1.5V)  - 039A (1.8V)

    VOUT_SCALE_LOOP = 0.5 (1.0 - 3.0V) 0734 (3.6V)

    VOUT_SCALE_LOOP = 0.25 (2.0V - 6.0V) 0E68 (7.2V)

  • Dear Peter James,

    Thank you for your answer.

    > Can you please double check the values you are reporting for Register 40h (VOUT_OV_FAULT_LIMIT) ?

    > I suspect that you are flipping the bytes of the command values due to the SMBus and PMBus definition of a WORD as Low-byte, High-byte.

    Sorry I didn't write exactly, we know that PMBus uses at first Low-byte and next High-byte, but I wrote value which is used in Script.

     

    > Comment,Read VOUT_OV_FAULT_LIMIT 1.300780 V

    > ReadWord,0x40,0x9A02 

    > 0x029A would be a value of 1.30V, and if stored and power-cycled, that would be read back as 0x02A0 because Command 40h (VOUT_OV_FAULT_LIMIT) does not have NVM back-up for the lower 4 bits, and the part will round the value during a store/restore.

    029Ah = 0000 0010  1001 1010

    VOUT_OV_FAULT_LIMIT (40h) has upper 4 bits and lower 4 bits volatile, expected value after power-up is xxxx 0010 1001 xxxx  = x29xh, but we read x2Axh.

     

    In the device datasheet is specified:

    > Note the lower 4 bits can not be backed up in EEPROM.

    There is no mention that values of lower 4 bits will be round.

    Best regards,
    Frantisek

  • Hi,

    Can I have your answer?

    Frantisek

  •  

    There are no questions in your last response, and I answered your question about why the write and read-back did not match from your initial post, so what question would you like to have an answer to?

  • Dear Peter James,

    Did you read my answer with attention?

    > Can you please double check the values you are reporting for Register 40h (VOUT_OV_FAULT_LIMIT) ?

    > I suspect that you are flipping the bytes of the command values due to the SMBus and PMBus definition of a WORD as Low-byte, High-byte.

    Sorry I didn't write exactly, we know that PMBus uses at first Low-byte and next High-byte, but I wrote value which is used in Script.

    FYI, we checked values and are OK, we know byte ordering and write correct value to device. So the error shall be elsewhere. Where?

    > Comment,Read VOUT_OV_FAULT_LIMIT 1.300780 V

    > ReadWord,0x40,0x9A02

    > 0x029A would be a value of 1.30V, and if stored and power-cycled, that would be read back as 0x02A0 because Command 40h (VOUT_OV_FAULT_LIMIT) does not have NVM back-up for the lower 4 bits, and the part will round the value during a store/restore.

    029Ah = 0000 0010 1001 1010

    VOUT_OV_FAULT_LIMIT (40h) has upper 4 bits and lower 4 bits volatile, expected value after power-up is xxxx 0010 1001 xxxx = x29xh, but we read x2Axh.

    Expected value is x29xh, but we read 0x2Axh, why?


    In the device datasheet is specified:

    > Note the lower 4 bits can not be backed up in EEPROM.

    There is no mention that values of lower 4 bits will be round.

    Super, can we trust the documentation? Where is truth, in documentation or in your answer?

    Frantisek

     

  • Did you read my answer with attention?

    [PJM] Yes, I read your answers.

    So the error shall be elsewhere. Where?

    [PJM] There is no "error" there is a STORE/RESTORE change to the value resulting from the limited EEPROM space dedicated to the VOUT_OV_FAULT_RESPONSE_LIMIT command.

    Expected value is x29xh, but we read 0x2Axh, why?

    {PJM] Because the TPS544B25 uses limited EEPROM storage for the command, the designers needed to define how to handle values that are not exact matches.  In the case of VOUT_OV_FAULT_LIMIT, the decision was made that it was better to "always round up" so that if there are any "1s" in the bottom 4 bits, the value stored in NVM is 1 LSB higher.  For UV limits, the opposite choice was made, and the value is truncated.  This ensures that the lost of resolution imposed by the limited NVM space does not result in tighter OV or UV fault limits, and potentially fault triggering.


    0x0281 - 0x0290 -> 0290

    0x0291 - 0x02A0 -> 02A0


    In the device datasheet is specified:

    > Note the lower 4 bits can not be backed up in EEPROM.

    There is no mention that values of lower 4 bits will be round.

    Super, can we trust the documentation? Where is truth, in documentation or in your answer?

    {PJM] The Documentation does not cover the details of how the part handles the extra 4 bits, it simply says that they're not stored in NVM, which is true.  The additional detail that I have included here is how the part handles the additional resolution, and it does so using a digital math process that ensures that the NVM restored value is equal to or larger than the programmed value to ensure that the rounding does not produce tighter limits than the programed value.

  • If this mentioned behavior is "undocumented" feature of the device, why PMBus Programmer Script File doesn't treat this feature and uses "bad" values for verification?

    Will it be fixed?

  •  

    I believe I am getting confused about your question and concern.  Perhaps it would help if we walked through things step by step.

    First, the best practice for creating a programming script using the FUSION software:

    1) Power up a sample device

    2) Connect the sample device to a computer using the provided TI dongle

    3) Start-up TI FUSION Digital Designer

    4) Configure the sample device in the desired configuration

    5) Store the desired configuration to NVM

    6) Power down the sample device

    7) Restore power to the sample device - this ensures that any power-on reset configuration values are captured in the active registers

    8) Select "Refresh All Parameters" from the "Device" menu - this updates the FUSION software with the power-on reset values from the device.

    9) Select "Export" from the "File" menu and choose the PMBus Programmer script

    Skipping steps 6-8 can create programming verification errors for programmed values, such as rounding errors, changes in the exponent used for SLINEAR11 values, or restored values that are not stored in NVM.

  • Dear Peter James,

    I understand this, but we cannot tell to the customers that their PMBus Programmer Script files aren't created properly and that they must follow the steps you sent me. This must be done by TI.

    BTW: The PMBus Programmer Script file I sent you earlier is created by customer who asked us to implement the programming support.

    Best regards,

    Frantisek

  •  

    Any change to the FUSION Designer script generation software is going to take time to implement.  I can manually change the file you sent me to remove the verification error, or I can provide you with instructions on how to manually update the file, but updated software will not be available for some time.

    Let me know if you would like me to update the CSV file, or provide instructions on how to update it.

  • Peter James,

    The PMbus Programmer Script file we received from customer for testing is not important. Important are cfg. files which customers will use in future. The there exist common instructions for updating such files the we can incorporate these instructions to our SW. So, yes please provide me with instructions for update incorrect script file.

    Best regards,

    Frantisel

  •  

    I have edited the CSV script that you provided.

    And the file didn't attach, and my notes on what I did got cut off.

    I edited the header to note that the file was manually edited by my on Tuesday March 31, 2020.

    I made some changes to the read-back verification after the RESET portion.

    1) I commented out changes to some commands that do not have NVM backup.

        VOUT_UV_WARN_LIMIT - Calculated from VOUT_UV_FAULT_LIMIT

        VOUT_OV_WARN_LIMIT - Calculated from VOUT_OV_FAULT_LIMIT

        IOUT_OC_WARN_LIMIT - Calculated from IOUT_OC_FAULT_LIMIT

    2) I updated the expected readback verification for some commands due to their limited NVM back-up

        VOUT_UV_FAULT_LIMIT - Truncate to round down to nearest value with bits [3:0] = 0000b

        VOUT_OV_FAULT_LIMIT - Truncate and add 4 to round up to the nearest value with bits [3:0] = 0000b

    That should address your customer's issues with their script file.  I will work with the FUSION Designer team to update the programming script export function.

  • Dear Peter James,

     I will work with the FUSION Designer team to update the programming script export function.

    It would be nice if you'll inform me upon availability of updated SW.

    Best regards,

    Frantisek