BluePill: Program is uploaded but MCU doesn't run correctly

[trung1]

Hi, I'm getting started at embedded programming, I've got this blue pill board having the STM32F103C6 MCU and ST-LINK v2 programmer.

Here's my code, just to light up the LED on port C 13:

#include "stm32f10x.h"

int main() {

RCC->APB2ENR |= (1<<4);

GPIOC->CRH |= ((1<<20) | (1<<21));

GPIOC->CRH &= ~((1<<22) | (1<<21));

GPIOC->BSRR = (1<<13);

return 0;

}

Despite the IDE flashes successfully the LED doesn't light up as I wanted, It will only lights up if I add a break point on debugging mode on Keil uVision

And here are my flash configurations:

Any help is appreciated.

[Tesla DeLorean]

Try using HAL code, check the HW works with that. I don't have a strong desire to validate others bare-metal coding.

Watch also for the clock hazard related to enabling the GPIO's APB clock and then immediately writing it's registers.

In Keil you should be able to do a Peripheral View of the GPIOC bank, and manually modify the registers, and toggle the PC13 pin.

Check the schematic, the other end of the LED connects to VCC, you need to ground the pin via OD or PP mode operation to provide a current path to light then LED.

PC13 HIGH will not illuminate the LED. And also has low current sourcing ability in any case.

[Shirley.Ye]

what is the CRH register? seems not consistent with the Reference manual.

and are you sure you are setting the GPIO output mode?

and also need to replace the return 0 with while(1).

[Shirley.Ye]

seems the GPIOC->CRH &= ~((1<<22) | (1<<21)); should be

GPIOC->CRH &= ~((1<<22) | (1<<23));

[trung1]

I did make such a mistake. After fixing bit register 21 -> 23, the LED turns on at 

GPIOC->CRH &= ~((1<<22) | (1<<23));

and turns off at

GPIOC->BSRR = (1<<13);

which is weird because it turns on while setting the register and turns off when setting the set-bit = 1.

[Pavel A. · Accepted solution]

> which is weird because it turns on while setting the register and turns off when setting the set-bit = 1.

What I expected. Some LEDs are "active low". TL;DR this is not unusual, just depends on how the LED is connected.

[trung1]

Thank you a lot, I didn't think of that case but thinking my board was broken.