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:
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.
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.
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.
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.
Warning! Ignore unknown configuration option swo_trace_clkin_freq in 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