2015-01-14 12:04 PM
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&sharpendifWhy is this happening?? #stm32f1032015-01-14 01:11 PM
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.2015-01-14 02:05 PM
2015-01-14 03:58 PM
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.2015-01-15 05:18 AM
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.
2015-01-15 07:59 AM
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.