STM8 debug no symbols

brett_anderson · May 11, 2021, 12:45pm

Hey All,

Stumbled across PlatformIO while looking for an IAR replacement for STM8 development. I had been playing with SDCC and OpenOCD via Eclipse when I found this. I really want to like it, but I can’t seem to get debugging working.

I setup just a sample project, basically the GPIO blinky. Compiles fine, and I can actually download to our PCBA (custom) and the appropriate LED does indeed flash. Fantastic!

Debug is where things stall. I have tried every config thing that I can find from this forum or the github repo discussions, and they all end the same way.
(no debugging symbols found)…done
Target runs, but no breakpoints and no well, debug info.

The output states it is building in debug mode, so that should not be a problem. It creates and elf, so -out-fmt-elf must be set.

I have some debug control, because I can pause the program, but no debug symbols.

I’m as up to date as possible, as I just found you guys yesterday and installed everything. I even checked that there were no pending updates with either PlatformIO or VSCode.

Platformio.ini: (default, plus I added debug_tool = stlink)
[env:stm8s003f3]
platform = ststm8
board = stm8s003f3
framework = spl
debug_tool = stlink

Do I need to add a debug env? I was looking that up when I finally got into the forum. (5 min expiration is riddiculous. It took 3 minutes for it to be caught by our spam filter, so took a lot of tries to get it released and clicked in under 5…)

Any guidance would be appreciated. I’ve read a lot of the docs, but some are not up to date. Ex, states to use debug_tool stlinkv2, but if you use that the build fails and says use stlink. no biggie, docs always lag behind.

I’m on a custom board (works fine), stm8s003f3 and st-linkv2 debugger.

Thanks!

maxgerhardt · May 11, 2021, 12:47pm

Currently a bug in SDCC prevents this from working, as noted in Debugging not working with SPL examples · Issue #44 · platformio/platform-ststm8 · GitHub.

brett_anderson · May 11, 2021, 1:13pm

Well shoot.

Guess I’ll maybe circle back if it ever gets fixed. Thanks for the quick reply, sorry I didn’t find that post first.

maxgerhardt · May 11, 2021, 1:26pm

We really hope that too, right now we are depending on 3 SDCC bugs

to get a good debugging experience for more complex project beyond the baremetal example, which is working. Sadly the bugs haven’t received much developer attention though…

brett_anderson · May 11, 2021, 1:49pm

OK. If I find some time, I might play with it more and see if I can add to it. I was having similar issues using SDCC and OpenOCD in Eclipse, which is how I stumbled across you guys.

I’m a professional embedded firmware developer, so I’m excited about what you guys are doing. IAR was fine for the STM8, but once they changed the code limit to 4k, I went fishing.

One question I had, was the order of the files when linking. SDCC doc 3.2.3 states that the .rel file containing main MUST be first in the list when passed for linking. If I run “platformio run -v”, I can see that it is passing stm8s_gpio.rel first, and main.rel second. I had weird issues until I wrote my makefile to enforce that main.c was first.

Is there a way I can control the file order in platformio?

maxgerhardt · May 11, 2021, 2:53pm

That would be extremely interesting if that is a fix.

PlatformIO is based on the SCons build system (written in Python), and uses its API calls to add the source files to the build (e.g. here, here). I’m not an expert enough on that to see how the link order could be easily changed there / what it depends on.

But still what one can do is log all compiler commands (as you’ve already done with pio run -v), add the absolute path to the compiler in front of the sdcc command (aka C:\Users\<user<\.platformio\packages\toolchain-sdcc\bin), write those to a .bat batch file and run it. Then load the resulting .elf file into stm8-gdb (C:\Users\<user>\.platformio\packages\tool-stm8binutils\bin) and see what it says. If you or anyone can find a combination of flags, command reorders or linker reorders that causes stm8-gdb to not say Dwarf Error and (no debugging symbols found), that would be a major breakthrough, and then we can look into teaching PlatformIO how to do it correctly.

brett_anderson · May 11, 2021, 3:10pm

Tentativly, I can confirm that fixes the no debug symbols issue.

I removed stm8s.h, and added in stm8s_gpio.c to the src directory. I added stm8s_gpio.h to the include directory.

