Startup Problem STM32F10x

[gkennerknecht]

Posted on May 15, 2014 at 15:40

Since about five years we�re using the STM32F103RET6 Controller within our Devices and our Application.

In between these five years we did only minimal changes at the Software and the Startup. With the last Shipment of Controllers the Devices Part Numbering changed form ARMl to ARMx. Up from this Point we have big Problems to get the Application Software running. It seems to be a Temperature Problem, if we cool down the Controller below 10�C the Apllication Software starts. This effect could be reproduced without Problems on each PCB. We are sure the Software and the electronic components are correct, because this product exists since five years. Does anybody have the same Problem, or could anybody help me to solve this strange effect. #stm32

[waclawek.jan]

Posted on May 15, 2014 at 17:04

What exactly ''we have big Problems to get the Application Software running'' means? Could you determine whether the application did not start running at all, or it starts the initialiation code and fails to get beyond some step, e.g. waiting for PLL to stabilize, or similar? Any suspicious level/activity on the reset pin? If crystal used, does it start to oscillate?

JW

[Trev]

Posted on May 15, 2014 at 17:13

Check the value of the crystal loading capacitors.

[Tesla DeLorean]

Posted on May 15, 2014 at 18:36

So a stepping of ''1'' ONE vs ''X'', I don't recall the history/details, you should also look at the date codes for the parts. You should contact your local ST rep or FAE, with the details of your issue, and the parts you are using.

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/errata_sheet/CD00190234.pdf

The steps could address issues or be die shrinks. Check if the stepping changes the gain in the oscillator design. I'd look very specifically at your start up code, how the clocks come up, if they do, if there are timeouts, and as Trev suggests look at the crystals, and loading components. Make sure the capacitors are in fact capacitors and of the correct values. You could also observe the clocks indirectly via the MCO (PA8), and this should be used instead of sticking scope probes on the crystals which will distort the characteristics of the circuit.

[gkennerknecht]

Posted on May 16, 2014 at 07:32

Thank you all for the quick Responses.

We observed our load capacitors, and it seems to be all right, also we checked the oscillator, and it runs. Also the Clocktree is all right, we don´t get stuck in any loops. Thank you clive1 for the errata. We are in contact with our Distributors and sales Partners, and also with ST Technical Support. But until now we don´t understand these temperature effect. If we cool down the Application Software starts up. Today i will If I get more Information/News, i will let you know. Thanks

[os_kopernika]

Posted on May 16, 2014 at 20:27

''It seems to be a Temperature Problem''

Your opening post lacks a very important ''detail''. IMHO you should start the topic from: ''Our design does not violate ST specification of the product''. Without that freaks would ask countless questions:

• Q1: Are you sure caps are caps and resistors are resistors
• Q2: Are you sure it is 3.3V and not 33V
• Q3: Did you tripple-check LQFP orientation
• ....
• Q497: Does your flash run with recommended wait states
• Q498: Are these from reputable distributor

and alike. It is irrelevant if your design was running fine or not on different hardware. You could violate some design rules then and if that worked previoysly then does not mean it has to work now. ''if we cool down the Controller below 10°C the Apllication Software starts. '' AFAIK the uC starts after applying power, (within its operating conditions). Place some ''blinky.asm'' under 0x0 and give it a go.

[Tesla DeLorean]

Posted on May 16, 2014 at 21:50

Without that freaks would ask countless questions:

Yes, but then again one reel of 0402 caps looks much like another, or resistors/inductors, and if someone pulls the wrong one from the stock room, or puts it on the wrong pick-n-place feeder, you are going to have a really bad day.

[os_kopernika]

Posted on May 17, 2014 at 00:07

''Yes, but then again one reel of 0402 caps''

I just wanted to clarify which scenarios this topic represents:

• A: The case of a uC that does not meet the manufacturer's specification (as OP suggests ''we apply power and it does not run'') or
• B: ''Do I have to connect all Vdd pins?'' topic.

[Tesla DeLorean]

Posted on May 17, 2014 at 00:57

Or C) It runs, just not how we want it too, likely stuck in a loop somewhere we have yet to identify.

The chip does not exhibit much in the way of signs-of-life if the code malfunctions early. One of the quickest ways is to pull BOOT0 high, and check USART1 to see if the System Loader came up, or not. If it's temperature sensitive perhaps it's a soldering issue, the pin material, or type of lead-free solder. Bet there's a different batch of solder, or run of PCBs in the mix too. Check the state of the NRST line, and the behaviour of the reset circuit. Put the NEW chip on an OLD board, put an OLD chip on a NEW board, see where the problem goes.

[gkennerknecht]

Posted on May 19, 2014 at 16:33

Hey,

we tried a little bit more regarding pcb and clock sources. What we found out, it´s a real temperature Problem. If we set the HSITRIM register to trim the internal oscillator, we get the application running. The strange Problem until now --> we could program the Controller, reset the device and the device is running. if the Controller heats up, and we do a reset (NRST- Pin or Software Reset), the application didn´t run.   Now we played a Little bit more with an infrared Camera and the HSITRIM Reg and it seems to be the internal oscillator calibration. If the HSITRIM isn´t calibrated, our software starts up until we reach 44°C, if we reach more than 44°C, the internal oscillator isn´t stable, and we aren´t able to setup the external HSE Oscillator source. If i´ll get further News, i will let you informed. Thanks