• State Not Answered
  • Replies 4 replies
  • Subscribers 74 subscribers
  • Views 333 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 346567
Options

Load switch initial state

vybz@gmx.de

Hello,

Before I start to over-develop I need to ensure that there isn't a better solution based on the nPM1300 behavior or capabilities.

Context

I'm using an nPM1300 as a load switch to power two controllers (nRF52840 and STM32L462CE), where either one is running or the other (mutual exclusive operation).

To toggle between the load switch's outputs, I'm using TWI, triggered by a designated GPIO on both hosts (where one MCU activates the other).

Consequently, each of these two controllers will serve as the sole host of the nPM1300 at one point.

I'm using the nPM1300 to provide two power rails: 1. first buck regulator and 2. the load switch powered by the second buck regulator.

Problem

I need to set the default state of the load switch to power e.g. MCU A in the initial system state. 

So far, I have only found passive state transition behavior, that always depends on an external host.

But the external hosts can't manage the states of the nPM1300 if not powered, which at this point kind of renders a chicken-egg problem

Question

Is there a native way to handle this situation i.e. without a dedicated discrete circuitry?

Or is the nPM1300 the wrong device for this purpose?

Thanks for helping me!

Parents Reply Children
  • 0 in reply to Bendik Heiskel

    Hi Bendik,

    Thanks for that clarification. I was really hoping  that the nPM1300 implements that behavior to make a discrete load switch obsolete.

    I have a different question I hope you can help me with. 
    I have based the discrete design for  the nRF52840 on the latest reference design.

    Can we safely drop the N.C. parts C13, C10 from the design, especially from the PCB? Because there is no explanation why for example the DEC2 is not requiring that external decoupling capacitor and why it is still in the reference design.

    Additionally, the reference design coontains a capacitor C9 for DEC5 with the note "not required for Fxx or later". How can I know the build ID in advance? Can we safely assume that all parts  that are curently available from major distributors satisfy that condition (because pre Fxx builds are older than e.g.10 years? Is it safe to drop C9 from the design?

    nRF52840 reference design (config. 7)

    Best regards,
    Brian

  • 0 in reply to [email protected]

    Hi Brian,

    [email protected] said:
    Can we safely drop the N.C. parts C13, C10 from the design, especially from the PCB? Because there is no explanation why for example the DEC2 is not requiring that external decoupling capacitor and why it is still in the reference design.

    C13 and C10 can be removed, they are left as placeholders to show that the DEC2 pin should be left floating, and that the capacitors on the DEC4_6 net should all be placed close to the DEC4 pin, and not close to the DEC6 pin.

    [email protected] said:

    Additionally, the reference design coontains a capacitor C9 for DEC5 with the note "not required for Fxx or later". How can I know the build ID in advance? Can we safely assume that all parts  that are curently available from major distributors satisfy that condition (because pre Fxx builds are older than e.g.10 years? Is it safe to drop C9 from the design?

    The Fx0 revision of the nRF52840 was introduced in 2021, it has a separate ordering code nRF52840-QIAA-F so as long as you are ording the correct part it should be OK to remove C9.

    If you want the option to use older revisions you need to keep C9, having C9 populated on revision Fxx and later will not be an issue as the pin have been disconnected internally.

    The change is documented in Information Notice 141

     

    Best regards,

    Bendik

  • 0 in reply to Bendik Heiskel

    Hi Bendik,

    thanks for not forgetting me. And thank you very much for your time and support!

    Bendik Heiskel said:
    having C9 populated on revision Fxx and later will not be an issue as the pin have been disconnected internally.

    That's a valuable point. This means following the paradigm "better safe than sorry" will be quite cheap in this case. I was also not aware that the "F" in the device's ID code refers to that revision. Because the docs identify "F" as "firmware" (pre-programmed). But then the document reference you have provided is pretty explicit on how to identify the revisions that have implemented the update. 
    Thanks for clarifying on that.

    You have helped me very much. Thank you! Good to have you around ;)

    I wish you a great day!

    Best regards,
    Brian

Related
Terms of service