STM8 support

[spth]

The FAQ mentions some advantages the BMP has over the ST-LINK. However, the ST-LINK supports not only STM32, but also STM8. How about STM8 support for the BMP?

Philipp

[UweBonnes]

Device supports requires open debug/flash programming information for that device and somebody with that device to implement it. You are open to provide patches, but chances are low that anybody here has STM8 devices and is willing to provide patches.

[spth]

There already is some free software for the STM8 using ST-LINK: Debugging via openocd and flashing via stm8flash.

Philipp

[UweBonnes]

The stlink has already some ST8 algorithms on board. Openocd can call these functions. BMP replaces the stlink software, so this functionality must be reumplemented...

[spth]

I see. Fortunately, it seems like documentation is available:

www.st.com/resource/en/user_manual/cd00173911.pdf

Philipp

[UweBonnes]

There is no SWIM implementation in BMP yet. So with the help of the docs you can implement it :-)

[spth]

My goal here is a fully free toolchain for STM8 development. Towards this goal, most of my work is on SDCC, but I have contributed to other tools along the toolchain (stm8flash, stm8gal, Code:Blocks).

My current focus is on improving the compilation time / code quality trade-off in SDCC and on improving support for on-target debugging. Next I would work on the calling convention and on a modular printf() to improve code size (the last remaining major weakness of SDCC vs. non-free compilers when targeting the STM8). Currently, I don't have a BMP, but I'll get one next year. I probably won't find time to work on SWIM support in the BMP before March.

Philipp

[UweBonnes]

Thumbs up for your work on SDCC :-)

B.t.w. you probably already have a STM8 board capable to get modified to BMP. E.g. the STM8SVLDISCOVERY can easyly be modified, as access to the F103 by JTAG?SWD can be made by CN5

[spth]

See also: https://community.st.com/thread/44550-the-missing-piece-for-a-fully-free-toolchain-st-link-firmware

Philipp

[gsmcmullin]

Until there is a GDB target for STM8, STM8 support in BMP doesn't really make sense.

[spth]

The GDB target is not upstream yet, but is has been written: https://stm8-binutils-gdb.sourceforge.io/ Even without GDB support, it could be possible to use the BMP as an ST-LINK substitute for stm8flash.

Philipp

[UweBonnes]

Flashing happens through gdb commands, so I think the gdb target is needed anyhow.

[gsmcmullin]

I'll leave the issue open. If the STM8 support can be merged in upstream GDB, I'd be happy to merge SWIM/STM8 support here. Programming could be done without GDB, for example with this script: https://github.com/blacksphere/blackmagic/blob/master/scripts/hexprog.py, but I'm not really interested in keeping making a dumb programmer.

[fabalthazar]

STM8 GDB target isn't upstream yet but is seriously taken as reference. Here in the popular PlatformIO dev environment: https://docs.platformio.org/en/latest/platforms/ststm8.html#packages In the event that a developer finds the time to prototype a SWIM implementation, are there any chances for it to interest somebody (other than me) and be merged into BMP? Or is it seen as too old-fashioned...?

[UweBonnes]

ST8 is interesting, as is RiscV, ESP32, AVR and FPGA targets. The STM8 protocol is timing driven. To implement in a safe way, the hardware needs to provide access to on-chip resources, probably UART. Native probably does not provide, only stlink per se does. Best way to start would be to extend BMP/stlink where on can compare easy against the ST tool. Perhaps baite is usefull too. If there is a PR, I will consider. Hosted has ample space, firmware however may soon run out of space with 124 kiB.

[esden]

ST8 is pretty old. And I don't feel like we should be adding support for it. Unless someone is really motivated to implement good clean support for it. For the sake of keeping the issue list short, i am closing this.