4

I have worked with STM, NXP and Atmel MCUs, but all the time during board bring up, we use the vendor provided startup script to bring up the hardware. I know we do that because we do not want to be rewriting the linker script and startup sequence from scratch, which is hardly productive. But from a learner's perspective if given an MCU how do we know in which sequence it needs to be booted? I was thinking maybe there should be some place where the sequence is documented but we rarely look at it.

Is there some place the vendor will document the startup sequence (steps to execute in ResetHandler() function) for a specific chip or a family of chips? I tried looking at the programmer's model in Cortex-M4 and ARMv7 technical reference manuals. But I was not able to find it. The chip I am currently using to learn in STM32G431RBT6

anirudhan
  • 43
  • 3
  • 1
    I wrote some general advise for how to implement your own professional CRT here: https://stackoverflow.com/a/47940277/584518. Vendors may use linker/tool chain specific stuff of course, as well as ISA-specific inline asm. – Lundin May 23 '22 at 10:33
  • 2
    Btw do note that some of the CRTs for Cortex M specifically were written by complete amateurs. For example setting the clock source to the internal slow RC one, then running the whole bloody `.data`/`.bss` copy-down using that slow clock, before finally telling the user to go set the clock perference themselves in main(), when the damage is already done. Or "now that I've already been chewing data for an eternity, would you like to enable the watchdog from main()?" Such incompetent people shouldn't be writing drivers for silicon vendors, but alas they are. Multiple big vendors have quack CRT. – Lundin May 23 '22 at 10:41
  • By explicitly asking "_Is there some place the vendor will document..._" you have rendered your question off-topic. Better to ask about run-time start-up in general and the answer can be posted here. – Clifford May 23 '22 at 11:16
  • 2
    What @Lundin said, ... and not always _literally_ "amateurs" - the vendor supplied code often looks that way (ST I am talking about you!). Even in ST's pre-STM32Cube their supplied example start-up for external SRAM failed to start the "compensation cell" a feature that is required to run a bus over about 50MHz and without which code will fail infrequently and randomly (the worst kind of bug). Incidentally the compensation cell gets not more than one line of documentation in the entire reference manual - it is largely a mystery what it does, but you need it! Good luck! – Clifford May 23 '22 at 11:52
  • 1
    I struggle to find any good vendor supplied firmware, the SDKs and libraries from the major players appear to be written by the B or C team at best. Very scary and disturbing. It is not only not hardly productive, if you blindly accept their code you are adding a fair amount of risk to your product. Maybe accept it and use it but if you are not ready to dive in and fix it or remove the risk. They have legal disclaimers to protect themselves, you need to protect yourself. – old_timer May 23 '22 at 13:57
  • @Lundin....lol, good point. If it is even employees and not the cheapest contractor. – old_timer May 24 '22 at 13:06

1 Answers1

2

Chip vendors don't typically dictate such things; it is application specific - i.e. up to you how you use the chip. Often it is "documented" by example/reference code rather then explicitly described.

That said there are some general principles:

There will be hardware initialisation which will be part specific, and for that the MCU reference manual and/or data sheet would be your source. For example for your STM32 the PLL will normally be configured if you want to run the MCU at more than the default internal RC oscillator's 16MHz, and before that you would typically need to configure memory timing and wait-states. If you are using external memory, you might also configure the bus and memory controller at that point - necessary if the external memory is in the link map so that code and data may be located there by your toolchain's linker.

Following hardware initialisation, the software run-time environment must be established. A C runtime will typically establish a stack, initialise static data, and initialise the library (for heap etc.). A C++ run-time will additionally call constructors for objects in global scope. Often this will be compiler/toolchain supplied code that is invoked before main() - for example you will typically see start-up code calling perhaps __main (ARMCC) or _start (GCC) - neither are a direct call to main() but rather the C/C++ runtime initialisation (which ultimately calls main() where you might do more application specific initialisation and/or start an RTOS kernel for example.

For ARM Cortex-M for which there is a framework called CMSIS, the hardware initialisation is placed in a user supplied function SystemInit(). If you have a vendor supplied SystemInit() you are expected there to modify it to suit your application. Or you can implement your own from scratch. SystemInit() will be invoked from Reset_Handler (usually implemented as assembler) which is the reset vector handler.

See for example: https://developer.arm.com/documentation/ka001193 which describes the typical start-up of a Cortex-M7 device following CMSIS conventions.

Clifford
  • 88,407
  • 13
  • 85
  • 165