Power-on LED design with MCU override

[GarthyD]

I am designing a board that has two 5V+ power sources plus a Li-Po rechargeable battery that powers the rest of the circuit via an LDO at 3.3V.

Of all things in the design I am actually having the most trouble with the power-on LED (yeah, I know), and I was wondering if I could get some advice as to the best way to approach this.

The ideal version of what I am after is as follows:

- By default the power LED should turn on if either of the two power sources have power. If both do not, it should be off.

- Additionally, the MCU should be able to override the LED via a single pin. If the pin has not been set to output by the MCU (high impedance), I want the default LED behaviour as specified above. Otherwise I want a low or high output to turn the LED on or off, regardless of the default. It doesn't matter if low=on or low=off, whatever is easier.

Some things to note:

- The two power sources will be around 5V+ each, and almost certainly not equal. There will be multiple parts in the main circuit that cannot handle 5V so they cannot be exposed to it.

- The LED should behave as expected even if the MCU is completely removed, ie. the logic needs to be in the circuit rather than the MCU.

- Due to the battery, the circuit will generally be operational even if neither of the 5V sources are connected.

- When the LED is off *and* the MCU has not overridden the LED to be on, I want to absolutely minimise the current needed. The circuit will still be connected to the battery, and I don't want my project to destroy a Li-Po just because the device wasn't used for a few months.

- When the LED is on I'm not as fussy about power use, as it means that we've got some sort of 5V source connected.

- The LED will need to be powered by the 3.3V source, as the MCU may choose to turn it on (override) even with no 5V source connected.

- I am after an economical solution. Economical in the sense that I don't want to use $5 worth of parts if 20c of parts would do the same job. On the other hand if it's simply going to cost $5 worth of parts to do it right, I'm fine with that. So I'm not that cost-sensitive, I just don't want to be wasteful.

- A drop-in IC that can do the same job is also fine. A set of low-cost ICs are also fine. So are a bundle of BJTs/MOSFETs.

- Ideally restricted to hand-solderable surface-mount or through-hole components. I have breakout boards.

In the worst case I can scale back my objectives and implement something close-enough to my ideal solution instead.

I am a novice with electronics, although quite fine on the MCU and software side. I am still fairly new to using MOSFETS and am also using this as an opportunity to learn more about them.

I've had a crack at a solution, image/link below once I find a way to attach it. It is not tested yet, and I expect to find problems and/or need to correct my understanding as to how MOSFETs work. The basic idea is that if either of the two power sources (5VIN, USB5V) provide power, they will enable the corresponding MOSFET and drive the signal on the line near PWRLED low. A pull-up to VCC handles the default case. PWRLED is from the MCU. If high or low (low=on, high=off) it will override the values from the MOSFETS (which are behind 10k resistors). The output from this stage is then inverted and drives another MOSFET which controls the LED.

Input very welcome. I'm curious as to the usual way to approach this sort of problem. I've been struggling with this problem longer than I should have. :/

[danadak]

You want to ,measure two voltages as part of controling MCU, yet you want
circuit to do all this w/o MCU.

Two alternatives -

1) Use 2 MCU, one that can be removed, the other measuring voltages and controlling
LED.

2) Use 1 MCU, do all logic, and put to sleep when not needed.

Cypress PSOC 4 perfect candidate for either solution. Has reference, A/D,
OpAmps, DAC, tons digital, lots of "other", cheap. $ 1 in volume.


Regards, Dana.

[danadak]

For me what stands out is -

1) Routability
2) Fast 12 bit SAR A/D and slow 20 bit DelSig
3) DFB (Digital Filter Block) that is dual channel, handle FIR or IIR filters, or DFB
can be used as a GP fast processor block, similar to RISC block
4) MSI logic elements GUI based and/or the UDB Verilog capability. Eg. the FPGA
like capability
5) Onboard Vref
6) IDAC, VDAC, OpAmps (up to 4), comparator, mixer, switch cap, analog mux....
7) LCD,  COM, UART, I2C, I2S, One Wire, SPI, Parallel, LIN, CAN, BLE, USB
9) Custom components capability, create with schematic capture or Verilog
10) DMA to offload processes like filters, COM, Display
11) ARM M0 (PSOC 4) or M3 (PSOC  5LP) or 8051 core(PSOC 3)
12) Extensive clock generation capabilities
13) All components supported by extensive prewritten APIs