Running platformio run -t debug -v and confirmed that main.rel is the first file listed in the last call to SDCC.

Hit debug, and I get:

It isn’t stopping at the breakpoint correctly, but it looks like this is related to your debug symbols issue. I have to run, but will play with this more.

brett_anderson · May 11, 2021, 3:12pm

Full build verbose:

$ platformio run -t debug -v
Processing stm8s003f3 (platform: ststm8; board: stm8s003f3; framework: spl; debug_tool: stlink)
------------------------------------------------------------------------------------------------------------------------------------------------
CONFIGURATION: https://docs.platformio.org/page/boards/ststm8/stm8s003f3.html
PLATFORM: ST STM8 (2.0.0) > ST STM8S003F3 chip
HARDWARE: STM8S003F3P6 16MHz, 1KB RAM, 8KB Flash
DEBUG: Current (stlink) External (stlink)
PACKAGES:
 - framework-ststm8spl 0.20301.181217 (2.3.1)
 - tool-stm8binutils 0.230.0 (2.30)
 - toolchain-sdcc 1.40100.12072 (4.1.0)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
sdcc -o .pio\build\stm8s003f3\src\main.rel -c -mstm8 --debug --out-fmt-elf --opt-code-size -DF_CPU=16000000L -DPLATFORMIO=50101 -DSTM8S_003 -DSTM8S003 -DUSE_STDPERIPH_DRIVER -DUSE_STDINT -D__PLATFORMIO_BUILD_DEBUG__ -Iinclude -Isrc -IC:\Users\branderson\.platformio\packages\framework-ststm8spl\Libraries\STM8S_StdPeriph_Driver\inc -Isrc src\main.c
sdcc -o .pio\build\stm8s003f3\firmware.elf -mstm8 --nostdlib --code-size 8192 --iram-size 1024 --out-fmt-elf .pio\build\stm8s003f3\src\main.rel 
.pio\build\stm8s003f3\src\stm8s_gpio.rel .pio\build\stm8s003f3\src\stm8s_it.rel -LC:\Users\branderson\.platformio\packages\toolchain-sdcc\lib\stm8 -lstm8
MethodWrapper(["checkprogsize"], [".pio\build\stm8s003f3\firmware.elf"])
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.2% (used 2 bytes from 1024 bytes)
Flash: [=         ]   5.3% (used 438 bytes from 8192 bytes)
.pio\build\stm8s003f3\firmware.elf  :

section           size    addr

INITIALIZED          2       1

SSEG                 1       3

HOME               111   32768

GSINIT              26   32879

GSFINAL              3   32905

INITIALIZER          2   32908

CODE               296   32910

.debug_line       1538       0

.debug_loc         964       0

.debug_abbrev      271       0

.debug_info       1924       0

.debug_pubnames    775       0

.debug_frame      1501       0

Total             7414
stm8-objcopy -O ihex --remove-section=".debug*" --remove-section=SSEG --remove-section=INITIALIZED --remove-section=DATA .pio\build\stm8s003f3\firmware.elf .pio\build\stm8s003f3\firmware.hex
========================================================= [SUCCESS] Took 1.45 seconds =========================================================

full debug console output:

Processing stm8s003f3 (platform: ststm8; board: stm8s003f3; framework: spl)

--------------------------------------------------------------------------------

Verbose mode can be enabled via `-v, --verbose` option

CONFIGURATION: 

PLATFORM: ST STM8 (2.0.0) > ST STM8S003F3 chip

HARDWARE: STM8S003F3P6 16MHz, 1KB RAM, 8KB Flash

DEBUG: Current (stlink) External (stlink)

PACKAGES:

- framework-ststm8spl 0.20301.181217 (2.3.1)

- tool-stm8binutils 0.230.0 (2.30)

- toolchain-sdcc 1.40100.12072 (4.1.0)

LDF: Library Dependency Finde

LDF Modes: Finder ~ chain, Compatibility ~ soft

Found 0 compatible libraries

Scanning dependencies...

No dependencies

Building in debug mode

Checking size .pio\build\stm8s003f3\firmware.elf

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"

RAM: [ ] 0.2% (used 2 bytes from 1024 bytes)

Flash: [= ] 5.3% (used 438 bytes from 8192 bytes)

