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

[os_kopernika]

Posted on May 19, 2014 at 16:33

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

This is still B. Perhaps B.53, B.54 or even B.55 but still B. It indicates that a uC meets the ST specification.

[waclawek.jan]

Posted on May 19, 2014 at 16:48

And what is the value of RCC_CR.HSICAL bitfield? What is the ''cold'' HSI frequency with default HSITRIM?

Also, is VDDA/VSSA connected to VDD/VSS, and is there a ceramic capacitor across these pins close to the package? JW

[gkennerknecht]

Posted on May 20, 2014 at 06:40

hello,

i´ll look for that at Weekend. the following two days i´m on another Project.

[mpanju]

Posted on May 20, 2014 at 15:27

Hello, we too have a start-up problem since December when the new batch of micros arrived. Prior to that we have made thousands of units without any problems, now suddenly this problem has cropped up. We use STM32L152 processor with internal HSI clock. What we have observed, is that when we switch over to HSI clock having first checked that it is stable, the device goes into Hardware fault interrupt. With debugger, we can run from reset up to switch over point and single step it through and it is fine, but if we try to run to the statement after switch over, it fails. It also fails in run mode. This happens with approximately 10% of the micros. Has anybody else come across this problem? I will now check the trimming of internal clock as describe here.

[mpanju]

Posted on May 20, 2014 at 15:28

Hello, we too have a start-up problem since December when the new batch of micros arrived. Prior to that we have made thousands of units without any problems, now suddenly this problem has cropped up. We use STM32L152 processor with internal HSI clock. What we have observed, is that when we switch over to HSI clock having first checked that it is stable, the device goes into Hardware fault interrupt. With debugger, we can run from reset up to switch over point and single step it through and it is fine, but if we try to run to the statement after switch over, it fails. It also fails in run mode. This happens with approximately 10% of the micros. Has anybody else come across this problem? I will now check the trimming of internal clock as describe here.

[gkennerknecht]

Posted on May 23, 2014 at 06:56 Hello, i found out sth. more. I´m sure it´s a temperature and HSI Problem. If we exceed a temperature of about 45 degree, the internal oscillator doesn´t start up. I have observed it via the MCO Pin also. We tested the HSI Calbration and observed the HSI/HSE Flags. But it´s only possible to debug, if the internal oscillator is running.   I´m also in Contact with technical support, because i´m not the only one with this strange effect. Anyone further ideas?

[mpanju]

Posted on May 29, 2014 at 10:01

We managed to solve the problem by trimming the clock. We use HSI as our main clock.

The clock frequency is below 16 MHz, but that is not critical in our application. The following line was added:  /* Enable HSI - 16 Mhz Internal clock */  RCC_HSICmd(ENABLE);  // Trim the HSE clock to 0x00  RCC_AdjustHSICalibrationValue(0x00);The default value is 0x10. Changing to 0x08 worked on most units but not all. Setting to 0 has cured the problem, now the batch of 200 has passed. It is obvious ST has a problem with the HSI oscillator in the new batch of processors, and I hope they now make it public.