cancel
Showing results for 
Search instead for 
Did you mean: 

STM32103RC Firmware not starting, had to modify system_stm32f10x.c to work. Why?

uxdiesel99
Associate II
Posted on January 14, 2015 at 21:04

I have this problem where on certain boards, the firmware does not start. I have an STM32F103RC with ext 16Mhz crystal. Some boards work normally and some fail to start. Those that were failing, I fixed the issue by commenting the &sharpdefine SYSCLK_FREQ_72MHz  72000000 from the following code from the system_stm32f10x.c, hence will always use the HSI

&sharpif defined (STM32F10X_LD_VL) || (defined STM32F10X_MD_VL) || (defined STM32F10X_HD_VL)

/* &sharpdefine SYSCLK_FREQ_HSE    HSE_VALUE */

 &sharpdefine SYSCLK_FREQ_24MHz  24000000

&sharpelse

/* &sharpdefine SYSCLK_FREQ_HSE    HSE_VALUE */

/* &sharpdefine SYSCLK_FREQ_24MHz  24000000 */

/* &sharpdefine SYSCLK_FREQ_36MHz  36000000 */

/* &sharpdefine SYSCLK_FREQ_48MHz  48000000 */

/* &sharpdefine SYSCLK_FREQ_56MHz  56000000 */

&sharpdefine SYSCLK_FREQ_72MHz  72000000

&sharpendif

Why is this happening??

#stm32f103
5 REPLIES 5
Posted on January 14, 2015 at 22:11

Why is this happening??

Probably because ST typically uses an 8 MHz crystal? And the PLL settings are hard coded with that expectation? You'd have to port the system_stm32f10x.c at a project level to reflect YOUR hardware and design choices. Changing HSE_VALUE allows the baud rate, and other clock related settings, to decode the current register configuration into an actual speed, otherwise the HSE is unknown, some arbitrary external source.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
uxdiesel99
Associate II
Posted on January 14, 2015 at 23:05

Clive, thanks for the fast reply. What baffles my mind is the following points:

We have more than one board using the STM32, and we never changed the configuration files, and they all have 16Mhz Ext OScillator, and never had any issues. Only this particular board had the startup problems

Also, if the HSE fails, isn't it supposed to run on the HSI, why does the code freezes?

Also this particular board version which the firmware fails to start, some of them work normally, and some of them fail to start, and we are speaking about the same version of the board! then when I comment the SYSCLK_FREQ_72MHz, forscing it to use the HSI, everything works fine. 

Posted on January 15, 2015 at 00:58

May be you're just been lucky? The speed the flash can operate at depends on IC fabrication process variations, operational voltage and temperature, typically you'd need to add one wait state for each 24 MHz of speed increase. Other parts of the design might have critical paths, also limiting speed.

If clocks don't start it's indicative of component issues, the oscillator has expectations about circuit characteristics, the crystal's load capacitance, cut, series/parallel resistance, and decoupling capacitors, etc. ST has an application note, and BOM examples, to design a circuit that will operate correctly over temperature, voltage, etc.

The part will always start with the HSI. If the HSE doesn't start or the PLL doesn't lock you'd need to review the error handling of that code, this is YOUR job as a developer, ST's code is a rough outline and will often enter infinite loops in error conditions. You might want to do other things.

It also sets the PLL and Flash wait states based on expectations of what frequency is being supplied. If YOU change that, YOU need to adapt your code to address those changes, and validate it to your own satisfaction. If the timing is wrong the chip might crash, or malfunction, or you could just end up in the Hard Fault Handler. If you haven't replaced the while(1) in the Hard Fault Handler with some useful diagnostic code you might want to consider that too.

So it's really YOUR responsibility to correctly select parts, adapt the code behaviour, and validate your design.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
uxdiesel99
Associate II
Posted on January 15, 2015 at 14:18

Wow, thanks for the perfect explanation, I was reviewing the firmware and the crystal is set in the compiler settings as 16Mhz, so it looks that it is set correctly. So, just to confirm, since I commented the #define SYSCLK_FREQ_72MHz, it will always use the internal rc right? because I believe there is some issue with the crystal.

Posted on January 15, 2015 at 16:59

I'd have to review the code, but if you did nothing the part will continue to run on the HSI source, and the PLL/HSE don't get enabled.

I would generally suggest stripping the file down and removing all the stuff that's not relevant to your implementation so you can clearly see what's being compiled in. Then review the code, it's error paths and behaviour, and add some more elegant fail-over or recovery code. Tailor the code to your component choices, and perhaps code a more adaptive PLL configuration where it uses HSE_VALUE, and computes the settings on the fly. The ST code has fixed values so it's fast and more concise, I seem to recall release prior to V3 were a little more verbose, and I know I've coded some better methods as part of a dynamic clock gearing strategy. The code might be a bit bigger and slower, but in the scale of things it's probably quite meaningless compared to say spinning waiting for the HSE or PLL to actual start/lock/stabilize.

For things on F2/F4 designs some peripherals are reliant on the PLL running even if the processor is not using them (ie SDIO). I'm a little too far away from the F1 to remember all the nuances, but for example if the HSE fails it's possible to use the HSI/PLL to get the part running at 64 MHz. The HSI is not good for USB or CAN applications.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..