========================= [SUCCESS] Took 0.83 seconds =========================

Reading symbols from C:\Users\branderson\OneDrive - Trek Bicycle Corporation\Documents\PlatformIO\Projects\TestDemo\.pio\build\stm8s003f3\firmware.elf...

done.

PlatformIO Unified Debugger ->

PlatformIO: debug_tool = stlink

PlatformIO: Initializing remote target...

xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:29)

Licensed under GNU GPL v2

For bug reports, read



srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst

Info : tcl server disabled

Info : telnet server disabled

Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748

Info : Target voltage: 3.223127

Info : clock speed 800 kHz

brett_anderson · May 11, 2021, 5:32pm

OK, so now I’m going to say confirmed.

I can switch it back and forth. If stm8s_gpio.rel is the first file passed, I get DWARF error, and no debug symbols found. If main.rel is the first file passed, I get no errors on debug symbols. This matches my experience when I was building with SDCC via Makfiles I created.

Relevant part of SDCC documentation, section 3.2.3 last paragraph:

The file containing the main() function MUST be the FIRST file specified in the command line, since the
linkage editor processes file in the order they are presented to it. The linker is invoked from SDCC using a script
file with extension .lnk. You can view this file to troubleshoot linking problems such as those arising from missing
libraries.

I think this is coming down to random chance though on which file is first. I’m including the same files, but if I load gpio through stm8s_conf, then it ends up first. If I comment that out, and load it manually through src/include, then main ends up first.

I still have an issue debugging, but that very well could be on my side and unrelated to the DWARF error (no debug symbols found). The code runs, I can pause it and restart it, but no breakpoints. When I pause, I’m also not seeing information in the call stack. Unknown source is all it says.

maxgerhardt · May 11, 2021, 5:33pm

That is also the experience that I had when there was a DWARF error and it couldn’t determine the address of any symbol. But it’s weird that you get past this error and still can’t debug properly… I’ll try and check this on my end.

brett_anderson · May 11, 2021, 5:44pm

I can create and get rid of the DWARF error … (no debug symbols found), by changing the file order.

I’m going to play with the python script. What I did in my makefile, was put main.c as a specific add before I did the wildcard searches for all of the other *.c files. That way I could force it first in the list. I think the same would work here. The only drawback, is that you are required to have a ‘main.c’, as opposed to a .c file that includes a main().

This has my interest for now. I’ll get back to real work at some point today.

brett_anderson · May 11, 2021, 7:59pm

And… I can debug.

I’m not positive what happened, but I’ll keep looking. I switched to a different STLinkV2, and it works.
Both are at version V2.J29.S7, so no idea why the change.

I’ll keep you posted as I find more, but I’m very confident saying the order of the files matters. I’m reading through the Python and I’ll try out some edits.

maxgerhardt · May 11, 2021, 8:02pm

I’ll update the issue and see what @valeros can maybe do about this – the linking order might be done very implicitly with the order of some API calls and not be apparent / easily changable

brett_anderson · May 11, 2021, 8:04pm

It looks like it is just the order it discovers them. From what I’m seeing, it discovers the spl core files first, then the source directory.

I don’t think it is a problem to require a main.c. Put that in the source directory by default, and in the source file list builder, put main.c first, then discover the rest. Generate an error if main.c is missing. That was my plan. If he knows more, he might be able to do it faster.

maxgerhardt · May 11, 2021, 8:56pm

Can you upload your reference project where it works? I’ve tried it starting from the spl-blink example, just barebones. I added build_type = debug at the bottom of the platformio.ini and did pio run -e stm8sblue -v to get the compiler commands. The linker command is

sdcc -o .pio\build\stm8sblue\firmware.elf -mstm8 --nostdlib --code-size 8192 --iram-size 1024 --out-fmt-elf .pio\build\stm8sblue\SPL\stm8s_gpio.rel .pio\build\stm8sblue\src\main.rel .pio\build\stm8sblue\src\stm8s_it.rel -LC:\Users\Max\.platformio\packages\toolchain-sdcc\lib\stm8 -lstm8

I.e, first stm8s_gpio.rel then main.rel then stm8s_it.rel. Loading this firmware.elf into stm8-gdb gives

