Add two Nucleo boards, GDB debugging and SVD files for all boards

maxgerhardt commented 3 years ago

This superseedes my PR #37.

See explanations in PR#37 why certain things were done to support and flash the new boards.

To get debugging working, I fixed a few things, restructured a bit and added a bit of code:

OpenOCD information for target .cfg file is placed in the board manifest as openocd_target as with other platforms (e.g. stm32)
Building in built_type = debug mode was broken because SDCC was given the default debug_build_flags with -Og -g2 etc., which it does not understand. Thanks to research in #31, the right flags were found, --debug --out-fmt-elf
However, this broke the .ihx build output file in debug mode because when converting it with SDCC to hex it also dumps the debug information in there, at address 0x0000, which crashes the uploader program and makes no sense at all. The ELF file is fine however, so I used stm8-objcopy to convert the ELF to IHX (while removing the wrong sections).
The SVD files come from @gicking at https://github.com/gicking/STM8_headers. The SVD files are flawless and pass all checks by the SVDConv tool in the CMSIS toolset. All peripheral info can thus be displayed
PR was tested against the STM8S-Discovery board, the Nucleo-8S208RB board and a STM8S103F3, with the ST-Link V2.1 and V2 debug probes respectively
A good bare-metal test project for debugging: https://github.com/maxgerhardt/stm8-headers-pio

This brings debugging from nothing for most boards to full debugging support for all boards with peripheral view thanks to SVD files!

step_2_init_breakpoint_hit

step_3_custom_breakpoint_hit

Closes #33, #34 and #31.

valeros commented 3 years ago

Many thanks, looks promising! Please see my comments in review.

maxgerhardt commented 3 years ago

I'll address the comments tomorrow and also fix a still wrongly built .ihx file, since I just got a report saying that in some cases it still includes bytes at address 0x0001 which don't belong there -- more infos pending hopefully :)

maxgerhardt commented 3 years ago

I've addressed the review comments and also fixed a bug in the Intel Hex file generation logic which previously prevented an upload as soon as a global variable was being created.

valeros commented 3 years ago

Thanks for the fixes! BTW, that new hex file generation logic works fine with the Arduino framework, right?

maxgerhardt commented 3 years ago

that new hex file generation logic works fine with the Arduino framework, right?

I can confirm that it does in normal release build mode. I've forked an Arduino project that plays the Tetris theme on a buzzer at https://github.com/maxgerhardt/TetrisThemeArduino, and it works with the my new platform perfectly. I've tested it on my STM8S103F3 board (stm8sblue).

However, debugging the Arduino framework code is currently not possible because of one freaking file failing compilation in --debug mode: WInterrupts.c. I've filed a bug at https://sourceforge.net/p/sdcc/bugs/3199/. Would be nice to get that resolved before release.

valeros commented 3 years ago

Many thanks for such a great contribution! I'm working on updates for SDCC and Sduino in a separate branch, so it will be a great release!

maxgerhardt commented 3 years ago

Awesome! Might also consider merging PR #28 for a STM8S003 chip and add the few extra items for debug support there? :)

valeros commented 3 years ago

I've just merged my branch into dev and also added minor changes to your previous code, would be great if you could take a look. Unfortunately, I don't have any ST8-based board at hand so it would be really great if you could test the latest revision (compiling, uploading, debugging).

maxgerhardt commented 3 years ago

I've built my stm8-headers-pio project from the PR decsription with the latest dev platform; it updated some packages, then compiled and uploaded just fine. Also works (blinks LED).

