nRF9151 SMA DK power input questions

Hi

I'm working on a new project using the nRF9151 SMA DK and I have some questions that I haven't been able to answer by searching this forum or reading through the documentation.

1. The hardware guide says the board should be powered from either USB or the VIN pin (pin 9 on P20). However it would be advantageous for my project if I could instead create a shield during prototyping that supplies 5v via pin 5 of P1. SB35 (closed by default) connects the P1/P3/P7 5V pins to VDD_5V, so electrically they appear to be the same net as VIN_5V on P20. Is this a supported way to power the DK, or are there caveats I should be aware of (e.g. the power switch SW6, power-input selection FETs, etc.)?

2. The guide says only one source should be applied at a time but doesn't say why. My assumption is that it's to prevent reverse current flow between the two sources. For my application I'd like the DK to remain powered from the vehicle's 12 V (via a buck) while also being able to connect USB for programming/debugging, without having to disconnect either side. I'm planning to put a Schottky in series with my buck output (cathode toward the DK's 5V net) to prevent USB current from flowing back into my buck. Looking at the power input section of the schematic, it appears that Q9 (MCM2301-TP) provides similar reverse-blocking on the VIN_5V -> VBUS path via its body diode. Is that the intended behaviour, and if so, would my Schottky + the existing Q9 be sufficient to safely connect both sources simultaneously? Are there any other failure modes (transient behaviour during USB plug-in, SW6 interaction, USB_DETECT logic, etc.) I should be aware of?

Thanks,
Mark