>c:\Users\Max\.platformio\packages\tool-stm8binutils\bin\stm8-gdb.exe .pio\build\stm8sblue\firmware.elf
..
Reading symbols from .pio\build\stm8sblue\firmware.elf...
Dwarf Error: Could not find abbrev number 117 in CU at offset 0x0 [in module C:\Users\Max\.platformio\platforms\ststm8\examples\spl-blink\.pio\build\stm8sblue\firmware.elf]
(no debugging symbols found)...done.

Now I just re-execute the linker command but with main.rel first.

C:\Users\Max\.platformio\packages\toolchain-sdcc\bin\sdcc -o .pio\build\stm8sblue\firmware.elf -mstm8 --nostdlib --code-size 8192 --iram-size 1024 --out-fmt-elf .pio\build\stm8sblue\src\main.rel .pio\build\stm8sblue\SPL\stm8s_gpio.rel .pio\build\stm8sblue\src\stm8s_it.rel -LC:\Users\Max.platformio\packages\toolchain-sdcc\lib\stm8 -lstm8

And then feed it into stm8-gdb again, but I still get the same error per above, just at a different offset

Reading symbols from .pio\build\stm8sblue\firmware.elf…Dwarf Error: Could not find abbrev number 117 in CU at offset 0xfe [in module C:\Users\Max.platformio\platforms\ststm8\examples\spl-blink.pio\build\stm8sblue\firmware.elf]

(0xfe instead if of 0x0).

If I do main.rel stm8s_it.rel stm8s_gpio.rel I get offset 0x402, but it never goes away.

Your project maybe just has two active files and not 3?

brett_anderson · May 12, 2021, 5:34pm

I’m on Windows, what are you on? Also, I’m running some tests using my makefile project vs pio.

I’m putting together the documentation. It will take me a bit to get it all sorted out. As best as I can tell, cliff notes version:

If I uncomment a .h file in stm8_conf.h, I will get the DWARF error. It also puts these first in the compile and link order.
If I add the same files to source and include manually, and comment them out in stm8_conf.h, I do NOT get the DWARF error. It also puts main.c/rel first in the compile and link order.

I’m running tests using my makefile project where I compile all the files manually. I played with the order of the files, and I can find no difference in this. I never get the DWARF errors. I did realize that Eclipse was using arm-non-eabi-gdb. This likely caused my errors I had before. I tested my *.elf files using stm8-gdb.

To test similar to me, add the files into the source folders instead of letting them get loaded via stm8s_conf.h. Let me know if you see the same results I do. That is the only real change. I also have manually added stm8s_it.c to source, and stm8s_it.c to include. I have tested this to success and fail with stm8s_tim1.c/h, and stm8s_clk.c/h. If loaded via conf, fail. If added manually to source list, pass.

Last 2 tries with stm8s_clk.c/h. First from conf include, second manual include:

C:\Users\branderson\OneDrive - Trek Bicycle Corporation\Documents\PlatformIO\Projects\TestDemo.pio\build\stm8s003f3>C:\Users\branderson.platformio\packages\tool-stm8binutils\bin\stm8-gdb.exe firmware.elf
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “–host=x86_64-w64-mingw32 --target=stm8-none-elf32”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:

Find the GDB manual and other documentation resources online at:

For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from firmware.elf…Dwarf Error: Could not find abbrev number 110 in CU at offset 0x0 [in module C:\Users\branderson\OneDrive - Trek Bicycle Corporation\Documents\PlatformIO\Projects\TestDemo.pio\build\stm8s003f3\firmware.elf]
(no debugging symbols found)…done.
(gdb) q

C:\Users\branderson\OneDrive - Trek Bicycle Corporation\Documents\PlatformIO\Projects\TestDemo.pio\build\stm8s003f3>C:\Users\branderson.platformio\packages\tool-stm8binutils\bin\stm8-gdb.exe firmware.elf
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “–host=x86_64-w64-mingw32 --target=stm8-none-elf32”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:

Find the GDB manual and other documentation resources online at:

For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from firmware.elf…done.
(gdb) q

list of files compiled for last successful test.