Processing stm8sblue_stm8s103f3 (platform: https://github.com/platformio/platform-ststm8.git; board: stm8sblue)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Tool Manager: Installing platformio/tool-stm8gal @ ~1.5.0
Tool Manager: tool-stm8gal @ 1.5.0 has been installed!
Tool Manager: Installing platformio/tool-stm8flash @ ~1.1.0
Tool Manager: tool-stm8flash @ 1.1.20170616 has been installed!
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm8/stm8sblue.html
PLATFORM: ST STM8 (1.0.3+sha.dbba972) > ST STM8S103F3 Breakout Board
HARDWARE: STM8S103F3P6 16MHz, 1KB RAM, 8KB Flash
DEBUG: Current (stlink) External (stlink)
PACKAGES:
 - tool-openocd 2.1000.200630 (10.0)
 - tool-stm8binutils 0.230.0 (2.30)
 - tool-stm8flash 1.1.20170616
 - tool-stm8gal 1.5.0
 - 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 1 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <STM8_headers> 0.0.1
Building in release mode
Compiling .pio\build\stm8sblue_stm8s103f3\src\main.rel
Archiving .pio\build\stm8sblue_stm8s103f3\libc36\libSTM8_headers.lib
Indexing .pio\build\stm8sblue_stm8s103f3\libc36\libSTM8_headers.lib
src\main.c:73:4: warning: #warning "[INFO] USING STM8S103F3 PINMAP PORTB, PIN 5"
Linking .pio\build\stm8sblue_stm8s103f3\firmware.elf
Checking size .pio\build\stm8sblue_stm8s103f3\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.5% (used 5 bytes from 1024 bytes)
Flash: [          ]   1.4% (used 115 bytes from 8192 bytes)
Building .pio\build\stm8sblue_stm8s103f3\firmware.hex
Configuring upload protocol...
AVAILABLE: serial, stlinkv2
CURRENT: upload_protocol = stlinkv2
Uploading .pio\build\stm8sblue_stm8s103f3\firmware.hex
Determine FLASH area

libusb: error [init_device] device '\\.\USB#VID_062A&PID_5918&MI_01#9&1953ACC1&0&0001' is no longer connected!
Due to its file extension (or lack thereof), ".pio\build\stm8sblue_stm8s103f3\firmware.hex" is considered as INTEL HEX format!
115 bytes at 0x8000... OK
Bytes written: 115
=============== [SUCCESS] Took 4.84 seconds ===============

However, debugging broke. There doesn't seem to be any debug information in the ELF file anymore, also it doesn't halt at the initial breakpoint anymore (main) because it can't figure out the address of it.

grafik

~~Using Verbose Build I can see that the final sdcc invocation that creates the ELF file doesn't have the --debug flag anymore.~~ My platform also didn't do that, so the cause might be somewhere else. I'll compare flags.

sdcc -o .pio\build\stm8sblue_stm8s103f3\src\main.rel -c -mstm8 --debug -DF_CPU=16000000L -DPLATFORMIO=50101 -DSTM8S_BLUE -DSTM8S103 -D__PLATFORMIO_BUILD_DEBUG__ -Iinclude -Isrc -Ilib\STM8_headers -Ilib\STM8_headers\include src\main.c
sdar rcs .pio\build\stm8sblue_stm8s103f3\libc36\libSTM8_headers.lib
sdranlib .pio\build\stm8sblue_stm8s103f3\libc36\libSTM8_headers.lib
src\main.c:73:4: warning: #warning "[INFO] USING STM8S103F3 PINMAP PORTB, PIN 5"
sdcc -o .pio\build\stm8sblue_stm8s103f3\firmware.elf -mstm8 --nostdlib --code-size 8192 --iram-size 1024 --out-fmt-elf .pio\build\stm8sblue_stm8s103f3\src\main.rel -LC:\Users\Max\.platformio\packages\toolchain-sdcc\lib\stm8 .pio\build\stm8sblue_stm8s103f3\libc36\libSTM8_headers.lib -lstm8

maxgerhardt commented 3 years ago

Ah, I think I figured out the cause. The --out-fmt-elf flag is missing in this platform code. This must be there for DWARF formatted debug info per #31.

My platform:

sdcc -o .pio\build\stm8sblue_stm8s103f3\src\main.rel -c -mstm8 --debug --out-fmt-elf -DF_CPU=16000000L -DPLATFORMIO=50101 -DSTM8S_BLUE -DSTM8S103 -DPLATFORMIO_BUILD_DEBUG -Iinclude -Isrc -Ilib\STM8_headers -Ilib\STM8_headers\include src\main.c

Yours:

sdcc -o .pio\build\stm8sblue_stm8s103f3\src\main.rel -c -mstm8 --debug -DF_CPU=16000000L -DPLATFORMIO=50101 -DSTM8S_BLUE -DSTM8S103 -DPLATFORMIO_BUILD_DEBUG -Iinclude -Isrc -Ilib\STM8_headers -Ilib\STM8_headers\include src\main.cx

You removed it in https://github.com/platformio/platform-ststm8/commit/e16be5294ef4437894052714c22f081318b3af54

If I add build_flags = --out-fmt-elf again with your platform it works again :)

