• State Not Answered
  • Replies 13 replies
  • Subscribers 89 subscribers
  • Views 366 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 360293
Options

Need urgent technical support for Nordic PMIC PM1300

Hemanth0

we are using nPM1300 EVK board for an upcoming project we are trying to interface PMIC PM1300 chip with Ambient Scientific processor GPx10 Pro.

It will be a huge setback for our project that is under development, if the I2C Interface between the two chips don’t work… since proto boards are already in fabrication

 

We have tested GPx10Pro I2C interface extensively with other sensors… but with this PMIC it is inconsistent and unreliable.  And this is the only part of Hardware that is not working yet.

In bare metal code, we are able to get acknowledgement sometimes. 

Parents
  • 0

    Hi,

    As the I2C communication sometimes work but is unreliable the first thing that comes to mind is if you have long jumper wires when testing, perhaps combined with too weak pull-up resistors? I would suggest shortening the wires and using stronger (lower resistance) pull resistors.

  • 0 in reply to Einar Thorsrud

    Hi,

    we have tried with other pull up resistors still getting same results. we will once check by soldering the PMIC i2c pins with our mcu and will let you know the results.

  • 0 in reply to Einar Thorsrud

    Hi Thorsrud,

    Yes, we have connected the common ground.

    We checked the signals using a logic analyzer and were able to observe the slave address (0x6B) being transmitted. however, we did not receive an ACK from the PMIC.

    We will recheck the signal integrity using an oscilloscope.

  • 0 in reply to Hemanth0

    Hi,

    We checked the signals using an oscilloscope, and the signal integrity appears to be correct. However, we are still not receiving an ACK response from the PMIC.

  • 0 in reply to Hemanth0

    Hi,

    I see.

    Can you share your signal integrity measurements done with the oscilloscope here? Please also show the circuit and where you measure. The best would be if you can do separate measurements, one set close to the pins on the MCU and another close to the pins on the PMIC, we need at least to see it from the PMIC side. VDDIO, SCL and SDA.

    Can you also share a logic analyzer trace with protocol analysis enabled of the same so we can see what is happening? 

    Which value of pull resistors are you using, and which other have you tested? If you can share a schematic that could also be very useful for our team looking into this.

    Lastly, so I have not misunderstood. You write that "In bare metal code, we are able to get acknowledgement sometimes". How often is that? Have you made any HW changes? And have you compared the write from the master where it works to when it does not? Is it the exact same address (and data), so that you should have seen an ACK from the PMIC? If so, that would strengthen the indication that this could be HW related. If not, then we need to look more closely at the SW.

    Edit: Another thing, have you verified that the PMIC power up correctly? What is supplying VDDIO? Is it one of the nPM1300 BUCKs? Could there be a conflict there between the BUCK and another supply on VDDIO?

  • 0 in reply to Einar Thorsrud

    Hi,

    I have an additional comment and a few questions. While I undertsand you are using a non-Nordic host MCU, it could be good to refer to the nPM1300 EK documentation Use the nPM1300 EK with an nRF5340 DK. And using that as a reference

    1. How is it connected to your host MCU board, also with the VDDIO connection? Typically in nRF5430DK+nPM1300 EK use case we are recommending to use VOUT2 for the VDDIO, but that is just our suggestion.
    2. How have you connected this jumper?

  • 0 in reply to Einar Thorsrud

    Hi,

    while using API's

    while using baremetal:

    npm_with_repeatstart.sal

    Please find the details below regarding the I2C communication setup and observations:

    • These are the pins we are using for the I2C communication between the MCU and the PMIC.
    • VDDIO is supplied from our MCU, which is operating at 3.3V.
    • On the P18 header, VDDIO is connected to VOUT2 through the onboard jumper.
    • We are currently using 1.8 kΩ pull-up resistors on the SCL and SDA lines. We also tested with 10 kΩ pull-up resistors, but we are still not consistently receiving ACK from the PMIC.
    • We have attached the Logic Analyzer (LA) results with protocol analysis enabled for reference.
    • In the bare-metal implementation, we are able to receive ACK from the PMIC approximately 8 out of 10 times.
    • No hardware changes were made during these tests.

    i will share the DSO readings ASAP.

Reply
  • 0 in reply to Einar Thorsrud

    Hi,

    while using API's

    while using baremetal:

    npm_with_repeatstart.sal

    Please find the details below regarding the I2C communication setup and observations:

    • These are the pins we are using for the I2C communication between the MCU and the PMIC.
    • VDDIO is supplied from our MCU, which is operating at 3.3V.
    • On the P18 header, VDDIO is connected to VOUT2 through the onboard jumper.
    • We are currently using 1.8 kΩ pull-up resistors on the SCL and SDA lines. We also tested with 10 kΩ pull-up resistors, but we are still not consistently receiving ACK from the PMIC.
    • We have attached the Logic Analyzer (LA) results with protocol analysis enabled for reference.
    • In the bare-metal implementation, we are able to receive ACK from the PMIC approximately 8 out of 10 times.
    • No hardware changes were made during these tests.

    i will share the DSO readings ASAP.

Children
Related