2014-05-15 06:40 AM
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. #stm322014-05-19 07:33 AM
''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.2014-05-19 07:48 AM
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? JW2014-05-19 09:40 PM
hello,
i´ll look for that at Weekend. the following two days i´m on another Project.2014-05-20 06:27 AM
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.
2014-05-20 06:28 AM
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.
2014-05-22 09:56 PM
2014-05-29 01:01 AM
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.