# Rowley Crossworks STM32 Start from Reset

I am using an STM32F4 with the Rowley CrossStudio for ARM. It is not clear to me how to have the MCU start from int main() on reset (i.e. power up the device). I thought building it in release mode would have done this, but that seems not to be the case.

Looking online, I see some people saying that you somehow change the startup vector but this may prevent future debugging?

Is there a good way to accomplish this so that I can debug if I need to and run my program without the debugger on startup?

Thank you!

• What is the state of the BOOT0 pin? This controls the startup mode of most members of the STM32 family. – Chris Stratton Mar 2 '18 at 19:49
• Aha! By grounding the BOOT0 pin I was able to make this work. This is a good hardware solution, but shouldn't I still be able to programmatically make this work? – Biff Mar 4 '18 at 0:32
• No, you have to use the pin, or else have something else command it to jump to flash. – Chris Stratton Mar 4 '18 at 1:14

On most (but perhaps not all) members of the STM32 family, to automatically boot an application from flash you must ground the BOOT0 pin.

This is essentially so that if you have a bad application in flash, or one that does not provide a means of entering the bootloader, you can force entry to the bootloader by cycling reset with BOOT0 high (with appropriate setting of boot1 or other mode controls to select the bootloader rather than RAM).

If you define the macro STARTUP_FROM_RESET it should jump to the proper reset vector on startup.

The JTAG interface should still be able to gain control if you've built for debug.

• So I tried #define STARTUP_FROM RESET 1 in my main.c file but it didn't seem to work? – Biff Mar 2 '18 at 18:59
• Try in Startup.s – Spehro Pefhany Mar 2 '18 at 19:03
• You could add this as a project setting. "Build Options"->"Project Macros" if I remember correctly – brhans Mar 2 '18 at 22:24
• Defining it in Startup.s does not work, and adding STARTUP_FROM_RESET in global macros does not work either. – Biff Mar 4 '18 at 0:11

If you've tried everything else and STARTUP_FROM_RESET still doesn't appear to work, chances are good you have a debug_printf("something") somewhere which is waiting on the JTAG/SW connection. Once I remove all my debug_printf's it worked as expected.