How to rename main function?

[CoolNamesAllTaken]

I'm working on a bootloader on an STM32. Both the bootloader and the main program are being written and debugged in the STM32CubeIDE. To avoid issues when debugging both applications simultaneously, I've had to edit the linker file (startup_stm32f446retx.s) to jump into boot_main instead of main when it calls the application entry point. This means that I also have to rename main to boot_main in main.c. However, every time I re-configure a peripheral using CubeMX, main.c is generated by CubeMX and it wipes out my name change to the main function. Is there a "proper" way to permanently change the name of the main function for a given program?

[TDK]

No, main is rightfully (IMO) hardcoded in CubeMX.

Compiling the main program separately from the bootloader is desirable a number of reasons. If you can just flash the program and bootloader all at once, it's not really a bootloader, just another part of the application.

[CoolNamesAllTaken]

Thanks for the response! The main program and bootloader are separate ST-Cube IDE projects, and are flashed on separately. The reason I changed one of the main functions to boot_main was so that I could debug the boot jump sequence where the bootloader hands off to the main program. The bootloader program and the main program both have a rather complex stack running an industrial communication protocol, so step-by-step debugging is useful for both programs (and seeing how they run together).

[TDK]

Ah, got it. That makes a bit more sense now. I still don't think there's a way other than manually renaming, however.

[Piranha]

Switch to a much simpler and better approach described here:

https://community.st.com/s/question/0D50X0000AFpTmUSQV/using-nvicsystemreset-in-bootloaderapplication-jumps

With this approach the jump sequence is so minimal, that it doesn't need any further debugging and it doesn't depend on what peripherals you use in the bootloader project.

[CoolNamesAllTaken]

Interesting approach! Thanks for sharing.

I have my current jump method in the bootloader working as intended, so I'm not planning to change it for now, but I will certainly look into this implementation of the jump in assembly for future applications.