valeros commented 3 years ago

That's interesting. IIRC, the --out-fmt-elf flag only makes sense for the linker:

--out-fmt-ihx - The linker output (final object code) is in Intel Hex format. This is the default option. The format
itself is documented in the documentation of srecord.

But if it's helps to produce a proper binary for debugging, let's then add it to CFLAGS as well. Please retest with the latest revision.

maxgerhardt commented 3 years ago

Seems to be not well documented, but per https://sourceforge.net/p/sdcc/discussion/1864/thread/aa45ea7ea2/#fad2/429a

gdb expects debug info in DWARF format. AFAIK, SDCC generates CDB on --debug without --out-fmt-elf, DWARF on --debug --out-fmt-elf, so you'll need to add --out-fmt-elf to the compilation command line.

The comment below says

Since the SDCC 4.1.0 release is very close, it is too late for that. But I've just documented it in the manual in the sdcc-next branch, which will be merged after the release.

maxgerhardt commented 3 years ago

With the latest commit, debugging functionality is restored again with no extra flags needed.

grafik

But, the updated Arduino core does not run anymore on my STM8S103F3 board. It simply outputs nothing (refer Tetris example above), like it doesn't even reach setup() or loop().

If I roll back just the Arduino core version but still use the latest platform version, it works again

platform_packages =
        framework-arduinoststm8@~0.40.0

Compile output from 0.40.0 Arduino core:

RAM:   [=         ]   7.2% (used 74 bytes from 1024 bytes)
Flash: [======    ]  62.2% (used 5099 bytes from 8192 bytes)

section       size    addr

DATA            52       1
INITIALIZED     22      53
HOME           107   32768
GSINIT          26   32875
GSFINAL          3   32901
CONST         1588   32904
INITIALIZER     22   34492
CODE          4941   34514
SSEG             1   39455
Total         6762

from new 0.50.0 core:

RAM:   [          ]   1.3% (used 13 bytes from 1024 bytes)
Flash: [====      ]  42.1% (used 3446 bytes from 8192 bytes)

section       size    addr
DATA             9       1
INITIALIZED      4      10
CONST         1606   32768
INITIALIZER      4   34374
CODE          3442   34378
Total         5065

The size decreased quite a bit, but maybe something important was removed? I'll see what I can find out that makes this non-working..

maxgerhardt commented 3 years ago

