PlatformIO Community

Creating custom board for STM32F429ZGT6

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. https://github.com/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 (https://github.com/CommunityGD32Cores/gd32-pio-projects/tree/main/gd32-spl-semihosting-printf).

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 https://github.com/platformio/platformio-core/issues/4069.

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_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

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 https://github.com/maxgerhardt/pio-swo-demo/blob/main/add_swo_viewer.py.

I’d also suggest opening a CLI and doing a pio upgrade --dev so that you’re on the very latest core version.