https://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=true

http://www.cypress.com/documentation/code-examples/psoc-345-code-examples

Great video library

Attached component list.  A component is an on chip HW resource.

Free GUI design tool with schematic capture, "Creator". Components have rich API library attached
to each component. Compilers free as well.

PSOC 4 is low end of family, consider 5LP parts as well. PSOC 4 also has arduino footprint boards (pioneer) as well

https://www.elektormagazine.com/labs/robot-build-with-cypress-psoc

http://www.cypress.com/products/32-bit-arm-cortex-m-psoc


Contact the local sales office, "RSM", regional sales manager, and FAE as well, maybe they can give you some stuff as well.
Never be afraid to ask. Even contact the Manufacturers Rep, sometimes they can have some boards laying around not being
used.


Regards, Dana.

[Ammar]

As mentioned you could use a second MCU to handle what you require. A PIC10LF322 has a sleep mode that consumes so little power it's silly and should meet your requirements.

When you say "The LED should behave as expected even if the MCU is completely removed", do you mean physically removed? If not, then a low power MCU on its own should do the trick.

[GarthyD]

Thanks for taking the time to look at my problem, much appreciated.

You want to ,measure two voltages as part of controling MCU, yet you want
circuit to do all this w/o MCU.

Not exactly. I am not measuring a voltage as part of controlling a MCU. I do want a circuit to control the LED that does not require the presence of a MCU to operate.

If either of two power sources have power present I want a single LED to light. I would like to be able to override the LED state using a single line coming in. For example: Hi-Z means no change, low means LED off, high means LED on. That line coming in just happens to have a MCU at the other end.

The "why" of it will probably help. Basically, I want a LED that confirms that external power is being supplied. If the MCU has a valid program and is running, I want the MCU to be able to take control of the LED. Perhaps to turn it off, and perhaps to use it to blink out an error code.

The Pi 2 can do something (seemingly) similar. The power-on LED lights when power is supplied, but you can override this in software. What I'm asking is a bit more complex than what the Pi is doing, but the idea is similar.

To clarify the MCU side of things, I've already got a MCU and have mostly written the software for it. I'm just trying to figure out how to manage the power-on LED without the control being implemented on the MCU.

2) Use 1 MCU, do all logic, and put to sleep when not needed.

Leaving the management to the MCU is a tempting solution (particularly as it shifts the problem to somewhere where I have considerably more experience) but leaves out the desirable case of being able to see that the board is supplied with power, but the MCU is not working. This is one of my fallback options.

1) Use 2 MCU, one that can be removed, the other measuring voltages and controlling
LED.

This could be my inexperience talking, but it almost seems overkill to dedicate a MCU (even a cheap one) to the task of managing a power-on LED. However, there is the possibility that what I am after might be complex enough to warrant one. Still, it surprised me. I might also have explained the problem poorly- I hope the clarification above helps.

Another fallback is to simplify things to just a single input being used to force the LED off.

Many thanks for your input on potential MCUs to use, plus all of the detail.

When you say "The LED should behave as expected even if the MCU is completely removed", do you mean physically removed?

Sorry, I may have explained this badly. Basically my goal is to come up with something that works independently of the MCU working or not. My intention in stating "even if the MCU is completely removed" was to say that I wanted to ensure that this part of the circuit was in no way dependent on the MCU. There will always be a MCU there, but it might not be running a valid program, or might have failed in some way.

[GarthyD]

Okay, I've hooked up most of my first guess for circuit layout (up to the gate for the second-to-right MOSFET) and it appears to be working as intended. I'm guessing that the pair of N-channel MOSFETs on the right aren't the best way to do things (they'll leak current when off), so I'm guessing  a 3.3V level P-channel MOSFET would be a better fit.

I've attached my best guess as to how this may look.