Building in debug mode
sdcc -o .pio\build\stm8s003f3\src\main.rel -c -mstm8 --debug --out-fmt-elf --opt-code-size -DF_CPU=16000000L -DPLATFORMIO=50101 -DSTM8S_003 -DSTM8S003 -DUSE_STDPERIPH_DRIVER -DUSE_STDINT -D__PLATFORMIO_BUILD_DEBUG__ -Iinclude -Isrc -IC:\Users\branderson.platformio\packages\framework-ststm8spl\Libraries\STM8S_StdPeriph_Driver\inc -Isrc src\main.c
sdcc -o .pio\build\stm8s003f3\src\stm8s_clk.rel -c -mstm8 --debug --out-fmt-elf --opt-code-size -DF_CPU=16000000L -DPLATFORMIO=50101 -DSTM8S_003 -DSTM8S003 -DUSE_STDPERIPH_DRIVER -DUSE_STDINT -D__PLATFORMIO_BUILD_DEBUG__ -Iinclude -Isrc -IC:\Users\branderson.platformio\packages\framework-ststm8spl\Libraries\STM8S_StdPeriph_Driver\inc -Isrc src\stm8s_clk.c
sdcc -o .pio\build\stm8s003f3\src\stm8s_gpio.rel -c -mstm8 --debug --out-fmt-elf --opt-code-size -DF_CPU=16000000L -DPLATFORMIO=50101 -DSTM8S_003 -DSTM8S003 -DUSE_STDPERIPH_DRIVER -DUSE_STDINT -D__PLATFORMIO_BUILD_DEBUG__ -Iinclude -Isrc -IC:\Users\branderson.platformio\packages\framework-ststm8spl\Libraries\STM8S_StdPeriph_Driver\inc -Isrc src\stm8s_gpio.c
sdcc -o .pio\build\stm8s003f3\src\stm8s_it.rel -c -mstm8 --debug --out-fmt-elf --opt-code-size -DF_CPU=16000000L -DPLATFORMIO=50101 -DSTM8S_003 -DSTM8S003 -DUSE_STDPERIPH_DRIVER -DUSE_STDINT -D__PLATFORMIO_BUILD_DEBUG__ -Iinclude -Isrc -IC:\Users\branderson.platformio\packages\framework-ststm8spl\Libraries\STM8S_StdPeriph_Driver\inc -Isrc src\stm8s_it.c
sdcc -o .pio\build\stm8s003f3\src\stm8s_tim1.rel -c -mstm8 --debug --out-fmt-elf --opt-code-size -DF_CPU=16000000L -DPLATFORMIO=50101 -DSTM8S_003 -DSTM8S003 -DUSE_STDPERIPH_DRIVER -DUSE_STDINT -D__PLATFORMIO_BUILD_DEBUG__ -Iinclude -Isrc -IC:\Users\branderson.platformio\packages\framework-ststm8spl\Libraries\STM8S_StdPeriph_Driver\inc -Isrc src\stm8s_tim1.c
sdcc -o .pio\build\stm8s003f3\firmware.elf -mstm8 --nostdlib --code-size 8192 --iram-size 1024 --out-fmt-elf .pio\build\stm8s003f3\src\main.rel .pio\build\stm8s003f3\src\stm8s_clk.rel .pio\build\stm8s003f3\src\stm8s_gpio.rel .pio\build\stm8s003f3\src\stm8s_it.rel .pio\build\stm8s003f3\src\stm8s_tim1.rel -LC:\Users\branderson.platformio\packages\toolchain-sdcc\lib\stm8 -lstm8

I am seeing an issue debugging where it will pause at main, but then timeout. gdb says I can increase the timeout. I am able to pause and step with symbols though.

I’ll keep digging.

brett_anderson · May 18, 2021, 1:37pm

So, just a quick update. I think I have this working fine. Unfortunately, it is a moot issue. SDCC does not remove dead code, so as soon as you pull in a file from the SPL, your code size balloons. I started moving one of our IAR projects over, and the code size isn’t even close to fitting. Like, 30k too large.

Looking into that issue, it appears that it is a known thing about SDCC. Someone made a port for 3.9 that adds the ability, but I’m not comfortable moving my company’s projects to a custom port.

If you guys want me to continue to look into what is causing the underlying debug issue instead of just a work-around, I’m more than happy to donate some time to support the cause. Until SDCC adds dead code removal, it just doesn’t work for what we need.