Some time ago I've moved from arduino ide to Eclipse (on linux). My project (small game for my nephew) used ST SPL for "blue pill", u8g library (graphics primitives, screen buffer handling), Nokia 5110 LCD with my own drivers and rotary encoder (handled by my code) - nothing special.
In fact I've used eclipse for code navigation and as good source browser for ST and u8g staff. Build process was driven by my own self-made makefile and the only linked in things were SPL distribution rooted startup files (no libgcc nor libc nor libstdc++).
I've used Chinese st-link clone for uploads with st-flash utility (exec bundled with Arduino IDE for Linux). Everything worked fine and development was very smooth - every code change was recompiled and re-linked by makefile and finally uploaded to stm32 board with reset and program started.
For next project i'd like to give the chance to other tools - Arduino API (stm32duino) built via PlatformIO IDE (VSCode on linux). In terms of usability this is way better than Arduino IDE - VSCode is decent IDE with powerful Sublime like editor, code completion and navigation. Unfortunately, on first sketch (LED blink) problems appeared. Build process is smooth but firmware upload is very unstable:
First upload (board had my game fw) was smooth:
Code: Select all
st-flash write .pioenvs/genericSTM32F103CB/firmware.bin 0x08000000 2018-01-20T15:56:03 INFO src/usb.c: -- exit_dfu_mode 2018-01-20T15:56:03 INFO src/common.c: Loading device parameters.... 2018-01-20T15:56:03 INFO src/common.c: Device connected is: F1 Medium-density device, id 0x20036410 2018-01-20T15:56:03 INFO src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes 2018-01-20T15:56:03 INFO src/common.c: Attempting to write 8436 (0x20f4) bytes to stm32 address: 134217728 (0x8000000) ... 2018-01-20T15:56:04 INFO src/common.c: Starting verification of write complete 2018-01-20T15:56:04 INFO src/common.c: Flash written and verified! jolly good! 8/8 pages written
Code: Select all
rm-none-eabi-objcopy -O binary .pioenvs/genericSTM32F103CB/firmware.elf .pioenvs/genericSTM32F103CB/firmware.bin st-flash write .pioenvs/genericSTM32F103CB/firmware.bin 0x08000000 2018-01-19T23:03:55 INFO src/common.c: Loading device parameters.... 2018-01-19T23:03:55 WARN src/common.c: unknown chip id! 0xa05f0000 st-flash 1.3.1
Then I've tried to re-flash my previous FW (done with makefile) It's uploaded with the same method (st-flash write fw 0x8000000) and first time I've to activate serial bootloader, but, after first flash every re-flashing was smooth again - this proves that HW (board and st-link) is still operable and stm32duinow firmware is probably the root of the problem. I've also tried to upgrade fw on st-link (now its newest) and try most recent texane/stlink, but it did change nothing...
I wonder if someone else had similar problems and why stm32duino based firmware (just simple blink) makes the board not flashable via st-link...
Maybe my board is somehow broken, but using old staff with it still works fine. It looks like stm32duino init part or some gcc related staff makes re-flashing so hard. I've tried 3 different toolchains (Arduino gcc, PlatformIO gcc and bleeding-edge gcc) but it also changed nothing..