while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
}
I Installed STMCubeMX and built a project for STM32IDE
In the IDE I successfully built the project using: project -> build all
I'm expecting to see the default led to stop blinking given my while loop is completely blank, but it's still blinking like crazy.
Try this, quite minimal, will test your tools and ability to copy the file to the board. I assume this is a NUCLEO board.
.cpu cortex-m0
.thumb
.thumb_func
.global _start
_start:
stacktop: .word 0x20000100
.word reset
.word reset
.word reset
.word reset
.thumb_func
reset:
b .
build
arm-none-eabi-as flash.s -o flash.o
arm-none-eabi-ld -Ttext=0x08000000 flash.o -o flash.elf
arm-none-eabi-objdump -D flash.elf > flash.list
arm-none-eabi-objcopy -O binary flash.elf flash.bin
check build
cat flash.list
Disassembly of section .text:
08000000 <_start>:
8000000: 20000100
8000004: 08000015
8000008: 08000015
800000c: 08000015
8000010: 08000015
08000014 <reset>:
8000014: e7fe b.n 8000014 <reset>
Looks good exactly what we want.
Now copy command line or drag and drop flash.bin to the virtual drive that is mounted when you plug in the NUCLEO board. It will load this into the target mcu on the board. The STM32F446, and should reset it and you will end up in this loop, no blinking user led.
As you make more complicated projects you simply expand on this a bootstrap, a program, linked (,checked), and copied to the virtual flash drive.
I normally do a firmware upgrade of the debug end (stlink plus thumb drive thing) when I get a new NUCLEO board. ST provides a Java-based tool that itself does not update that often, but it checks the board vs I guess a database at their site and can upgrade your flash. Depending on your host OS I have had NUCLEOs that you can only copy to a few times or one time and you have to unplug and replug, newer firmware versions for those and more recent boards that problem has pretty much gone away. It would say no room left on the device, unplug/replug and it would be fine.
Also providing stlink capabilities you can use openocd or other tools to stop and examine the device, with openocd for example when you telnet in to the openocd server you can use mdw 0x08000000 20 and examine the start of the user flash to see if it matches the binary you think you have loaded on the device. Depending on the part you can also write/erase that flash via openocd, but do not assume that support is always there for all ST or other branded parts. Write to ram and run from there (different startup not a vector table) sure, but flashing requires someone to add that support for each part or family into openocd.
As pointed out in the comments either you are not building what you think or you are not actually loading the program into the flash. Examine the binary examine the flash to see what actually happened if anything. The above should avoid all the barriers to success, CMSIS, IDE tools, STMCubeMX, etc. Once you are able to succeed then work your way to the middle from both ends (between this trivial example and your project) and find where the real problem is/was. You should be able to for example use the IDE and all that stuff to build the binary, use the gnu tools to examine that binary, hexdump/whatever to examine the .bin file, and then drag and drop outside the IDE to program.