Programming the blue pill with ST-link V2 on Ubuntu - Page 1
Forum section: electronics / general

author: IrejectYourReality
author_rank: Contributor
timestamp: November 24, 2018, 04:11:53 pm
content: Hello, I am trying to program my blue pill board (http://wiki.stm32duino.com/index.php?title=Blue_Pill) using an st-link V2. I am using Ubuntu 18.04.I downloaded STMCubeMX, started a new project, and only thing I changed was:- RCC - ceramic oscillator on HSE- PC13 set as OUTPUTThen I auto resolved the clocks, and generated the code, using Makefile as the Toolchain/IDE.I opened up main.c, and added this to the main while(1) loop:Code:HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13);HAL_Delay(500);I compiled succesfully (make).Then I tried to flash the MCU by usinghttps://github.com/texane/stlinkI connected the bluepill with st-link V2 to my computer, and ranCode:./st-flash write ~/bluepill/build/bluepill.bin 0x08000000Everything looked ok:Code:st-flash 1.4.0-53-gf87076f2018-11-24T16:45:49 INFO common.c: Loading device parameters....2018-11-24T16:45:49 INFO common.c: Device connected is: F1 Medium-density device, id 0x200364102018-11-24T16:45:49 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes2018-11-24T16:45:49 INFO common.c: Attempting to write 3788 (0xecc) bytes to stm32 address: 134217728 (0x8000000)Flash page at addr: 0x08000c00 erased2018-11-24T16:45:49 INFO common.c: Finished erasing 4 pages of 1024 (0x400) bytes2018-11-24T16:45:49 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id2018-11-24T16:45:49 INFO flash_loader.c: Successfully loaded flash loader in sram4/4 pages written2018-11-24T16:45:49 INFO common.c: Starting verification of write complete2018-11-24T16:45:49 INFO common.c: Flash written and verified! jolly good!But my board is not blinking, even after restarting. So, what am I doing wrong?

author: screwbreaker
author_rank: Regular Contributor
timestamp: November 24, 2018, 05:42:35 pm
content: sudo is not required to get the write rights on the device?

author: pyroesp
author_rank: Regular Contributor
timestamp: November 24, 2018, 06:22:44 pm
content: Did you initialize the GPIO with HAL_GPIO_Init(...) ?

author: HB9EVI
author_rank: Frequent Contributor
timestamp: November 24, 2018, 06:31:42 pm
content: if the shown code is all what main.c contains it'll not work at all; if there is more than these two lines, please post all the codemaybe also take a look to openocd; that's more or less the standard to use for programming the mcus on linux, since it'll also allow you debugging when needed

author: IrejectYourReality
author_rank: Contributor
timestamp: November 24, 2018, 06:46:58 pm
content: Quote from: screwbreaker on November 24, 2018, 05:42:35 pmI dont know, but it seems to be working fine without sudo, and tutorials are also using it without sudoQuote from: pyroesp on November 24, 2018, 06:22:44 pmYes I did, it is a part of the autogenerated code from STMCubeMXQuote from: HB9EVI on November 24, 2018, 06:31:42 pmNo, the code contains all the other bits (clock initiation, GPIO pin setup etc), as it was generated by the STMCubeMX. The code I posted was the only thing I added.

author: HB9EVI
author_rank: Frequent Contributor
timestamp: November 24, 2018, 07:01:47 pm
content: Yea, well, then post it; if I were you I wouldn't start relying too much on CubeMX and HAL; autogeneration can give you a hint how to set up something, but it makes thing actually overly complex and slow.

author: IrejectYourReality
author_rank: Contributor
timestamp: November 24, 2018, 07:16:18 pm
content: Here is main.c:https://pastebin.com/aR786rCn

author: HB9EVI
author_rank: Frequent Contributor
timestamp: November 24, 2018, 07:28:32 pm
content: You said you set the parameters for HSE clock, but in the code you use HSI; I don't from mind, what default clock speed it has, I guess it's 8MHz, but verify that. If you use the PLL, you have to watch out to not exceed the maximal allowed clock of 72MHz.If you use the PLL, it's a good idea to verify if the PLL has locked state before proceeding.I don't know, if the HAL is doing that, but I wouldn't rely blindly on it, since clocks depend from a working PLL

author: IrejectYourReality
author_rank: Contributor
timestamp: November 24, 2018, 07:51:16 pm
content: I am sorry, I posted a wrong verison of the code (I tried to run from the internal oscillator to see if it made a difference)Here is the one with HSE:https://pastebin.com/PqUfA15JHow do I verify that the PLL has a locked state?

author: screwbreaker
author_rank: Regular Contributor
timestamp: November 24, 2018, 07:52:44 pm
content: Quote from: IrejectYourReality on November 24, 2018, 06:46:58 pmOk, I asked, because I remember I used it.By the way, I got the same issue, it say "Flash written and verified! jolly good!" but then it does not work.With the ST-ulility for Windows everything worked correctly. Try it first, to make sure your code is correct.

author: technix
author_rank: Super Contributor
timestamp: November 24, 2018, 07:58:02 pm
content: If I recalled it right, you should be able to program and debug that chip using OpenOCD and ST-Link v2...

author: HB9EVI
author_rank: Frequent Contributor
timestamp: November 24, 2018, 08:02:34 pm
content: code looks ok, except this:Code:__HAL_RCC_GPIOD_CLK_ENABLE();there is no GPIOD on the STM32F103C8, it's unlikely to cause issues, but remove it and try again.PLL is not activated in that code, so no source of trouble.good advice from technix: switch to openocd and use gdb for debugging

author: IrejectYourReality
author_rank: Contributor
timestamp: November 24, 2018, 08:14:50 pm
content: Removed the __HAL_RCC_GPIOD_CLK_ENABLE(); and it did not help, as expected.I will try to change to openOCD.But in the meantime, I can run the gdb with the texane/stlink.I started the gdb:Code:arm-none-eabi-gdb bluepill.elftar extended-remote :4242Then loaded the code and ran it:Code:(gdb) load(gdb) continueBut I only got the same "jolly good" message, nothing else.Also, if I reset the board, gdb will recognize it, but still no LED blinks if I run the code.

author: tsman
author_rank: Frequent Contributor
timestamp: November 24, 2018, 08:21:31 pm
content: What happens if you disconnect the ST-Link from the STM32 board or press the reset button on the STM32 board? It sounds like st-flash is holding it in reset.

author: HB9EVI
author_rank: Frequent Contributor
timestamp: November 24, 2018, 08:36:42 pm
content: the blue pill has no NRST on the SWD-connector, just SWDIO and SWCLK; more likely the programmer software doens't release the mcu from halt condition after loading the code.get a look on openocd and forget that programmer software.set up a file called openocd.cfg:Code:source [find interface/stlink-v2.cfg]source [find target/stm32f1x.cfg]start openocd and it will connect to the targetafterward you startCode:gdb bluepill.elfthenCode:target remote localhost:3333

author: IrejectYourReality
author_rank: Contributor
timestamp: November 24, 2018, 08:39:35 pm
content: Ok, I tried openocd, uploaded the code:Code:Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.Open On-Chip Debugger> reset halttarget halted due to debug-request, current mode: ThreadxPSR: 0x01000000 pc: 0x08000e10 msp: 0x20005000> flash write_image erase /home/dan/bluepill.elfauto erase enableddevice id = 0x20036410flash size = 64kbytestarget halted due to breakpoint, current mode: ThreadxPSR: 0x61000000 pc: 0x2000003a msp: 0x20005000wrote 4096 bytes from file /home/dan/bluepill.elf in 0.292450s (13.678 KiB/s)> reset>And this is the output from the openocd window:Code:sudo openocd -f /usr/share/openocd/scripts/board/bluepill.cfg -f /usr/share/openocd/scripts/interface/stlink-v2.cfgOpen On-Chip Debugger 0.10.0Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.htmlInfo : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWDadapter speed: 1000 kHzadapter_nsrst_delay: 100none separatenone separateWarn : Interface already configured, ignoringError: already specified hl_layout stlinkInfo : Unable to match requested speed 1000 kHz, using 950 kHzInfo : Unable to match requested speed 1000 kHz, using 950 kHzInfo : clock speed 950 kHzInfo : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748Info : using stlink api v2Info : Target voltage: 3.247152Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpointsInfo : accepting 'telnet' connection on tcp/4444target halted due to debug-request, current mode: ThreadxPSR: 0x01000000 pc: 0x08000e10 msp: 0x20005000auto erase enabledInfo : device id = 0x20036410Info : flash size = 64kbytestarget halted due to breakpoint, current mode: ThreadxPSR: 0x61000000 pc: 0x2000003a msp: 0x20005000wrote 4096 bytes from file /home/dan/bluepill.elf in 0.292450s (13.678 KiB/s)Still no blinky. I am following some tutorial that I found online, so maybe the commands that I used were not the correct ones?

author: cdev
author_rank: Super Contributor
timestamp: December 02, 2018, 01:30:00 am
content: You can also use a USB-UART adapter to program the Blue Pill using a program called stm32flashGround goes to the pin labeled G, 2nd from the bottom right corner. +3.3 volts goes to the "3.3" pin on the bottom right corner. TXD on the USB-UART dongle goes to the A10 pin and RXD goes to the A9 pin. - if your dongle is mislabeled like many are you may need to reverse a9 and a10.You have to create the binary file using your tool and then upload the binary using stm32flash via your *3.3 volt* USB-UART dongle, by changing the boot0 jumper from 0 to 1 then applying power and then immediately uploading the program . (have the command line ready to go right after the power on the blue pill device is applied) You should see the lights blinking, Then change the boot 0 jumper back from 1 to 0 (normal state when not writing a program is 0 on both jumpers) and restart it. Otherwise it wont stick. Maybe you just left out that part?I have never figured out how to use my stlink v2 properly. I have however successfully loaded self compiled software without it fine. Using whichever USB UART dongle Ive had handy.