Is the board not flashable? What’s the output of the project task “Advanced → Verbose Upload”?
Board has SWD interface out which both in development and in production is connected to STLink
Output for Verbose Upload :
Processing erica_black_dsp (platform: ststm32; board: erica_black_dsp; framework: stm32cube)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/erica_black_dsp.html
PLATFORM: ST STM32 (14.2.0) > BDSP
HARDWARE: STM32F429ZGT6 180MHz, 256KB RAM, 1MB Flash
DEBUG: Current (stlink) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES:
- framework-stm32cubef4 1.26.2
- tool-dfuutil 1.9.200310
- tool-ldscripts-ststm32 0.1.0
- tool-openocd 2.1100.0 (11.0)
- tool-stm32duino 1.0.1
- toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 52 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
MethodWrapper(["checkprogsize"], [".pio/build/erica_black_dsp/firmware.elf"])
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [ ] 2.5% (used 6440 bytes from 262144 bytes)
Flash: [= ] 14.7% (used 154148 bytes from 1048576 bytes)
.pio/build/erica_black_dsp/firmware.elf :
section size addr
.isr_vector 428 134217728
.text 138084 134218160
.rodata 15364 134356248
.ARM.extab 0 134371612
.ARM 8 134371612
.preinit_array 0 134371620
.init_array 24 134371620
.fini_array 4 134371644
.data 700 536870912
.bss 5740 536871612
._user_heap_stack 1536 536877352
.ARM.attributes 42 0
.comment 126 0
.debug_frame 83264 0
.stab 204 0
.stabstr 493 0
Total 246017
<lambda>(["upload"], [".pio/build/erica_black_dsp/firmware.elf"])
AVAILABLE: blackmagic, cmsis-dap, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
openocd -d2 -s /Users/t/.platformio/packages/tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f4x.cfg -c "program {.pio/build/erica_black_dsp/firmware.elf} verify reset; shutdown;"
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.11.0-00155-ge392e485e (2021-03-15-18:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Error: open failed
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked
The OpenOCD invocation looks good, but OpenOCD can’t find your STLink adapter.
It seems like you’re using Mac. Do you have libusb installed? Can you connect to the chip using other tools, e.g., STM32CubeProgrammer?
You are right, this most probably is a test stand issue, will get back here once I have new wire to test this.
I’m on Mac, previously stuff was working under Eclipse/STM32IDE. I Found PlatrofmIO when I started thinking to move project in to VScode.
Today I’ve tried with new wires. Could upload successfully with default ini:
[env:erica_black_dsp]
platform = ststm32
board = erica_black_dsp
framework = stm32cube
When I tried to use build flags that I copied from old eclipse build setup I got errors:
/Users/t/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld: error: .pio/build/erica_black_dsp/FrameworkHALDriver/Src/stm32f4xx_hal.o uses VFP register arguments, .pio/build/erica_black_dsp/firmware.elf does not
Problem seems to be in
-mfloat-abi=hard
Seems to be toolchain or linkage? How can I solve this? Thanks!
It seems object files are compiled with -mfloat-abi=hard but this build flag isn’t used in the final ELF linking stage.
Try adding a small extra script to append to the linker flags.
extra_scripts = link_hardfloat.py
with link_hardfloat.py in the project’s root directory
Import("env")
env.Append(LINKFLAGS=["-mfloat-abi=hard"])
This seems to solve the issue. Thanks!
Now I could get hello world to run in debug mode! great!
Next questions I have are more regarding libraries and includes setup:
-
If adding
#include <stm32l4xx_hal.h>to main.cpp to VScode it does not see the framework file, what is correct way to set include path for such? -
Usually in STM32 HAL projects I would have config file provided by STM32 HAL library template
included with defines to set up library includes. Is this file defined somewhere in project settings or I have to add it to project /src dir ? -
I have my own library, which is located in parent directory of platformio project. Tree looks like this:
└─ . ├─ app2 │ ├─ app.cpp │ ├─ app.h │ └─ targets │ ├─ desktop_target_dir │ └─ platrofmio_dir ├─ app1 │ ├─ app.cpp │ ├─ app.h │ └─ targets │ ├─ desktop_target_dir │ └─ platrofmio_dir └─ custom_library ├─ blocks │ └─ some_block.h ├─ dsp │ └─ some_dsp.h └─ utils └─ some_util.h
How should I include my custom library correctly to the project, considering that I might need to debug and make library code changes while working in the environment?
I don’t understand the question. It does not “see” the framework file? There is a compile error when writing that include?
PlatformIO by default automatically uses a config file that enables all submodules. If you don’t want that, you can tell the stm32cube.py builder script to not use that default file by adding
board_build.stm32cube.custom_config_header = yes
and additionally adding a e.g. -Iinclude flag so that if your HAL config file is in include/ it will be found by the framework during the build process. An example is in e.g. GitHub - maxgerhardt/pio-stm32h7-stm32cube-freertos.
Adding libraries is per LDF doc and library options.
Your libraries should be organized in a PlatformIO compatible folder structure for this to work.
Since I don’t see where in the directory tree structure above the project root with the platformio.ini is, I can’t say specifically what path you need. One option is to use lib_extra_dirs with with a relative path, e.g. lib_extra_dirs = ../custom_library, then all folders within custom_library/ are seen as potentially includable libraries (blocks, dsp, utils modelled as separate libraries).
If you have more complex libraries and need to add include files, give a library a library.json file.
Lint gives this error:
#include errors detected. Please update your includePath. Squiggles are disabled for this translation unit() .C/C++(1696)
cannot open source file "stm32l4xx_hal.h"C/C++(1696)
I had wrong include file name copied from example files,
#include “stm32f4xx_hal.h”
works like charm!
Regarding rest:
Will read carefully library include docs and get back here with my progress!
@maxgerhardt before I jump in lib stuff deep in:
Program with simple hello world runs, but it does not print in to VScode terminal. Could you suggest how I can redirect stdout there. In original eclipse project I was debugging trough SWO.
Is it really via SWO or SWD semihosting? What’s a minimal piece of code to use SWO?
Out-of-the-box, PlatformIO doesn’t have the capability to read the SWO stream (or tell OpenOCD to read it), per Viewing SWO output within PIO?. But the linked topic also contains workarounds. The “Monitior” task starts miniterm.py, which can connect to serial ports (UART) and network sockets.
Seeing semihosting output is possible by expanding the GDB initialization commands and running the application in debug mode (gd32-pio-projects/gd32-spl-semihosting-printf at main · CommunityGD32Cores/gd32-pio-projects · GitHub).
Actually per Viewing SWO output within PIO? - #13 by maxgerhardt I was able to get a SWO demo running within PlatformIO. This is now also tracked in Support viewing SWO data · Issue #4069 · platformio/platformio-core · GitHub.
I think debugging via semihosting is OK for now, later on I might want to get SWO running and its good to know that there is work towards this direction.
I tried to add .ini lines
board_debug.semihosting = yes
debug_extra_cmds =
monitor arm semihosting enable
monitor arm semihosting_fileio enable
However linker fails to find initialise_monitor_handles()
What I am missing?
This doesn’t work outside the GigaDevice project I mentioned – it triggers something specific in platform-gd32. You need to remove that line and append your existing extra script with the lines
so that initialise_monitor_handles() becomes available.
; board_debug.semihosting = yes
removed ^^^ line and updated
update_link_flags.py
with:
Import("env")
env.Append(
LINKFLAGS=[
"-mthumb",
"-mfloat-abi=hard",
"-mfpu=fpv4-sp-d16",
"--specs=rdimon.specs",
],
LIBS=["rdimon"],
)
Still have same link error
changed that py code to
Import("env")
env.Append(
LINKFLAGS=[
"-mthumb",
"-mfloat-abi=hard",
"-mfpu=fpv4-sp-d16",
"--specs=rdimon.specs",
"--specs=nano.specs",
]
)
env.Append(LIBS=["rdimon"])
now error changed to
arm-none-eabi-g++: fatal error: /Users/t/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/nano.specs: attempt to rename spec 'link' to already defined spec 'nano_link'
compilation terminated.
*** [.pio/build/erica_black_dsp/firmware.elf] Error 1
for
Import("env")
env.Append(LINKFLAGS=["-mthumb", "-mfloat-abi=hard", "-mfpu=fpv4-sp-d16"])
env.Append(LINKFLAGS=["--specs=rdimon.specs"], LIBS=["rdimon"])
also link error undefined reference to `initialise_monitor_handles()’
Try adding those too
or try SWO with the referenced demo.
SWD semihosting is extremely slow – you will see for yourself.
Did not help, still linkage error…
Taking a look in SWO demo
So I’m trying to use SWO.
I’ve modified to platformio.ini:
[common_env_data]
build_flags =
-D VERSION=1.2.3
-D DEBUG=1
-Wall
-mcpu=cortex-m4
-ffunction-sections
-fdata-sections
; --specs=nosys.specs
-fstack-usage -MMD -MP
-std=c++17
-g3
-D DEBUG
-D USE_HAL_DRIVER
-D STM32F429xx
-mfloat-abi=hard
-mfpu=fpv4-sp-d16
-mthumb
[env:erica_black_dsp]
platform = ststm32
board = erica_black_dsp
framework = stm32cube
lib_extra_dirs = ../../../zenlib
; Build options
build_flags =
${common_env_data.build_flags}
extra_scripts = pre:add_swo_viewer.py
update_link_flags.py
swo_trace_clkin_freq = 180000000
debug_server = $PLATFORMIO_CORE_DIR/packages/tool-openocd/bin/openocd
-f $PLATFORMIO_CORE_DIR/packages/tool-openocd/scripts/interface/stlink.cfg
-f $PLATFORMIO_CORE_DIR/packages/tool-openocd/scripts/target/stm32f4x.cfg
-c "tpiu config internal - uart off 180000000"
-c "itm ports on"
-c "tcl_port 6666"
Copied from demo repo
add_swo_viewer.py
swo_parser.py
On build time I’m getting warning:
Warning! Ignore unknown configuration option
swo_trace_clkin_freqin section [env:erica_black_dsp]
Then when I try to connect after main() breakpoint with
python3 swo_parser.py --dont-run
I’m getting no output.
I tried to do General → Upload and then Custom-> SWO viewer:
*** [swo_viewer] NameError : name 'link' is not defined
Traceback (most recent call last):
File "/Users/t/.platformio/packages/tool-scons/scons-local-4.2.0/SCons/Action.py", line 1279, in execute
result = self.execfunction(target=target, source=rsources, env=env)
File "/Users/t/GitHub/synths/zendelay/targets/BDSP/add_swo_viewer.py", line 28, in swo_viewer_task
"-f", "interface/%s.cfg" % link,
NameError: name 'link' is not defined
Can be ignored, the value is custom-used in the script.
Funny that the code worked for me, but there’s definitely an error there. Copy the latest version again from pio-swo-demo/add_swo_viewer.py at main · maxgerhardt/pio-swo-demo · GitHub.
I’d also suggest opening a CLI and doing a pio upgrade --dev so that you’re on the very latest core version.