Hm, it works out of the box when installing the 0.5.0 core in the Arduino IDE (https://github.com/tenbaht/sduino#installation) and using the same Tetris code. I'll see what the differences during build are.

In the Arduino IDE, the build size is

Sketch uses 4721 Bytes (57%) of program memory. Maximum is 8192 Bytes.
Global variables use 76 Bytes (7%) of the dynamic memory. 948 Bytess for local variablen remain. Maximum is 1024 Bytes.

But the build there also uses SDCC 3.9.1 #11242 (MINGW32).

maxgerhardt commented 3 years ago

This is pretty absurd. Adding a Serial_begin(115200); in the setup() makes the firmware work again with PlatformIO and all latest version (0.5.0 Arduino core, SDCC 4.1.0, latest dev platform). The firmware.map file shows some differences in linked functions, maybe something crucial got optimized away.

valeros commented 3 years ago

Any better if you downgrade the toolchain?

maxgerhardt commented 3 years ago

Downgrading to 3.8.4 (1.30804.10766) did not work.

But if I use the exact toolchain that SDCC does, 3.9.1 (which isn't even listed in https://sourceforge.net/projects/sdcc/files/sdcc-win64/ so I had to pull it from C:\Users\Max\AppData\Local\Arduino15\packages\sduino\tools\sdcc\build.11242), I first get a linker error

ASlink-Warning-No definition of area SSEG
*** [.pio\build\stm8sblue\firmware.elf] Error 1

which is resolved by the two lines of code found in https://github.com/tenbaht/sduino/issues/76#issuecomment-708592340.

Then it compiles, uploads and runs correctly.

So for some magical reason, that exact SDCC version has to be used and that dummy variable trick. If I read https://github.com/tenbaht/sduino/commit/c7ebb07c1ef1b659495cb59c59028a59b75626ac correctly that's also what they do with

echo "void main(void); void (*dummy_variable) () = main;"; \

I'll retry with SDCC 4.0 though.

maxgerhardt commented 3 years ago

A SDCC 4.0 downloaded straight from https://sourceforge.net/projects/sdcc/files/sdcc-win64/4.0.0/ works too but also needs the dummy_variable workaround. Have not gotten it to work with SDCC 4.1 (with or without dummy_variable).

So I guess it's best to use either SDCC 4.0 or their exact SDCC 3.9.1 with that dummy variable inclusion, and open an issue in SDCC on why SDCC 4.1 won't make it work correctly?

I've looked in to the .map files and optimization in SDCC 4.1 is really aggressive, with most of the unused interrupts and functions removed. Still, SDCC 4.1 does retain the timer 4 overflow interrupt and millis() and everything, so it should work, if that's the correct timer..

If only I could debugging with the Arduino framework to work, then I could look where the chip is stuck..

valeros commented 3 years ago

Thanks for the help, let's stick to that SDCC 3.9.1 at least for Sduino.

valeros commented 3 years ago

Arduino is now switched to SDCC v3.9.1. I also added a hacky workaround to avoid the ASlink-Warning-No definition of area SSEG error. Would be great if you could retest. Thanks!

maxgerhardt commented 3 years ago

Just tested with standard platformio.ini+ dev platform + removed my own dummy_variable definition. Compiles, uploads and works, the Tetris tune plays again.

>pio run
Processing stm8sblue (platform: https://github.com/platformio/platform-ststm8.git; board: stm8sblue; framework: arduino)
------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm8/stm8sblue.html
PLATFORM: ST STM8 (1.0.3+sha.acb8a45) > ST STM8S103F3 Breakout Board
HARDWARE: STM8S103F3P6 16MHz, 1KB RAM, 8KB Flash
PACKAGES:
 - framework-arduinoststm8 0.50.210317
 - tool-stm8binutils 0.230.0 (2.30)
 - toolchain-sdcc 1.30901.11242 (3.9.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 12 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Compiling .pio\build\stm8sblue\src\TetrisThemeArduino.c.rel
Linking .pio\build\stm8sblue\firmware.elf
Checking size .pio\build\stm8sblue\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]   7.4% (used 76 bytes from 1024 bytes)
Flash: [======    ]  57.6% (used 4721 bytes from 8192 bytes)
Building .pio\build\stm8sblue\firmware.hex
================ [SUCCESS] Took 2.04 seconds ================

The firmware size now also is 100% equal to what the Arduino IDE outputs per https://github.com/platformio/platform-ststm8/pull/38#issuecomment-804290563.

So, all works normally in release mode :)

The debugging issue with WInterrupts.c is also present in SDCC 3.9.1, but as above, I've filed a bug for that already.

Still sad that the 0.50 core can't be compiled to a working firmware with SDCC 4.1 but 0.40 could. I'll open a separate issue in sduino for that (or SDCC if that's the culprit).

maxgerhardt commented 3 years ago

Slightly off-topic, but with https://github.com/platformio/platformio-core/issues/3872 resolved this would make an even better release / less frustration and weirdness for more users 😄

maxgerhardt commented 3 years ago

Oh, but debugging has broken again. Pressing the debug button VSCode results in a short loading time, then the debug buttons disappear. I'll check if that change did that.

maxgerhardt commented 3 years ago

Yes 100%. Commenting out

https://github.com/platformio/platform-ststm8/blob/acb8a45d50b21f39f67e79040db063d3038048fd/platform.py#L46-L47

makes debugging working again with my pio-stm8-headers example from the PR description.

The platformio.ini of that is

[env:stm8sblue_stm8s103f3]
platform = https://github.com/platformio/platform-ststm8.git
upload_protocol = stlinkv2
board = stm8sblue

Maybe has something to do with that upload_protocol can be

-c programmer Specify programmer used (stlink, stlinkv2, stlinkv21 or stlinkv3)

(for stm8flash, and PIO forwards it) and that isn't handled correctly with that continue logic?

valeros commented 3 years ago

Thanks, I see now. Removed that lines.

maxgerhardt commented 3 years ago

Retested with latest commit and now debugging is working again, Arduino sketch works as before.

platformio / platform-ststm8

Add two Nucleo boards, GDB debugging and SVD files for all boards #38