Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations KootK on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Turn-on circuitry: MCU startup time too long.

Status
Not open for further replies.

evanwi92

Electrical
Feb 23, 2016
4
Hi,

It's my first post on here. Thanks for the support!

I'm developing on an STM32F410RB Nucleo and have a need for a simple, pushbutton on/off switch for my project.

I'd like the pushbutton to be the single on/off switch, however the system will also need to be able to turn itself off. I would like to use a single power regulator for the whole system which include the MCU and plenty of power-hungry auxiliary components.

I was looking at latches and flip-flops that could sit above the power regulator, however I finally went with a simple design that works as follows (see attached schematic):

- Initial pushbutton grounds series resistors (voltage divider) that lowers voltage on a P-FET that sits at battery voltage.
- this closes the FET and supplies Vbat to the power regulator (30v to 3V3)
- power regulator supplies voltage to MCU and aux components.
- first command for MCU is to push a GPIO high (for the purpose of latching the power on)
- the GPIO drives an N-FET that keeps the series resistor / voltage divider flowing which keeps the voltage low on the P-FET (keeps it closed).
- MCU chooses to stop GPIO and cut power anytime or when the external interrupt from another press of the pushbutton comes in (external interrupt on separate pin, parallel to first press circuitry).

I've tested the above process and it works well, however the MCU takes time to turn on and reach that first command in the main loop.

I'm having to wait 4-6 seconds before the MCU drives that GPIO to latch power on.

I'm not sure if this is the minimum boot/start up time for an MCU or if that can be reduced.

Any information or help on the subject of getting an MCU to execute main loop quicker upon power-on would be greatly appreciated.

Thank you!

Evan
 
 http://files.engineering.com/getfile.aspx?folder=a49b956d-4877-4b55-8038-df1155084209&file=turn_on_circuitry.PNG
Replies continue below

Recommended for you

You've got a challenge going there. That processor is capable of starting up in microseconds but it's embedded in the whole board running an operating system. The operating system is dictating the startup. You're stuck with what you have short of a lot of work and fundamental knowledge of how the entire system works so you could alter the operating system to prioritize getting that pin to hold the power on.

A much simpler end-run is to put some timing logic in your power-up circuitry that holds the button down for you, for that initial 4 seconds AND lights a LED so users can recognize the button push has been effective. This shouldn't be a problem as modern users all recognized there are delays in electronic's start ups. Every cell phone has them as does every TV.

Keith Cress
kcress -
 
Yes, everywhere I've read it would seem the processor could start up that quickly however I'm sure the abstraction of the compiler is bogging it down.

That's great advice to have some hardware give the user feedback before the system is actually on. Do you have any recommendations and experience with this?

However back to getting the STM32F4 to the first issue,
1) is it not common to totally power down an MCU like this? It seems they are recommended putting the MCU in standby and waiting for external interrupt for wakeup, however that would require a dedicated regulator for the MCU to be on 24/7 and another regulator for the aux components that the MCU could turn on.

2) Is there a resource where I can dig into the OS and compiler to minimize that start-up time? 4-6 seconds seems excessively long in the embedded world. I'm wondering if its hardware on the nucleo that is taking so long to get power to the actual MCU. In debug mode (power from USB), there is no delay.

Thanks for all your help!

Evan
 
Quick starting a CPU usually requires ground-up design considerations. Trying to tag it on later is typically very hard and not worth it. The designers of the Nucleo chose not to bother with the extra effort required to isolate the processor from the periphery and the added regulator you correctly surmise. I can't blame them too much as it would mean several more $ in the sell price in an admittedly massively overcrowded field of !use-me! processor boards.

Off hand I don't have a startup circuit for you but there are scads of ways to do it. You just need a circuit that latches ON for a countdown the countdown being a second longer than the slowest possible Nucleo boot. I'd maybe start with 555 circuits? If you only need a 5 seconds just a comparator and some capacitor games might do the trick.



Keith Cress
kcress -
 
Looked at the 555 timers as you recommended. Actually made me think of this possible solution (see attached pic):

Current circuit is in blue. If I add the 1k resistor between the 3v3 supply and the latching FET gate, then there should not be a delay in latching.

I can configure the Keep On GPIO to an open drain output and re-title it to "Turn Off". Therefore the GPIO pulls the gate to ground with about 3mA going through the open drain.

What do you think? Would I still need the 100k pull-down? Would the open drain be effective at pulling the charge off the N-FET gate?

Got everything to try it here in-house actually. I'll give it a test.

Evan

 
 http://files.engineering.com/getfile.aspx?folder=30f8505c-dad8-4c23-beb5-7e1df0b66720&file=IMG_7760.JPG
UPDATE:

Tested the concept above and it worked very well. Latch is instantaneous and MCU successfully pulls charge off the gate to turn off.

I wouldn't have imagined the solution being as simple as adding 1 resistor and changing a line of code.

Thanks for the help,

Evan
 
Excellent solution. It's only drawback might be a crashed processor not actually booting-up but still leaving the entire system powered up and draining the battery. My original suggestion eliminated that possibility because the ON signal only lasts slightly longer than needed for the boot process. If, say, the boot failed it would shut down again using the "human" to try it again.

You still might want some sort of confirmation from the processor for this 'watchdog' function.

Keith Cress
kcress -
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor