What is the role of .s files in a C project?

The .s files usually contain the Vector tables. It defines what should the system do when an interrupt occurs. This table (code) is placed in a memory address defined by you in linker file. For example, every time a reset occurs what or rather where should your processor begin from , what code should it run. similarly, there are other handlers ( interrupt vectors). In STM32 , usually the controller loops on particular handlers. As given in the below example:See this link for detailed explanation

    .section INTERRUPT_VECTOR, "x"
    .global _Reset
    _Reset:
      B Reset_Handler /* Reset */
      B . /* Undefined */
      B . /* SWI */
      B . /* Prefetch Abort */
      B . /* Data Abort */
      B . /* reserved */
      B . /* IRQ */
      B . /* FIQ */

    Reset_Handler:
      LDR sp, =stack_top
      BL c_entry
      B .

This assembly code later is converted to object files and linked with your .c files and .ld to create a .elf or .bin files.

They usually contain assembly code. The assembler turns them into object files which are later linked by the linker with the main stuff. But I imagine it does depend on the compiler, toolchain etc.

The .s extension is the convention used by GNU and many other tool-chains for assembler files.

Last I looked the STM32 Standard Peripheral Library itself contains no assembler files, however the CMSIS library contains start-up code for various STM32 parts, for example startup_stm32f2xx.s is start-up code for all STM32F2xx series devices. There are different implementations for different tool-chains; you need to build and link the file associated with your specific part and tool-chain. If you are using an example project that builds and runs or an IDE that creates part-specific projects for you, this will probably already have been done - if you have code that runs it certainly has.

How you build and link the code will depend on what tool-chain you are using. Most IDE based tools will automatically recognise the extension and invoke the assembler to generate an object file that will be linked like any other. The exact content differs slightly between tool-chain versions, but primarily creates the C runtime environment (stack and heap), initialises the processor, defines an initial interrupt/exception vector table, initialises static data and jumps to main().

The core of the file for the Keil/ARM RealView version for example looks like this:

; Reset handler
Reset_Handler    PROC
                 EXPORT  Reset_Handler             [WEAK]
        IMPORT  SystemInit
        IMPORT  __main
                 LDR     R0, =SystemInit
                 BLX     R0
                 LDR     R0, =__main
                 BX      R0
                 ENDP

Reset_Handler is the address Program Counter (PC) register will be set to after a processor reset.

SystemInit is an external C code function that does the bulk of the initialisation - this may need customisation for your hardware. Cortex-M is unusual in that it can start running C code immediately after reset because the vector table includes both the reset address and the initial stack pointer address, which is automatically loaded to the SP register on reset. As a result you do not need much assembler knowledge to get one running.

__main() is the compiler supplied entry point for your C code. It is not the main() function you write, but performs initialisation for the standard library, static data, the heap before calling your `main()' function.

The GCC version is somewhat more involved since it does much of the work done by __main() in the Keil/ARM RealView version, but essentially it performs the same function.

Note that in the CMSIS SystemInit() is defined in system_stm32f2xx.c, and may need customisation for your board (correct crystal frequency, PLL setup, external SRAM configuration etc.). Because this is C code, and well commented, you will probably be more comfortable with it.