I don't have any 3.3V P-channel MOSFETS yet (hopefully in 2-48 hours), so I can't actually test this, but I think it'll work when I do.

Feedback welcomed.

[MK14]

You should be able to do it with a simpler circuit, such as this:



A/B/C etc are the various supply rails.
The MCU could override the LED on/off status, by connecting the transistors base to a floating while off, MCU output pin (If the MCU datasheet allows this. I'm NOT sure how you are powering the MCU and/or if it is physically installed when disconnected. E.g. A ZIF socket, or is it present but not powered, or still powered ?). Make the resistor between the base and the diodes common cathodes suitably big, e.g. 22K.
The LED would go in series with the resistor, between the collector and the +V supply.

If the MCU's datasheet, does NOT allow a diode drop, about 0.7V of voltage on an output pin, while NOT powered (if that is what you are doing, I'm NOT sure). Then you would be best to put an extra second transistor between the output pin and the base of the first transistor. Hence allowing the MCU to override the LED status, and still meet the datasheet specifications.

[GarthyD]

Many thanks for putting together a potential solution.

Answering a few of your questions:

The MCU is powered by a rechargeable battery connected to a 3.3V LDO, the output of which powers most of the circuit. Both sources go to a charger IC that charges the battery. The battery power source can be assumed to be present, because either it is there, or one of the other sources is providing power.

The MCU will be physically present, soldered on, no socket. It may not be working fine, or might be running code that will not ever set the override pin to an output. I've included some extra detail in the last paragraph of my post two posts prior.

The MCU is a SAM4E series (ARM). Pins are tolerant to 4V. I *believe* it'll start up in Hi-Z and act that way until specifically enabled as an output.

I am not aware of a diode drop causing an issue on the output lines, but I am not certain.

Please let me know if I've missed anything.

If I've understood your layout and description correctly, I believe there will be an issue with overvoltage if there is no diode present between the MCU and transistor base as soon as either power source is on (~5V - 0.7V > 4V). Although, maybe a voltage divider before each diode? I *think* it won't be able to override the LED with a low signal if the diode is present. In any case, I'm not sure I know enough to determine the behaviour if the MCU input line is low?

...

I've built my prior solution now, and it seems to work okay. I think it is fairly efficient. There doesn't seem to be a path to ground unless a power source is connected or the MCU drives the line low to enable the LED. There was a mistake in my previous schematic (P-channel MOSFET orientation). I'll attach a fixed schematic.

I'm not sure of the tradeoffs between the two approaches thus far (MOSFET vs diode).

[MK14]

If I've understood your layout and description correctly, I believe there will be an issue with overvoltage if there is no diode present between the MCU and transistor base as soon as either power source is on (~5V - 0.7V > 4V). Although, maybe a voltage divider before each diode? I *think* it won't be able to override the LED with a low signal if the diode is present. In any case, I'm not sure I know enough to determine the behaviour if the MCU input line is low?

In the circuit I just supplied. The Base/Emitter junction, should keep the voltage between 0V (Ground) and about 0.7V, because of the (approx 22K) resistor, between the base and the diodes. So the 4V tolerant Arm MCU pins, should be fine.

I've built my prior solution now, and it seems to work okay. I think it is fairly efficient. There doesn't seem to be a path to ground unless a power source is connected or the MCU drives the line low to enable the LED. There was a mistake in my previous schematic (P-channel MOSFET orientation). I'll attach a fixed schematic.

I'm not sure of the tradeoffs between the two approaches thus far (MOSFET vs diode).

Since you have built your circuit (I was late to this thread, so I knew you may have done that, NO PROBLEM), and it seems to be working. You are probably best to keep to that circuit.

The reason I suggested it is because. Diodes are usually smaller/cheaper and you are even more likely to have them in stock. They are a bit more robust, as if your 5V connections are via plug/sockets (if permanently connected, then should be protected against ESD). You could have a danger of breaking the input gates of the mosfets, with static electricity.

