Programming the blue pill with ST-link V2 on Ubuntu

[IrejectYourReality]

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 OUTPUT

Then 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: [Select]

HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13);

HAL_Delay(500);
I compiled succesfully (make).

Then I tried to flash the MCU by using https://github.com/texane/stlink
I connected the bluepill with st-link V2 to my computer, and ran

Code: [Select]

./st-flash write ~/bluepill/build/bluepill.bin 0x08000000
Everything looked ok:

Code: [Select]

st-flash 1.4.0-53-gf87076f

2018-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 0x20036410

2018-11-24T16:45:49 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes

2018-11-24T16:45:49 INFO common.c: Attempting to write 3788 (0xecc) bytes to stm32 address: 134217728 (0x8000000)

Flash page at addr: 0x08000c00 erased

2018-11-24T16:45:49 INFO common.c: Finished erasing 4 pages of 1024 (0x400) bytes

2018-11-24T16:45:49 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id

2018-11-24T16:45:49 INFO flash_loader.c: Successfully loaded flash loader in sram

4/4 pages written

2018-11-24T16:45:49 INFO common.c: Starting verification of write complete

2018-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?

[screwbreaker]

sudo is not required to get the write rights on the device?

[pyroesp]

Did you initialize the GPIO with HAL_GPIO_Init(...) ?

[HB9EVI]

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 code

maybe 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

[IrejectYourReality]

sudo is not required to get the write rights on the device?

I dont know, but it seems to be working fine without sudo, and tutorials are also using it without sudo

Did you initialize the GPIO with HAL_GPIO_Init(...) ?

Yes I did, it is a part of the autogenerated code from STMCubeMX

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 code

No, 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.

[HB9EVI]

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.

[IrejectYourReality]

Here is main.c:

https://pastebin.com/aR786rCn

[HB9EVI]

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

[IrejectYourReality]

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/PqUfA15J

How do I verify that the PLL has a locked state?

[screwbreaker]

I dont know, but it seems to be working fine without sudo, and tutorials are also using it without sudo

Ok, 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.

[technix]

If I recalled it right, you should be able to program and debug that chip using OpenOCD and ST-Link v2...

[HB9EVI]

code looks ok, except this:

Code: [Select]

  __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

[IrejectYourReality]

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: [Select]

arm-none-eabi-gdb bluepill.elf
tar extended-remote :4242
Then loaded the code and ran it:

Code: [Select]

(gdb) load
(gdb) continue
But 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.

[tsman]

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.

[HB9EVI]

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: [Select]

source [find interface/stlink-v2.cfg]
source [find target/stm32f1x.cfg]
start openocd and it will connect to the target

afterward you start

Code: [Select]

gdb bluepill.elf
then

Code: [Select]

target remote localhost:3333

[IrejectYourReality]

Ok, I tried openocd, uploaded the code:

Code: [Select]

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> reset halt
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000e10 msp: 0x20005000
> flash write_image erase /home/dan/bluepill.elf
auto erase enabled
device id = 0x20036410
flash size = 64kbytes
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20005000
wrote 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: [Select]

sudo openocd -f /usr/share/openocd/scripts/board/bluepill.cfg -f /usr/share/openocd/scripts/interface/stlink-v2.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
none separate
Warn : Interface already configured, ignoring
Error: already specified hl_layout stlink
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.247152
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection on tcp/4444
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000e10 msp: 0x20005000
auto erase enabled
Info : device id = 0x20036410
Info : flash size = 64kbytes
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20005000
wrote 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?

[cdev]

You can also use a USB-UART adapter to program the Blue Pill using a program called stm32flash

Ground 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.