Startup code customization options feature request

[Mikk Leini]

On STM32Hxx and STM32N6 families I have faced a situation where I need to modify startup assembly code  (startup_stm32xxx.s) to copy code (.text) into ITCM or clear RAM/TCM areas, for clean data or to prevent ECC error (on STM32N6). But next time CubeMX generates code, those changes are overwritten. Same story with SystemInit function in system_stm32xxx.c. So either manual restoration or script must be done. But it's getting quite annoying after several projects. I believe the purpose of CubeMX is to ease development, so I make a feature request:

Please add user code begin/end comment sections that exist in main.c also into startup_stm32xxx.s assembly and system_stm32xxx.c source files.

For startup assembly I wish the user sections are:

1. User symbols definitions.
2. User data copy.
3. User zero fill.

For system file I wish the user sections are quite similar to main.c:

1. User includes.
2. User defines/constants/variables.
3. In SystemInit() function:
   1. In the beginning.
   2. After VTOR setting
   3. At the end.
4. User functions in the end of the file.

[Pavel A.]

At least for STM32H7 the startup .s and system_stm32.c files should be created by CubeMX only once and not touched by re-generation at all. This is why these files do not have "user sections". Users can freely customize these files.

If you see different behavior, maybe this is because of unusual settings in the Project manager-> Code generation.

[Mikk Leini]

Hmm, I didn't know that CubeMX does not (or shall I say - is not supposed to) re-generate them and you made me re-think what problem did we have in the past projects and how it was solved. Unfortunately I don't remember exactly anymore and I can't verify either. Those projects used older CubeMX'es also. But now I made a clean test with latest CubeMX 6.17.0 using two toolchains: STM32CubeIDE and CMake + GCC. No other changes done to the projects except toolchain selection. Fresh HAL used for each MCU family. 

1. Nucleo-H753ZI board new empty project. Generated for STM32CubeIDE toolchain, inserted lines into both files, regenerated. Startup assembly and system init C file changes are not overwritten. Tried generating for CMake + GCC. Startup assembly placed into root folder now instead, but neither startup or system init C file is overwritten by re-generation. Closed, re-opened CubeMX and re-generated - still not overwritten. So you're right @Pavel A. 

2. Nucleo-H563ZI board new empty project. Re-generated STM32CubeIDE toolchain. Secure and NonSecure applications startup assembly and system init C file are not overwritten. Re-generated CMake + GCC toolchain. Assembly file names changed. Secure and NonSecure application startup assembly code is overwritten, system init C is not overwritten.

3. Nucleo-H7SL8 board new empty project. Enabled Boot and Application. Re-generated STM32CubeIDE toolchain. Boot and Appli startup assembly and system init C file are not overwritten. Configured for CMake + GCC toolchain and re-generated. Startup assembly files are overwritten, system init C files are not.

4. Nucleo-N657X0-Q board new project. Enabled Secure and NonSecure domains. Generate FSBL, AppS, AppNS. Re-generated STM32CubeIDE toolchain. Modified 3x2 files. No changes overwritten by re-generation. Configured for CMake + GCC. Startup assembly files are overwritten, system init C files are not. 

 

As it seems the problem appears with CMake+GCC toolchain and assembly files. What I observed is that STM32CubeIDE and CMake+GCC toolchains generate slightly different startup assembly file names in cases 2, 3 and 4. E.g.

• startup_stm32h563xx.s vs startup_stm32h563zitx.s
• startup_stm32h7s3l8hx.s vs startup_stm32h7s3xx.s
• startup_stm32n657x0hxq_fsbl.s vs startup_stm32n657xx_fsbl.s

Maybe this fact and overwriting behavior are related?

I didn't try other toolchains. This test has taken quite a lot of time already.

But I couldn't make CubeMX overwrite system init C file in any way. Yet on our N6 project, the post-gen script restores system init file. I tried with CubeMX v6.16.1 and that didn't overwrite system init C file either. Looks like it was a precaution.

The scenario I didn't test is what happens when HAL upgrade is made. If new HAL has changes in start-up or system init then they should somehow be updated also, I guess?

About the generation settings - I don't see any settings on any of the four families which would allow to alter the startup assembly or system init C file generation behavior. "Keep user code when re-generating" checkbox is checked by default.

 

In conclusion - if CubeMX would never overwrite startup assembly and system in C file, then this feature request can be dropped. If it does overwrite in certain toolchains, like it is doing right now with CMake, then it's a bug report.

[Ghofrane GSOURI]

Hello @Mikk Leini 

Your change request has been raised to dev team under internal ticket ID  228148 for further investigation and feasibility check.

I will keep you posted with updates.

THX

Ghofrane

[Pavel A.]

Yes, generation of some files for CMake goes differently from traditional IDEs  (with intent of improvement, of course).

>  If new HAL has changes in start-up or system init then they should somehow be updated also, I guess?

The startup files are not part of the HAL. Rather they belong to the CMSIS code base and are associated with toolchains (GCC, clang, Keil, IAR and so on) - not with HAL or other library of that sort. The system_stm32xxx.c also implements functions defined by the CMSIS spec and is written in toolchain-independent C.

But yes, these CMSIS files sometimes are updated in upstream and then *can* be updated in the projects manually - if the changes are really necessary.  If the updates enable new ST MCUs that don't exist when your project has been generated - they are not required. Sometimes changes come from ARM and affect the CMSIS #include files. *Usually* such changes are backward compatible, no need to worry.

[Mikk Leini]

---

 (with intent of improvement, of course).

---

The road to hell is paved with good intentions :)

 

---

The startup files are not part of the HAL.

---

Correct, I meant the "Cube" package. They seem to come from

C:\Users\[User]\STM32Cube\Repository\STM32Cube_FW_[Family]_[Version]\Drivers\CMSIS\Device\ST\STM32[Family]xx\Source\Templates

 

[Mikk Leini]

Hi @Ghofrane GSOURI - did you notice my post about test results? My feature request could also be a bug report. I think it would be easier to fix generator.