STM32 code uploads successfully but doesn't run

Question

I'm new to STM32 and I followed the instructions here in order to program my first stm32f103c8t6 board in Ubuntu.

Here is the code which I added to the source code:

int main(void)
{
  /* USER CODE BEGIN 1 */

  /* USER CODE END 1 */

  /* MCU Configuration----------------------------------------------------------*/

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();

  /* USER CODE BEGIN Init */

  /* USER CODE END Init */

  /* Configure the system clock */
  SystemClock_Config();

  /* USER CODE BEGIN SysInit */

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  /* USER CODE BEGIN 2 */

  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {

  /* USER CODE END WHILE */

  /* USER CODE BEGIN 3 */
   HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_0);
   HAL_Delay(500);

  }
  /* USER CODE END 3 */

}

And of course, I have set PA0 port as GPIO_output in STM32CubeMX. Here is the output of function MX_GPIO_Init:

static void MX_GPIO_Init(void)
{

  GPIO_InitTypeDef GPIO_InitStruct;

  /* GPIO Ports Clock Enable */
  __HAL_RCC_GPIOA_CLK_ENABLE();

  /*Configure GPIO pin Output Level */
  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_0, GPIO_PIN_RESET);

  /*Configure GPIO pin : PA0 */
  GPIO_InitStruct.Pin = GPIO_PIN_0;
  GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
  HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

}

The code builds and uploads successfully to the board. Here is the output for rebuilding the code which builds and uploads the code:

-------------- Clean: Release in sample1 (compiler: GNU GCC Compiler for ARM)---------------

Executing clean command: make -f Makefile cleanRelease
rm -fR .dep build
Cleaned "sample1 - Release"

-------------- Build: Release in sample1 (compiler: GNU GCC Compiler for ARM)---------------

Checking if target is up-to-date: make -q -f Makefile Release
Running command: make -f Makefile Release
mkdir -p build      
C. Compiling build/system_stm32f1xx.o...
C. Compiling build/stm32f1xx_hal.o...
C. Compiling build/stm32f1xx_hal_cortex.o...
C. Compiling build/stm32f1xx_hal_dma.o...
C. Compiling build/stm32f1xx_hal_flash.o...
C. Compiling build/stm32f1xx_hal_flash_ex.o...
C. Compiling build/stm32f1xx_hal_gpio.o...
C. Compiling build/stm32f1xx_hal_gpio_ex.o...
C. Compiling build/stm32f1xx_hal_pwr.o...
C. Compiling build/stm32f1xx_hal_rcc.o...
C. Compiling build/stm32f1xx_hal_rcc_ex.o...
C. Compiling build/stm32f1xx_hal_tim.o...
C. Compiling build/stm32f1xx_hal_tim_ex.o...
C. Compiling build/main.o...
C. Compiling build/stm32f1xx_hal_msp.o...
C. Compiling build/stm32f1xx_it.o...
S. Compiling build/startup_stm32f103xb.o...
2018-06-21T10:32:46 INFO usb.c: -- exit_dfu_mode
C. Linking build/sample1.elf...
/usr/bin/arm-none-eabi-size build/sample1.elf
   text    data     bss     dec     hex filename
   3560      20    1572    5152    1420 build/sample1.elf
H. Linking build/sample1.hex...
B. Building build/sample1.bin...
Used gcc: 6.3.1
/usr/local/bin/st-flash erase
2018-06-21T10:32:46 INFO common.c: Loading device parameters....
2018-06-21T10:32:46 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2018-06-21T10:32:46 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2018-06-21T10:32:46 INFO common.c: Loading device parameters....
2018-06-21T10:32:46 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2018-06-21T10:32:46 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
st-flash 1.4.0-39-g6db0fc2
Mass erasing
/usr/local/bin/st-flash --reset write build/sample1.bin 0x8000000
2018-06-21T10:32:46 INFO common.c: Attempting to write 3580 (0xdfc) bytes to stm32 address: 134217728 (0x8000000)
st-flash 1.4.0-39-g6db0fc2
Flash page at addr: 0x08000000 erased
Flash page at addr: 0x08000400 erased
Flash page at addr: 0x08000800 erased
2018-06-21T10:32:46 INFO common.c: Finished erasing 4 pages of 1024 (0x400) bytes
2018-06-21T10:32:46 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2018-06-21T10:32:46 INFO flash_loader.c: Successfully loaded flash loader in sram
Flash page at addr: 0x08000c00 erased
  1/4 pages written
  2/4 pages written
2018-06-21T10:32:46 INFO common.c: Starting verification of write complete
2018-06-21T10:32:46 INFO common.c: Flash written and verified! jolly good!
  3/4 pages written
  4/4 pages written
Process terminated with status 0 (0 minute(s), 1 second(s))
0 error(s), 0 warning(s) (0 minute(s), 1 second(s))

However, the LED does not start to blink as expected. LED works fine when I connect it to 5volt. I have checked the board's pins by AVO meter and they are all connected to the micro-controller.

After a few research, I thought that it has to do something with Boot0 and Boot1 pins so I tried different options from here but none of them worked.

Here is the image of my board:

How can I fix it?

