I'm trying the light an LED (on port c, pin 13) on STM32F103C8T6. I'm not using IDE. Code:
#include "include/stm32f10x.h"
int main()
{
RCC->APB2ENR |= RCC_APB2ENR_IOPCEN;
GPIOC->CRH &= ~GPIO_CRH_CNF13;
GPIOC->CRH |= GPIO_CRH_MODE13_0;
GPIOC->BSRR = GPIO_BSRR_BR13;
while(1)
{
GPIOC->BSRR = GPIO_BSRR_BS13;
}
return 0;
}
Links to include files in include directory:
system_stm32f10x.h
core_cmInstr.h
core_cmFunc.h
core_cm3.h
stm32f10x.h part1
stm32f10x.h part2
That's how I compile it
arm-none-eabi-gcc --specs=nosys.specs -o output led.c
After uploading it to mc nothing happens.
to light the led on a blue pill you need PC13 low (reset) so write with reset bit 13 set in the gpioc bsrr register, then end the program, making the gpio line go high turns off the led.
#include "include/stm32f10x.h"
int main()
{
RCC->APB2ENR |= RCC_APB2ENR_IOPCEN;
GPIOC->CRH &= ~GPIO_CRH_CNF13;
GPIOC->CRH |= GPIO_CRH_MODE13_0;
GPIOC->BSRR = GPIO_BSRR_BR13;
while(1)
{
continue;
}
return 0;
}
Just look at the schematic.
Understand this is not a universal truth that low is on. You have to look at the design of the board. Also not all stm32f103c8t6 chips have an led on that pin, but I assume this is an stm32 "blue pill" board.
EDIT
a complete working blinker example for that board
flash.ld
MEMORY
{
rom : ORIGIN = 0x08000000, LENGTH = 0x1000
ram : ORIGIN = 0x20000000, LENGTH = 0x1000
}
SECTIONS
{
.text : { *(.text*) } > rom
.rodata : { *(.rodata*) } > rom
.bss : { *(.bss*) } > ram
}
flash.s
.cpu cortex-m0
.thumb
.thumb_func
.global _start
_start:
stacktop: .word 0x20001000
.word reset
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.thumb_func
reset:
bl notmain
b hang
.thumb_func
hang: b .
.align
.thumb_func
.globl PUT16
PUT16:
strh r1,[r0]
bx lr
.thumb_func
.globl PUT32
PUT32:
str r1,[r0]
bx lr
.thumb_func
.globl GET32
GET32:
ldr r0,[r0]
bx lr
.thumb_func
.globl dummy
dummy:
bx lr
.end
blinker01.c
void PUT32 ( unsigned int, unsigned int );
unsigned int GET32 ( unsigned int );
void dummy ( unsigned int );
#define GPIOCBASE 0x40011000
#define RCCBASE 0x40021000
int notmain ( void )
{
unsigned int ra;
unsigned int rx;
ra=GET32(RCCBASE+0x18);
ra|=1<<4; //enable port c
PUT32(RCCBASE+0x18,ra);
//config
ra=GET32(GPIOCBASE+0x04);
ra&=~(3<<20); //PC13
ra|=1<<20; //PC13
ra&=~(3<<22); //PC13
ra|=0<<22; //PC13
PUT32(GPIOCBASE+0x04,ra);
for(rx=0;;rx++)
{
PUT32(GPIOCBASE+0x10,1<<(13+0));
for(ra=0;ra<200000;ra++) dummy(ra);
PUT32(GPIOCBASE+0x10,1<<(13+16));
for(ra=0;ra<200000;ra++) dummy(ra);
}
return(0);
}
build
arm-none-eabi-as --warn --fatal-warnings -mcpu=cortex-m3 flash.s -o flash.o
arm-none-eabi-gcc -Wall -Werror -O2 -nostdlib -nostartfiles -ffreestanding -mthumb -mcpu=cortex-m0 -march=armv6-m -c blinker01.c -o blinker01.thumb.o
arm-none-eabi-ld -o blinker01.thumb.elf -T flash.ld flash.o blinker01.thumb.o
arm-none-eabi-objdump -D blinker01.thumb.elf > blinker01.thumb.list
arm-none-eabi-objcopy blinker01.thumb.elf blinker01.thumb.bin -O binary
arm-none-eabi-gcc -Wall -Werror -O2 -nostdlib -nostartfiles -ffreestanding -mthumb -mcpu=cortex-m3 -march=armv7-m -c blinker01.c -o blinker01.thumb2.o
arm-none-eabi-ld -o blinker01.thumb2.elf -T flash.ld flash.o blinker01.thumb2.o
arm-none-eabi-objdump -D blinker01.thumb2.elf > blinker01.thumb2.list
arm-none-eabi-objcopy blinker01.thumb2.elf blinker01.thumb2.bin -O binary
builds both with and without thumb2 extensions (flash.s doesnt have to be thumb only, just leftovers from prior examples).
now what file and how are you uploading it to the mcu? loading an elf does you no good there isnt an operating system but depending on the tool you are using it may read elf and download the loadable portions. I wrote my own tool since it is so simple to interface with the bootloader uart interface. I have also used openocd with various swd/jtag interfaces (stlink, j-link), to write these. They come from asia locked so the first time you have to unlock them, know you can do it from the uart interface, pretty sure I figured it out from openocd as well...
So either your binary build is bad/wont boot right, or the download is the issue (or both).
the flash in the stm32 maps at 0x08000000, they re-map it to 0x00000000 if/when booting from the application. Should be able to use 0x00000000 as well, but most I have seen use 0x08000000. As documented the first word is loaded into the stack pointer on reset, the second word is the thumb address to the reset vector (lsbit is set to indicate thumb so 0x41 below means the reset vector is at address 0x40 as shown)
08000000 <_start>:
8000000: 20001000 andcs r1, r0, r0
8000004: 08000041 stmdaeq r0, {r0, r6}
8000008: 08000047 stmdaeq r0, {r0, r1, r2, r6}
800000c: 08000047 stmdaeq r0, {r0, r1, r2, r6}
8000010: 08000047 stmdaeq r0, {r0, r1, r2, r6}
8000014: 08000047 stmdaeq r0, {r0, r1, r2, r6}
8000018: 08000047 stmdaeq r0, {r0, r1, r2, r6}
800001c: 08000047 stmdaeq r0, {r0, r1, r2, r6}
8000020: 08000047 stmdaeq r0, {r0, r1, r2, r6}
8000024: 08000047 stmdaeq r0, {r0, r1, r2, r6}
8000028: 08000047 stmdaeq r0, {r0, r1, r2, r6}
800002c: 08000047 stmdaeq r0, {r0, r1, r2, r6}
8000030: 08000047 stmdaeq r0, {r0, r1, r2, r6}
8000034: 08000047 stmdaeq r0, {r0, r1, r2, r6}
8000038: 08000047 stmdaeq r0, {r0, r1, r2, r6}
800003c: 08000047 stmdaeq r0, {r0, r1, r2, r6}
08000040 <reset>:
8000040: f000 f80a bl 8000058 <notmain>
8000044: e7ff b.n 8000046 <hang>
08000046 <hang>:
8000046: e7fe b.n 8000046 <hang>
You have to resolve this for starters, then once you have something with a chance of booting, then you can look at the code.