Parents
  • Hi Mark,

    First, be sure to keep in mind that I'm not really a hardware person so, my knowledge on the subject are somewhat limited.

    1. The hardware guide says the board should be powered from either USB or the VIN pin (pin 9 on P20). However it would be advantageous for my project if I could instead create a shield during prototyping that supplies 5v via pin 5 of P1. SB35 (closed by default) connects the P1/P3/P7 5V pins to VDD_5V, so electrically they appear to be the same net as VIN_5V on P20. Is this a supported way to power the DK, or are there caveats I should be aware of (e.g. the power switch SW6, power-input selection FETs, etc.)?

    It is definitely not recommended as you are bypassing some protections (and the "POWER ON/OFF" switch) and supplying voltage to a pin that should be used as an output.

    However, I think it should theoretically work, but we cannot give any guarantee that you won't break your board after some time if you are supplying your board that way.

    2. The guide says only one source should be applied at a time but doesn't say why. My assumption is that it's to prevent reverse current flow between the two sources. For my application I'd like the DK to remain powered from the vehicle's 12 V (via a buck) while also being able to connect USB for programming/debugging, without having to disconnect either side. I'm planning to put a Schottky in series with my buck output (cathode toward the DK's 5V net) to prevent USB current from flowing back into my buck. Looking at the power input section of the schematic, it appears that Q9 (MCM2301-TP) provides similar reverse-blocking on the VIN_5V -> VBUS path via its body diode. Is that the intended behaviour, and if so, would my Schottky + the existing Q9 be sufficient to safely connect both sources simultaneously? Are there any other failure modes (transient behaviour during USB plug-in, SW6 interaction, USB_DETECT logic, etc.) I should be aware of?

    Yes, this is to prevent reverse current flow. Even though we don't recommend doing it, the DK is capable of handling USB and VIN:5V at the same time. It will switch to the available source with a preference with the USB source. So when both way are powered, the VIN:5V is not used. This mechanism does not allow to power from VIN:5V and use USB, it will switch between fully USB powered + USB data or fully VIN:5V (USB not connected).

    However, if you are supplying power directly from the 5V pin, this mechanism doesn't work, and you may break something.

    Basically if you want to use USB with another power supply, you will need to somehow "replace" the USB V_BUS before it enters the board.  

    Please take what I said with a grain of salt, as I am not a hardware expert.

    If you have more questions, feel free to ask.

    Best regards,

    Simon D-M

  • Hi Simon

    Thanks for getting back to me and I appreciate you're not an expert, is it possible to get a definitive response from someone who is?

    I feel like these are fairly basic things that should be covered by the technical documentation but right at the start of my project when I'm trying to design the power circuitry it seems like things are a bit vague. I would like to know:

    It is definitely not recommended as you are bypassing some protections

    Which protections specifically?

    and supplying voltage to a pin that should be used as an output

    What are the specific implications of doing this that I should be aware of?

    we cannot give any guarantee that you won't break your board after some time if you are supplying your board that way

    Obviously I don't want to break the board but I'm confused as to what you mean here. Do you mean that since I'm bypassing protection circuits then I might make a mistake and cause over-voltage or over-current? Or is this inherently going to cause damage for some reason even if I'm careful and put sensible protections in on the source side?

    > However, if you are supplying power directly from the 5V pin, this mechanism doesn't work, and you may break something.

    Ok so if I've understood this correctly I think what you're saying here is that if I do what I wanted to do in question 1 (supply via the 5V pin of P1) then the mechanism that defers power input to the usb won't work and something might break as a result.

    If I instead supply 5v through VIN the way the documentation says to, is it the case that the device will switch from 5v to USB power when it's connected and switch back when unplugged? Are there any specific implications or risks of operating it like this? I can add protection to the things I'm connecting to it but without knowing what you're referring to it's a bit difficult to design them.

    Basically if you want to use USB with another power supply, you will need to somehow "replace" the USB V_BUS before it enters the board.

    I'm really not sure what you mean by this. I think powerless USB cables exist, is that what you're referring to? Or do you mean I'd need to put something in the path of the USB connection and turns its power off when VIN is present?

    How is this supposed to work in products built using the nRF9151 platform? It surely can't be the case that connecting them to both a DC input and USB at the same time would cause problems so this must be a unique quirk of the dev board.

    I mean no disrespect here and I do appreciate you trying to help but I'd rather not design power circuits based on vague notions about how things might work. Would be very grateful if you could get a definitive answer from someone.

    Cheers,
    Mark

  • Hi,

    I'll ask one of my colleague to review what I say. But first let me try to answer your questions:

    m4rkw said:

    It is definitely not recommended as you are bypassing some protections

    Which protections specifically?

    At least the USB/VIN switching mechanism. I don't know how well it can handle taking current backward, so I wouldn't plug the USB nor the VIN if I were to input power on the 5V pin.

    I don't think there are other things that are bypassed, but I might be wrong there.

    m4rkw said:

    and supplying voltage to a pin that should be used as an output

    What are the specific implications of doing this that I should be aware of?

    First for our part, we won't cover any damage done to the board.

    Then, for your part:

    • You shouldn't connect USB.
    • You shouldn't connect VIN_5V
    • You shouldn't connect an external debugger,
    • Your power supply must be stable enough and not have big spikes (that also applies for VIN_5V though)
    m4rkw said:
    Obviously I don't want to break the board but I'm confused as to what you mean here. Do you mean that since I'm bypassing protection circuits then I might make a mistake and cause over-voltage or over-current? Or is this inherently going to cause damage for some reason even if I'm careful and put sensible protections in on the source side?

    I don't think it will inherently damage the board. The only part I'm not sure is the switching mechanism. As said before, I don't know how well it can handle being "reverse-powered" (even though I think it should be fine).

    m4rkw said:

    > However, if you are supplying power directly from the 5V pin, this mechanism doesn't work, and you may break something.

    Ok so if I've understood this correctly I think what you're saying here is that if I do what I wanted to do in question 1 (supply via the 5V pin of P1) then the mechanism that defers power input to the usb won't work and something might break as a result.

    If I instead supply 5v through VIN the way the documentation says to, is it the case that the device will switch from 5v to USB power when it's connected and switch back when unplugged? Are there any specific implications or risks of operating it like this? I can add protection to the things I'm connecting to it but without knowing what you're referring to it's a bit difficult to design them.

    Correct. The switching mechanism should be working fine. The only problem I can think about is the current peak that will appear when the switch happens. But, I believe the warning is mostly to be sure that Nordic won't be accused if some USB device plugged into the device breaks because some small current got sent to back to the port, or if the switch current peak breaks the USB device, etc...

    m4rkw said:

    Basically if you want to use USB with another power supply, you will need to somehow "replace" the USB V_BUS before it enters the board.

    I'm really not sure what you mean by this. I think powerless USB cables exist, is that what you're referring to? Or do you mean I'd need to put something in the path of the USB connection and turns its power off when VIN is present?

    How is this supposed to work in products built using the nRF9151 platform? It surely can't be the case that connecting them to both a DC input and USB at the same time would cause problems so this must be a unique quirk of the dev board.

    What I wanted to say here is that you would need to supply your board through the USB directly if you want the USB data. You probably shouldn't power from VIN and use USB at the same time. The board will just switch to the USB thus making the VIN unused. The board has just not been made for that use-case.

    But this is not relevant for an actual product using nRF9151 as this is concerning only the nRF9151 DK. As you can see here, the nRF9151 only needs to be powered by VDD and VDD_GPIO. The DK has not been made to be integrated to actual product. You are welcome to copy parts of its schematic to make your own board, but you most likely want to get rude of most things.

    As said, I'll ask one of my colleague that knows more about hardware to confirm what I just wrote. 

    Best regards,

    Simon D-M

  • Thanks Simon much appreciated. I realise it’s just a dev board but for a beginner getting used to the platform being able to use it as an initial prototype is very desirable. My plan is to prototype using the dev board at first and then later develop the solution with a ready made nRF9151 module and then eventually a full blown board of my own.

    It sounds like it’s probably ok to have it powered through VIN and connect a macbook for debugging, since a laptop isn’t going to act badly on the usb bus and send silly voltage through it and will handle incoming transients sensibly. I think as long as that’s relatively safe to do then this should all be fine, hopefully your hardware person can clarify. I was initially thinking of creating a shield type board to use for the prototype where using the other header would have been handy but now I’m thinking it would probably make more sense to just have it be a separate thing with a connector.

    Cheers,

    Mark

  • Oh one other thing - it would be good to know if it’s likely that the board will reset when switching between VIN and USB

Reply Children
No Data
Related