On the other hand, if the single transistor circuit I showed, had needed more transistors. Then a circuit like you have shown, maybe with bipolar transistors (much less ESD issues) instead. May have been a viable alternative, anyway. But you can use mosfets and solve any ESD issues, which may not be present, as long as it is permanent (no removable connectors).

tl;dr
Mosfet's gates don't like higher voltages (e.g. > 15 to 20 volts). Best to see datasheet for exact voltage limits. So if any of the power connections can be opened up by the user. E.g. USB connectors or other plug/sockets. They could pick up stray static electricity (ESD), and get damage. But there are ways of protecting inputs from such damage. Such as back to back diodes or zeners. But you have to be careful to not interfere with the circuits correct operation, when doing this.

[GarthyD]

Thankyou yet again for your help with this problem and for taking the time to explain things to me.

In the circuit I just supplied. The Base/Emitter junction, should keep the voltage between 0V (Ground) and about 0.7V, because of the (approx 22K) resistor, between the base and the diodes. So the 4V tolerant Arm MCU pins, should be fine.

Based on my current understanding I was uncertain whether the voltage would really be around 0.7V at the base. So I hooked up that part of the circuit and measured it and.... you were dead right! I saw 0.67V at the base. To make sure I wasn't going mad I checked the other side, and it was 4.5V (NB: 5V through a diode, so 4.5V was expected).

I have to say that I don't entirely understand the reason, but I am guessing it has to do with the current flowing through the gate to ground acting as a voltage divider with the 22k resistor? My existing understanding of transistors is insufficient to understand the reason. If you're happy to point me in the right direction I can read up on the theory.

You are probably best to keep to that circuit.

Perhaps. It's hooked up in my prototype at present, but part of this process is trying to find better solutions, and it seems likely that the one you have come up with may be superior.

Diodes are usually smaller/cheaper and you are even more likely to have them in stock.

I'm not surprised to hear this. After seeing your solution I went and researched diode prices and I was given the impression that they may be cheaper. However I hadn't been through their specs, so I didn't know if I was comparing like for like.

They are a bit more robust, as if your 5V connections are via plug/sockets
So if any of the power connections can be opened up by the user

The most important power source of the two is the USB power source, so it would seem that I will need to be quite aware of ESD issues. My knowledge in this area is presently nil. I was thinking of asking about power source issues (beyond the LED light) once I'd gotten a bit more familiar with the issues affecting them.

Thanks for your additional consideration of the tradeoffs between BJTs, diodes, and MOSFETs in your solution. I don't yet have the experience to make this sort of judgement.

Then a circuit like you have shown, maybe with bipolar transistors (much less ESD issues) instead.

At a guess I'd be able to swap the two N-channel MOSFETs with BJTs.

I've attached an updated layout, and included a bit more detail on the rest of the power side of the circuit. It is still very much a work-in-progress. Included are the charger and regulator I am using. The bulk of the circuit will run on the 3.3V output of the regulator, with some exceptions. There is an additional LED to indicate charge with a similar override, which I didn't mention initially to simplify the problem.

In the bottom right I've put together a best-guess of how a diode-based solution would look based on your schematic and description. Please let me know if any corrections are needed. One thing I am uncertain about is the connection of the MCU pin to the transistor base. I'm assuming a resistor would be needed, and put a 1k in place for the time being. I can't figure this last bit out though. If there is no resistor then a MCU high would short to ground through the base? If there is a resistor, then this will change the voltage at the gate, and I am not sure how the current will flow. I'm concerned that with the wrong resistor that some current will flow when the MCU overrides low, which might make the LED turn on (albeit dimly). I am quite uncertain about this though. I hooked it up experimentally using a 1k resistor, single diode and power source, and my multimeter detected zero current flow through the LED when the override line was grounded. Perhaps I am wrong to be concerned. It is a cheap multimeter though.

[MK14]

You seem to have drawn the circuit I was trying to convey to you, very nicely!

