- This topic has 1 reply, 2 voices, and was last updated 8 years, 7 months ago by
.
-
Posts
-
I have a question regarding the .s startup files. Up until now when using the standard peripheral library examples there are the .s start-up files included in the projects. I see that there are no .s files with the VisualGDB projects. Does the startup .c file that is generated with VisualGDB perform the same functionality as the .s files. Why are these c files created instead of using the .s that has been standard up until now?
It looks like the .s file initializes memory, sets up the NVIC and calls the SystemInit() c function (not necessarily in that order) is this correct? For the memory initialization it copies the data initialization from flash to RAM and zeros out the rest of it?
For configuring the clocks with the VisualGDB blink project:
– There is default code for setting up the clocks and configuring the registers. Browsing the code there are #ifdef’s to change the options. By default the HSI is configured and used. How would you go about using the HSE? Is It in main.c that you add the #defines or should they be added as preprocessor directives? For more advanced clock configuration do you modify the startup.c code or is this a separate function.The startup execution flow looks like this to me:
– startup.c (or .s) sets up the memory as above
– system_stm32____.c SystemInit() is called from the startup file – this resets the clock configuration to default state and resets registers, disables interrupts etc.
– The above function calls SetSysClock() – This is where it gets confusing – the ST periph example shows the PLL (clocked by HSE) in the comments but there is no HSE crystal installed on my board, the HSI is used.Where should the clock setup be modified?
Your understanding of the startup sequence is correct. You can actually explore it visually it using Code Map if you are using the Clang IntelliSense:
First, the Reset_Handler from startup.c gets invoked. Startup.c files is actually generated from the .s files and should be 100% compatible with them (i.e. use same vector names). We use the .c files instead of the original .s ones to support advanced features like DEBUG_DEFAULT_INTERRUPT_HANDLERS and also to make things more uniform across different architectures.
The startup.c code does indeed copy the data section and erase the bss section. Then it calls device-specific initialization from the system_xxx.c file that is copied to your project folder and can be modified separately from other projects. If you just want to change HSI_VALUE/HSE_VALUE, you can edit the stm32fxxx_hal_conf.h for HAL projects or define HSE_VALUE via Preprocessor Macros in VisualGDB Project Properties for StdPeriph projects. For more complex changes, you would need to edit the system file. We would normally recommend switching to the STM32 HAL and then using the STM32CubeMX generator to generate the startup code automatically. If this is not an option, please replace your system file with a file from STM32 StdPeriph examples that matches your board configuration the best.
- You must be logged in to reply to this topic.