2015-05-27 12:51 AM
Hello there,
I've noticed that the in my application the start-up time, i.e. the time from power-up to the first instruction in main() is about 7 to 8 ms. This seems very long to me.I'm using a STM32F103RC and the IAR compiler. I changed system_stm32f10x.c so it configures the STM32 to run with HSI at start-up by commenting all the defines for SYSCLK (e.g. SYSCLK_FREQ_HSE etc.). So I would expect a start-up time of about 50 microseconds (as noted here: http://www.silica.com/designers-community/forum/view/topic/stm32_disable_por_at_startup_to_reduce_startup_timeower.html).Why does start-up take so long? What am I missing?Regards,Roman2015-05-27 02:22 AM
I can think of a couple of things you might consider:
1) Software only starts executing when the processor comes out of reset. You don't mention what board you are using, but some boards deliberately hold the processor in reset for some time after power is initially applied to ensure that power has stabilised. This might simply be an R-C combination on the Reset pin, or through use of a power-supply-monitor chip.2) All global variables are initialised before main() is called. Although this might be as simple as copying (many) variables from FLASH to RAM in C code, if you're writing in C++ then the constructors are as complicated as you (or any of your library providers) have written.Hope this helps,Danish2015-05-27 02:36 AM
One more thing to consider is the startup time of a crystal oscillator, if you use it.
JW2015-05-27 03:25 AM
Attached you cand find the schematic of our PCB. As you can see, we are using a 8 MHz crystal for HSE and a 32,768 kHz crystal for LSE. Do these two crystals affect start-up time even if the STM32 runs from HSI at start-up? HSE and LSE are initialized only later in main. By the way, I'm programming in C.
________________ Attachments : Schematic.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0v5&d=%2Fa%2F0X0000000bg8%2FGQ7CMPDLoSAxKPaEaHSv1bCYVSnDO2OAfpe0xreFmwg&asPdf=false2015-05-27 03:43 AM
I guess the value of the capacitor on the NRST pin is too high (100 nF) in combination with the 40 kOhms of the internal pull-up resistor. This results in a time constant of 4 ms. Could that be?
2015-05-27 03:44 AM
By the way, I'm programming in C.
This suggests you also have access to the startup code. You could dive into Assembler coding, and add some GPIO pulsing shortly after the reset handler, to measure when the MCU actually comes to life. Or, perhaps the startup code contains some ''exotic'' initialisations. Mechanical systems (e.g MEMS sensors) and displays often need such long startup times.
2015-05-27 04:15 AM
Some toolchains insert HSE initialization into startup before main (this is mandated by CMSIS/ARM, but some toolchains are sane enough not to obey, and user may have overriden that too [EDIT] SORRY I now realized you did exactly this and reported about it in the original post Sorry again [/EDIT] ).
The capacitor on reset pin might have add to the startup time - this is easy to check, simply remove it or exchange for a significantly smaller value. For production, you should try to get down to the root of why the DS talks about ''reset circuit sensitivity'' and recommends the 100nF capacitor. For extra fun, look up ''temporization'' in the DS/RM. I doubt you could get rid of that one unless you represent significant buying power for ST to pay more attention. JW2015-05-27 05:07 AM
You didn't show the power supply on the schematic. That long a delay to first instruction suggests your voltage regulator needs several milliseconds to stabilize before the 3.3V supply is valid. The controller will hold itself in reset until the 3.3V reaches the threshold to start running. Look at the rise time for your 3.3V logic supply.
Jack Peacock2015-05-27 05:48 AM
Yes, I didn't show the power supply because with ''power-up'' I meant the 3,3 volts. It's about 7 to 8 milliseconds from stable 3,3 volts to the first instruction in main. I will remove the capacitor to see if that is the reason.