The Emitter/Base junction of a bipolar Junction Transistor (BJT), is basically a diode. At low currents (100mA or less), there would be about 0.6 to 0.7 volts across this "diode". I usually call it 0.7 Volts. But some call it 0.6V. (With a few mA's, 0.7 is usually fairly close).
Strictly speaking, the exact voltage can vary a bit between devices, slightly with current levels, and with temperature.

Because the MCU output, will be close to 0V (assuming it is a modern MCU and the currents are rather small. Best to check with datasheet) when off (logic 0). The diode (Emitter/Base Junction), will cause almost no current to flow. Hence why your 1K base resistor (value seems a reasonable/good starting point), sees almost zero current through it, when the output is off. Which is good.

As requested, here is the (optional) reading material.
https://inst.eecs.berkeley.edu/~ee100/su07/handouts/DiodeTransistorNotes.pdf

But there are many possible sources of information. That one goes into LOTS of the possible details and other components, which are related to it. It also seems to nicely go into the finer details about the 0.6/0.7 voltage drop.

[GarthyD]

Many thanks again MK14 for your continued input.

Thankyou for the additional explanation.

I had a quick skim of the reading material you supplied, but didn't quite grasp the reason on my first pass. I'm giving it a more thorough read and will try to fill in the gaps in my knowledge. Thankyou for your recommendation.

Once I've figured this out I'm going to try to come up with a similar solution for the charging LED. For this, CHGA is either active low if charging, Hi-Z if not. It's a bit different to this problem, but I imagine there is a similar elegant solution.

[MK14]

Warning: The links I give below, explain about diodes, rather than explaining about the Emitter/Base junction of bipolar junction transistors. But that was all I could find with a quick look.

Maybe this is a better article for you:
https://learn.sparkfun.com/tutorials/diodes/real-diode-characteristics

For a forward biased diode or bipolar transistor Emitter/Base junction. The following graph, begins to explain about the 0.7 Volts across it, when a small current is flowing:


Which is from here (probably too long and detailed for your purposes):
http://www.allaboutcircuits.com/textbook/semiconductors/chpt-3/introduction-to-diodes-and-rectifiers/

[JiggyNinja]

Sorry, I may have explained this badly. Basically my goal is to come up with something that works independently of the MCU working or not. My intention in stating "even if the MCU is completely removed" was to say that I wanted to ensure that this part of the circuit was in no way dependent on the MCU. There will always be a MCU there, but it might not be running a valid program, or might have failed in some way.

So how do you determine that the microcontroller hasn't failed in a way that sticks the LED off? If the micro is capable of controlling the circuit and is always connected to it, it is not in any way independent.

[JiggyNinja]

- The LED will need to be powered by the 3.3V source, as the MCU may choose to turn it on (override) even with no 5V source connected.

What I said in the last post goes double if the microcontroller is capable of overriding the LED on, and not just off. If the program fails, you can't trust the LED AT ALL.

[GarthyD]

Sorry for the slow reply on this one.

So how do you determine that the microcontroller hasn't failed in a way that sticks the LED off? If the micro is capable of controlling the circuit and is always connected to it, it is not in any way independent.

What I said in the last post goes double if the microcontroller is capable of overriding the LED on, and not just off. If the program fails, you can't trust the LED AT ALL.

There are really only two states that I can indicate with a single non-animated LED. I'm happy with the particular split I've chosen here. The ability to override is a hard requirement. With this in mind, how would you approach this instead?

Maybe this is a better article for you:
https://learn.sparkfun.com/tutorials/diodes/real-diode-characteristics

Thankyou MK14 yet again for the wealth of information.

The Sparkfun article looks familiar, and I suspect I had gone through that article already. However I went through it again with your recommendation. I definitely hadn't seen the All About Circuits one through, and I've gone through that one as well.

There's still a gap in my knowledge here- although this time I know where that gap is. I had completely misunderstood how the voltage drops across the resistor in this particular setup. Time for me to brush up and improve my incomplete understanding here.

...

There has been a bit of an update with this part of the design. For an unrelated part of the overall board design I am investigating using a CPLD. If I do end up using one, the functionality here may instead just be rolled into the CPLD. If I don't, things should be unchanged and I will almost certainly be using the diode-based design discussed here. Even if I *do* use a CPLD for my current design, I'll be designing a second board which will not be able to include a CPLD. This second board will also have power and charge LEDs, so I should be able to apply what I have learned here to the design of this board as well.

[MK14]

There has been a bit of an update with this part of the design. For an unrelated part of the overall board design I am investigating using a CPLD. If I do end up using one, the functionality here may instead just be rolled into the CPLD. If I don't, things should be unchanged and I will almost certainly be using the diode-based design discussed here. Even if I *do* use a CPLD for my current design, I'll be designing a second board which will not be able to include a CPLD. This second board will also have power and charge LEDs, so I should be able to apply what I have learned here to the design of this board as well.

That's the thing about CPLDs (or FPGAs, MCUs). Once you have got at least one of these in your circuit. You can potentially add functionality, without any extra hardware cost (in most cases), up to the limits of the device(s) you have used.
CPLDs can easily perform extra things, so that some of the circuitry simply gets put into the CPLD, rather than needs to be created in other hardware on your board(s).

[danadak]

PSOC 4 family, 4000 in specific, can be had for < 50 cents. Its got analog,
reference, ARM M0 core.....Why bother with a CPLD ?

Step up for a couple of dimes more to one with A/D, OpAmps....


Regards, Dana.

[GarthyD]

That's the thing about CPLDs (or FPGAs, MCUs). Once you have got at least one of these in your circuit. You can potentially add functionality, without any extra hardware cost (in most cases), up to the limits of the device(s) you have used.
CPLDs can easily perform extra things, so that some of the circuitry simply gets put into the CPLD, rather than needs to be created in other hardware on your board(s).

They seem very interesting and I imagine they are quite useful. This is my first time working with one. I have one partly working in my prototype at the moment (both hardware and software), but it isn't far enough along yet to make a solid call as to whether it will remain.

PSOC 4 family, 4000 in specific, can be had for < 50 cents. Its got analog,
reference, ARM M0 core.....
Step up for a couple of dimes more to one with A/D, OpAmps....

There is certainly an appeal to a sub-$1 MCU, and I can see myself grabbing one to experiment with at some point. I do already have a decent MCU selected for this prototype though.

Why bother with a CPLD ?

A CPLD is a closer match to the problem I am trying to solve than an MCU, which is routing a number of lines between different parts of the circuit. A MCU would have to constantly monitor the lines and react, whereas with a CPLD I can configure and forget, and it all happens in parallel.

EDIT: To clarify, I'm looking at a CPLD to solve a problem that is completely different to the one in this thread, but if I did end up using one it would be a solution that would easily absorb the problem being discussed in this thread.

[GarthyD]

An update: The final power-on LED design I used in my board was heavily based on MK14's suggestions.

This is the design that made it to the prototype PCB:



In the end, the presence of the CPLD on the board didn't matter at all. The power LED was a special case anyway.

I've since completed a prototype board with this design:



More info here:

https://www.eevblog.com/forum/projects/general-purpose-sam4s-mcu-and-max-v-cpld-development-board/

Thanks to all who contributed, particularly MK14 for the excellent suggestion and guidance.

[MK14]

Thanks for the update.
I'm glad it is working out well for you.
Your prototype is looking good!

[GarthyD]

Thanks for checking in. Not a problem re the update. Thankyou again for your help.

After adding the CPLD to the project I attempted to roll the LED control design into the CPLD as I had suggested I may do earlier in the thread. I could not find an arrangement that I was happy with. This came about because the signals coming in and the power feeding the LED were from vastly different sources with different voltages and their own requirements for use. I realised that the power LED really *was* a special case that needed a dedicated solution. The solution of the form you had suggested solved the problem in the best way.

The next board revision is going to have a slight change re the power LED. The PWRLED signal is driven by a CPLD line for maximum flexibility, but after working on the prototype I discovered there would be considerable value in driving it directly from the MCU on a dedicated line. This would make it the one on-board LED that the MCU can control directly without the CPLD. Some other planned design changes will free up at the required MCU line, so no problem there. The above schematic for the power LED would be unchanged, but the PWRLED signal would come from the MCU rather than the CPLD.