Are you sure that you configured Cube for the correct mcu/board? And that the PA0 corresponds to the pin of the LED? Maybe you can also have a look in the function MX_GPIO_Init to make sure that the code generated is the one expected. Can you put a link to the board you have? — Stoogy, Jun 21 '18 at 08:34
yes, I'm using the STM32F103C8Tx library. I add `MX_GPIO_Init` content to the question. here is the link to my board: http://wiki.stm32duino.com/index.php?title=Black_Pill — Yashar, Jun 21 '18 at 09:57
Is the current outputted by the GPIO high enough ? I see you are using the NOPULL mode. Maybe try GPIO_PULLUP ? If you have a logic analyser or a voltmeter try to put the GPIO high and Low for a long time to check if it is actually changing — Stoogy, Jun 21 '18 at 10:33
@Stoogy I tried `GPIO_InitStruct.Pull = GPIO_PULLUP;` I have set the delay for 2 seconds but it seems that the PA0's voltage is not changing. Does it have to do anything with B0-, B0+ , B1-, B1+ pins? — Yashar, Jun 21 '18 at 10:46
The Pull Ups/Downs doesn't matter if you switch a port to push/pull. The PP drivers are much stronger than the weak pull up or down resistors — theSealion, Jun 21 '18 at 11:06
On your image, it seems that the Boot pins are set to B1+ and B0+. I think you should boot from main memory. So B0 should be B0- — Stoogy, Jun 21 '18 at 12:00
@Stoogy I tried with B0- but still, it doesn't work. Can you please take a look at theSealion's answer and my comment on it? I have this problem with D2 LED either. — Yashar, Jun 21 '18 at 12:32
Just a couple of thoughts - is there a current limiting resistor on the LED ? (doesn't look to be from that image) And will it work at 3.3V, what is it's forward voltage ? — sergeantKK, Jun 28 '18 at 13:06
you are using an stlink yes, you can use openocd or other tool and stop and examine what is going on, you can manually configure the gpio port (about three register writes) and then use a couple more register writes to turn the led on/off once that works you can then write a program to do it. the libraries you are using have a massive overhead, perhaps you are trapped in something there. the blue pill and from what i am reading (will need to buy some of these black pills) support dfu-util so you dont need the stlink to load firmware... — old_timer, Jan 07 '19 at 16:20
with the stlink and a tool like openocd you can stop the processor and examine the program counter to see what memory space it is in and confirm you have your boot pins correct. Likewise you can use dfu-util -l to list (sometimes it takes a few power cycles on these boards) to see that you are in that mode then I think you need to move both boot jumpers from that mode to user application type mode. — old_timer, Jan 07 '19 at 16:23
sorry didnt see this was an old question, did it get resolved? — old_timer, Jan 07 '19 at 16:26

score 2 · Answer 1 · answered Jun 22 '18 at 11:06

I believe the HAL_Delay function is using systick to count time in ms, systick must be set to 1ms to get the right delay, did you configure that ? I am not sure how you do this.

If the time between the output toggles is very low, the output will not toggle because you set GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;, try GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH; then you can use an oscilloscope to check if it toggles.

If you do not have an oscilloscope at hand, you could try to insert a "while loop" counting towards a high number, instead of the HAL_Delay function.

Counter=0;            
while (Counter<500000000)
  {
  Counter++;
  }

Assuming your clock frequency is set at 72MHz, this will give a time in the range of 0.5 to 1 sec. Remember to declare the variable as integer 32 bit or higher, e.g. uint32_t counter = 0; If it does not work, set a breakpoint at the HAL_GPIO_Togglepin line, it will then pause at the breakpoint line and every time you click "RUN", it should then run to the breakpoint again and the output should toggle.

Actually, I would try to SET / RESET the output pin first, just to verify that it works. Try: HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, GPIO_PIN_RESET); And HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, GPIO_PIN_SET); One will turn on the LED and the other will switch it off, depending on how the LED is connected. — Peter1, Jun 22 '18 at 11:11

score 1 · Answer 2 · answered Jan 07 '19 at 05:48

I was dealing with the same problem for a week. a simple program for blinking the LED diode in the arduino environment with stm32f103c8t6 was working, the combination of stm32f103c8t6, stm32CubeMX, ubuntu's gcc-arm (gcc-arm-none-eabi version:15:6.3.1+svn253039-1build1) and ubuntu 18.04 does not. After I installed GNU Embedded Toolchain for Arm the things started to work. GNU Arm Embedded Toolchain Version 8-2018-q4-major Linux 64 solved my problem.

theSealion · Answer 3 · 2018-06-21T12:54:11.787

Your code should work, but you are only toggling an unconnected µC pin.

If you look at the schematics from the "black pill" homepage the LED is connected to PB12

The BOOT0 pin should be connected to GND if you want to run your firmware (from flash) the BOOT1 pin doesn't matter.

One thing in your image: you don't have a resistor for your LED to limit the current, depending on the LED type this could damage the LED and/or the µC pin.

Maybe you should first try to use D2 from the board and if that works you could switch over to your on LED.

I don't know if you've done a correct initialization of the pin:

PB12 Setup

GPIO_InitTypeDef GPIO_InitStruct;

/* GPIO Ports Clock Enable */
__HAL_RCC_GPIOB_CLK_ENABLE();

/*Configure GPIO pin Output Level */
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, GPIO_PIN_RESET);

/*Configure GPIO pin : PB12 */
GPIO_InitStruct.Pin = GPIO_PIN_12;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

The Clock enable is very important for each peripheral.

I think you are talking about the LED on the board but in my scenario, I have connected an external LED (visible in the photo) to the board — Yashar, Jun 21 '18 at 10:20
You are right, I tried D2 and it seems it doesn't work either. here is the code I add for D2: first set PB12 to GPIO_Output and `HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_12); HAL_Delay(500);` in main method — Yashar, Jun 21 '18 at 12:23
my PB12 setup is same as what you wrote. Actually, I didn't write this by myself, it was generated by STM32CubeMX — Yashar, Jun 21 '18 at 13:48

score 0 · Answer 4 · answered Nov 11 '21 at 16:50

0

I had the same problem and I solved that by connecting BOOT0 pin to the ground...

answered Nov 11 '21 at 16:50

hassan karimi

1

1

Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Nov 11 '21 at 17:53

STM32 code uploads successfully but doesn't run

4 Answers4

PB12 Setup