2016-04-15 02:18 PM
2016-04-15 07:05 PM
The expectation is that the system_stm32fxxx.c file is placed in your project directory, and tailored to specific chip/board designs. The ST file is definitely just a roughed-in starting point.
Around here we have some better fail-over code for the HSE and PLL, so the HSI will bring up the PLL, as without the PLL the SDIO, USB and CRYPT won't function at all. And a more generalized SystemCoreClock initial computation using the defines, so there are less source changes. On one specific build, that can run on all sorts of F4s (F407, F401, F411, F446, F429), I have it detecting the chip and selecting the CPU and PLL settings to run anywhere between 84 MHz and 180 MHz automatically.2016-04-18 05:12 AM
Hi price.Kyle,
You are using an old/wrong ''system_stm32f4xx.c'' file of Standard peripheral library (SPL). Try to use the recent version/release of the library that you can find . You find ''system_stm32f4xx.c'' file under this path: STM32F4xx_DSP_StdPeriph_Lib_V1.6.1\Libraries\CMSIS\Device\ST\STM32F4xx\Source\Templates I have attached the file for you. -Hannibal- ________________ Attachments : system_stm32f4xx.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0eS&d=%2Fa%2F0X0000000bbz%2FugMw2mZYzhCBmdiu8SOhq5H.BOdElBPUgCfe2xsbHfI&asPdf=false2016-04-18 08:10 AM
That definitely makes sense. I have been changing the init value, then letting it try to stabilize an HSE, if that fails, feed the HSI into the PLL to bump the frequency up to enable some of the higher speed peripherals and last making a call to the SystemCoreClockUpdate() either way to update the global - as I use it in some of the SysTick code elsewhere.
Thank you for the information, it sounds like you have a much better way to generalize this.2016-04-18 08:24 AM
Thank you Hannibal, I will take a look at the newer files and adopt them into this project!