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.

LP8764-Q1: Programming NVM over I2C

Part Number: LP8764-Q1
Other Parts Discussed in Thread: LP87644Q1EVM

Dear,

We have a LP876411B4RQKRQ1 on a custom PCB. To operate it properly, we would like to change the NVM through I2C as asked before (link). Normally, this should work with any I2C host as mentioned in the answer. When trying this on the evaluation module (LP87644Q1EVM) with a generic I2C host and access to VCCA, VIO, SCL, SDA, and GND, this works as expected. However, when running the same I2C commands on our generic PCB we can find the LP876411B4RQKRQ1 at the correct I2C address, but we cannot update the NVM.

I read on the forums that multiple people have the same problem. In (link), the user registers were locked, but this has been taking care of in our I2C command list by writing on register 0xA2 on page 0 as explained in the “Scalable PMIC NVM Update Guide” (link).

I also saw two topics related to my question on the forum (link & link) without any solved responses.

Could you help me with this problem, or direct me the correct documentation to solve this one?

Kind regards

Gertjan

  • Hi Gertjan,

    We have a LP876411B4RQKRQ1 on a custom PCB. To operate it properly, we would like to change the NVM through I2C as asked before (link).

    As mentioned in the thread that posted a while ago. We are working on to release user-programmable version of the device and related documentation. It is not release yet. However, you should be able to update the NVM by referring to Scalable PMIC NVM update guide .  

    I see issue here is that you are using a device which was meant to use in certain application together with another device and hence  NVM of that device was configured according to that particular use case. Now you have used that device for your own DIY application and for that you need to modify the NVM of existing device. Similar thing has been pointed out by my other colleagues in one of those threads that you pointed out. So, our assumption is that when you are doing this kind of update you are familiar with the NVM update concept and you know what to update according to your use. 

    I also saw two topics related to my question on the forum (link & link) without any solved responses.

    I would say issues are deferent for different customers but most of the time we do not have complete picture of the issue and that's why we try to get more information why and how it doesn't work. 

    The device LP876411B4RQKRQ1 has by default NVM which has been made for a use case together with TPS65941213-Q1 . You can also have look at the user guide and the NVM configuration settings of that device (https://www.ti.com/lit/pdf/slvucf3 ) and see if something is being missed while doing the updates.

    Now coming to the issue. so you are saying the same updates you are able to do on EVM but not on your custom board, right. Have you checked that everything on hardware schematic looks good ? I2C needs PUs and corrected VIO voltage on bus. Have you probed using scope to see if there is any discrepancies in I2C communications? And after that what errors are you getting while updating the NVM? Also have you made sure that it is not address related issue?

    BR,

    Ishtiaque  

  • Hi Ishtiaque,

    The main problem is that the PMIC is connected over I2C, but all replied data equals 0x0. 

    When following the guide to update the NVM by referring to Scalable PMIC NVM update guide, the first step to unlock the NVM is given by writing 0x98 to register 0xA2. If you look at the I2C communication captured on the scope, then I am able to write the value to the register (left side). However, I cannot read the value back as seen in the right side:

    Am I missing a first step before unlocking the NVM? This approach worked on the evaluation module, therefore I assumed it would work with the IC itself as well.

    On the dedicated PCB, a 5k1 resistor is added as pull-up resistor for the SDA and SCL line, respectively. The VIO voltage at pin 24 of the PMIC is equal to 3.31V, and its VCCA voltage at pin 18 is 5.13V. The I2C address of the PMIC is selected as 0x4C as seen in all documentation files, and confirmed by a simple I2C bus scan. 

    I hope this clarifies the problem we are experiencing. Feel free to ask more details to better understand the situation.

    Kind regards

    Gertjan

  • Hi Gertjan,

    Please follow instructions literally. That unlocking needs 4x writes to register 0xA2 and cannot be read during or after 4 writes.

    Br, Jari

  • Hi Jari,

    I did follow the instructions as specified in the scalable PMIC NVM Update Guide in Appendix D. 

    However, when reading register 0xA3 after unlocking the NVM, bit 6 is not set and the returned byte is 0x00. If I follow the same procedure using the EVM, bit 6 is set and the returned byte is 0xC0. 

    Does this help to clarify/locate the problem?

    BR

    Gertjan

  • Hi Gertjan,

    Isn't it so that NVM is permanently locked. Can you read the register address 0x41 in Page 1 see what is default value. 

    If the register reads any value other than 0xA5 then it is EEPROM is locked. This is also described in section 5.4 of Scalable PMIC NVM Update Guide . 

    If it is permanently locked then unfortunately nothing can be done. You need to change the device and try to re-configure or update the NVM that you are trying to do.  

    BR,

    Ishtiaque 

  • Hi Ishtiaque,

    If I read this register from the EVM that we have, we indeed get the 0xA5 value. From the LP876411B4RQKRQ1 IC on the dedicated PCB, we only get 0x00, like we always do when asking for a register value. However, no commands were given to lock the NVM, and I assume they are not shipped with a standard locked NVM since the PMIC does not have any outputs enabled yet. In addition could you clarify if it would be possible to read from the NVM, even when the NVM is locked?

    I feel like something is missing to get a proper reply from the PMIC itself. Am I correct in assuming we only need a generic I2C-host and supply signals to VIO, VCCA, GND, I2C_SCL and I2C_SDA to set up a communication with the device, make it reply, and program its NVM? Is the PMIC in a sleep state we need to erase? Or is there another state we need to take care of?

    BR,

    Gertjan

  • Hi Gertjan,

    Thanks for the feedback. 

    In addition could you clarify if it would be possible to read from the NVM, even when the NVM is locked?

    Yes, it is possible to read NVM even if the NVM is locked. Only thing is that you cannot update the NVM when it is locked.

    I feel like something is missing to get a proper reply from the PMIC itself

    From you feedback, it seems that probably your I2C communication is not working properly. Are you able to read and write properly from the device without updating the NVM? Have you tried to read 0x1 (DEV_REV), 0x2 (NVM_CODE_1), 0x3 (NVM_CODE_2) and what you got? do you also get 0x00 while reading those registers? 

    BR,

    Ishtiaque  

  • Hi Ishtiaque,

    Thank you for your answer and sorry for my late reply, I was caught up in some other projects.

    I have been looking into this problem again, and I still have the same error: I cannot read from any register on the PMIC. However, the PMIC is able to send an ACK on the SDA line, after which the SDA line goes to 3.3V again without any problems.

    Below you can find the scope image when probing the EVM (address 0x48) for the data at register 0x01:

    However, if I repeat the same procedure to ask the PMIC (address 0x4c) with the dedicated PCB for the data at register 0x01, we get a 0x00 reply:

    Since we do get an ACK from the PMIC, the PMIC can pull the SDA-line low. In addition, the pull-up resistors seem small enough such that the exponential rise time is small enough as well. Do you have an idea how this problem can be explained and fixed? 

    Kind regards,

    Gertjan

  • Hi Gertjan,

    1. What VCCA/input voltage have you set in the NVM and using in the system. If you set 5V input in the NVM and providing 3.3V. Can you try to increase first to 4V then try to read and still if the device reads 0x00 then increase to 5V and try reading again. 

    2. or have you set in NVM 3.3V and you are providing 5 V? 

    Because when I did change the VCCA to 5V with VCCA monitoring enabled and applied 3.3V then it read the same 0x00 as you have. 

    See the register map below. It all reads zero. So I suspect that you either have any one condition mentioned above. Please try to look in that direction.

    BR,

    Ishtiaque 

  • Dear Ishtiaque,

    Thank you for your suggestion. Up until now, I applied 5V to Vcca and 3.3V to Vio. I cannot check which Vcca voltage is expected by the PMIC since I cannot check the NVM. However, the default value of register 0x2C (VCCA_PG_WINDOW) seems to indicate that Vcca should be set at 3.3V. Therefore, I changed the value of Vcca to 3.3V as well, but I still experience the same problem that I cannot read out any data of the NVM (the oscilloscope captures of the communication are identical to the ones above).

    Is there another reason why the PMIC might acknowledge the communication and send ACKs, but not reply with the requested data?

    Kind regards,
    Gertjan

  • Hi Gertjan,

    Alright, not sure why so. 

    Have you tried checking by replacing another device. May be the one which you are testing is broken or its EEPROM got corrupted ? 

    Does the device power up at first time in your PCB? 

    Can you share the NVM json file that you are trying to update? or you have updated to the LP876411B4RQKRQ1 device on your custom PCB? 

    Also have you checked that your I2C host is working correctly with custom PCB? because I see some discrepancies in shared figure of I2C communication. 

    You may look at the repeated start communication of I2C. Is it according to what datasheet suggests. I noticed (highlighted by vertical red line in below figure)  that after repeated start when SDA rise happens at the very edge of SCL fall as compared to normal communication where SDA transition should happen when SCL is low. This may may not be the exact cause because if you are using the same I2C host on EVM and it is working then this should also work but because it is custom PCB may be the hardware connections are differently routed and catching some noise and that might be creating the discrepancies that I just mentioned. 

    BR,

    Ishtiaque

  • Hi Ishtiaque,

    Thank you for your support. However, at the moment I am still facing the same problem. I do have some questions on the topics you raised and maybe these can help to find the solution.

    Have you tried checking by replacing another device. May the one which are testing is broken or its EEPROM got corrupted ? 

    I changed our custom PCBs but I do obtain the same problem. Therefore, I believe it is systematic rather than related to the PCB.

    Does the device power up at first time in your PCB? 

    It does acknowledge I2C commands, so it should be powered on. Or do you mean something else with power up that I could measure or check? 

    Can you share the NVM json file that you are trying to update?

    I would like to first test basic communication before moving there.

    or you have updated to the LP876411B4RQKRQ1 device on your custom PCB? 

    Yes, the PMIC on the custom PCB is: LP876411B4RQKRQ1. Is this a problem vs the PMIC used on the EVM?

    Also have checked that your I2C host is working correctly with custom PCB? because I see some discrepancies in shared figure of I2C communication. 

    I have looked into this again and changed some parameters. You can find the scope plot of the communication below which should have a valid repeated start if I am correct. In addition, I double checked again the I2C communication with a temperature sensor on the PCB and that one behaves normally. Therefore, I think the I2C host is not causing any problems.

    Is there something else that I might miss and that I could check to fix this problem or point towards where the problem is located?

    Kind regards,

    Gertjan

  • Hi Gertjan,

    I changed our custom PCBs but I do obtain the same problem. Therefore, I believe it is systematic rather than related to the PCB.

    What I meant from replacing the device was that have you tried to change Sample A PMIC with Sample B PMIC on the same custom PCB. And are you still seeing the same behavior? And did you try the same say Sample A PMIC on the EVM to check weather it is working correctly?

    It does acknowledge I2C commands, so it should be powered on. Or do you mean something else with power up that I could measure or check? 

    Yes, I meant whether the PMIC is powering on  or not. Did you check the output  of the PMIC? 

    Yes, the PMIC on the custom PCB is: LP876411B4RQKRQ1. Is this a problem vs the PMIC used on the EVM?

    Yes EVM comes with a device with different NVM. This information is given in EVM user guide . 

    Until unless you have populated the LP876411B4RQKRQ1 on EVM as well. 

    And I see now the repeated start looks correct. 

    Up until now, I applied 5V to Vcca and 3.3V to Vio

    From what I looked into your comments above that you have been providing 5V input  however, the LP876411B4RQKRQ1 is programmed for 3.3V VCCA input as could see in the below diagram from User guide . 

    So to me the issue still seems to be the one that I highlighted above. 

    1. What VCCA/input voltage have you set in the NVM and using in the system. If you set 5V input in the NVM and providing 3.3V. Can you try to increase first to 4V then try to read and still if the device reads 0x00 then increase to 5V and try reading again. 

    2. or have you set in NVM 3.3V and you are providing 5 V? 

    Because when I did change the VCCA to 5V with VCCA monitoring enabled and applied 3.3V then it read the same 0x00 as you have. 

     

    so, while using the LP876411B4RQKRQ1, provide 3.3V input to device instead of 5V. 

    BR,

    Ishtiaque