STM32F2xx Debugging with STLink V2 problems

PlatformIO Core
#1

I’m using an STLink V2 to debug my code on an STM32F207 chip. If I modify code and then Start Debugging from the toolbar, it rebuilds then uploads code to the target and I can debug just fine.

Problem: If I merely build the code and then try to only Upload the .bin file. It proceeds and says upload successful (here are last lines of output):

debug_level: 1
hla_swd
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080001a0 msp: 0x20004cf0
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

As soon as this completes, the target application is dead, won’t run at all. Tried hardware resetting to no avail. It almost seems like the Upload process is putting the binary into the wrong areas of the mcu flash.

Is there a way I can look at what the Upload command is doing?
Is there a also a way to tell the Upload task where the base flash address should be?

The platformio.ini file default_envs points to an [env:debug] section that uses

extra_scripts =
${common.extra_scripts}
buildroot/scripts/stm32f2xx_0x8000_iap.py

The custom py script sets FLASH: ORIGIN = 0x8008000 in the link script and maybe this
doesn’t get picked up when running the Upload command?

I’m lost at this point and and any thoughts are appreciated,
thanks.

#2

Open a terminal using *PlatformIO: New Terminal" (either from the status bar, from Quick Access or from the Command Palette) and run:

pio run -v -t upload

This will produce verbose output and show the exact upload command.

For further support, it’ll helpful if you post the relevant output and your custom py script as well.

#3

Thanks for the suggestion manuel, I tried it but this is what I get back

PS C:\Users\tony\Documents\CNC\BIGTREETECH-TouchScreenFirmware-master - Copy> pio -v -t upload
Usage: pio [OPTIONS] COMMAND [ARGS]…
Try ‘pio -h’ for help.

Error: no such option: -v
PS C:\Users\tony\Documents\CNC\BIGTREETECH-TouchScreenFirmware-master - Copy> pio -h
Usage: pio [OPTIONS] COMMAND [ARGS]…

Options:
–version Show the version and exit.
-f, --force DEPRECATE
-c, --caller TEXT Caller ID (service)
–no-ansi Do not print ANSI control characters
-h, --help Show this message and exit.

Commands:
access Manage resource access
account Manage PlatformIO account
boards Embedded board explorer
check Static code analysis
ci Continuous integration
debug Unified debugger
device Device manager & serial/socket monitor
home UI to manage PlatformIO
lib Library manager
org Manage organizations
package Package manager
platform Platform manager
project Project manager
remote Remote development
run Run project targets (build, upload, clean, etc.)
settings Manage system settings
system Miscellaneous system commands
team Manage organization teams
test Unit testing
update Update installed platforms, packages and libraries
upgrade Upgrade PlatformIO to the latest version

#4

Your copy/paste lost the word “run”. Try it with the correct command again.

#5

manuel,
finally got it to run, the command needed to be “pio run -t upload -v”, I guess the -t had to precede the “upload” command.
Finally I saw that upload was calling

openocd -d2 -s C:\Users\tony.platformio\packages\tool-openocd/scripts -f interface/cmsis-dap.cfg -c “transport select swd” -f target/stm32f2x.cfg -c “program {.pio\build\BIGTREE_TFT35_V3_0 DEBUG UNIQUE\BIGTREE_TFT35_V3.0.26.x} verify reset; shutdown;”

and that stm32f2x.cfg file was indeed setting the flash bank to 0x08000000. For some reason, the project firmware needs to leave the first 32K open and must be loaded at 0x08008000 instead. So I changed that stm32f2x.cfg file and it works fine now!

Thanks!

#6

No-no, local modifications to the openOCD configs are not portable, PlatformIO is configurable for these bootloader-occupies-x-amount-of-space cases

Please revert your openOCD changes (or remove C:\Users\tony.platformio\packages\tool-openocd completely) and addd

board_upload.offset_address = 0x08008000

to the platformio.ini.

This also auto-applies it to all other possible upload methods, not only via STLink, but e.g. DFU, serial etc.

If you’ve created a custom board JSON file for this, this can also be directly written into the manifest file as shown in e.g.

#7

Wow, that is a much simpler, clean way to do it. Wasn’t aware that this was one of the UPLOAD commands available. I wish I would have found that somewhere in the documentation, it would have saved me a lot of time. I’ve been using C/C++ for a few years and worked with IAR IDE. I like PlatformIO, it’s a much richer experience, but obviously I’m overwhelmed by all the details.

What I eventually wound up doing was not to modify the stm32f2x.cfg, but instead added this to the platformio.ini:

upload_protocol = custom
upload_command = $PROJECT_PACKAGES_DIR\tool-stm32duino\texane-stlink\st-flash write $SOURCE 0x8008000

Another thing I want to ask is that it seemed like the stock Upload command (before trying the above) was writing “program {.pio\build\BIGTREE_TFT35_V3_0 DEBUG UNIQUE\BIGTREE_TFT35_V3.0.26.x}.
This is actually the .elf file it created by the build process, not the .bin file. So it’s uploading the .elf to the flash and basically bricks the system. If I inspect the memory at 0x08000000 the first 3 bytes are “ELF” and the rest of the programmed blocks match the contents of the BIGTREE_TFT35_V3.0.26.x file (which is the elf file in reality). Fortunately I can use the stm32cube programmer to get things back again.

I don’t understand why the build produces that filename with no extension. Could it be due to this custom python script which is one of the extra_scripts= section?

Import("env")
build_flags = env.ParseFlags(env['BUILD_FLAGS'])
flags = {k: v for (k, v) in build_flags.get("CPPDEFINES")}
if flags.get("HARDWARE") == "MKS_28_V1_0":
    filename = "MKSTFT28"
else:
    filename = flags.get("HARDWARE") + "." + flags.get("SOFTWARE_VERSION")
print("Renaming output file to " + filename)
env.Replace(PROGNAME=filename)

I think that script just renames the default file from “firmware” to “BIGTREE_TFT35_V3.0.26.x”. But it also results in no actual BIGTREE_TFT35_V3.0.26.x.elf file to be generated, just the filename with no extension called BIGTREE_TFT35_V3.0.26.x (which is the .elf file without .elf appended).

Could there be a problem with the “.” chars in the renamed PROGNAME causing this?

When I used the method of

upload_protocol = custom
upload_command =  $PROJECT_PACKAGES_DIR\tool-stm32duino\texane-stlink\st-flash write $SOURCE 0x8008000

the texane-stlink flasher uses $SOURCE which is the actual binary.

So, if I take your suggestion of “board_upload.offset_address = 0x08008000”, how do I get around the problem of it wanting to incorrectly upload what is actually the .elf?

Thank you maxgerhardt for your assistance!

#8

OpenOCD can accept the ELF file and should still respect the upload address. Does that not work when uploaded?