Got STM8 boards
I bought a set of three small STM8 boards and a programmer off eBay.
I built the stm8flash util and the STM8 examples repo to test stuff with.
$ make
cc -g -O0 --std=gnu99 --pedantic `pkg-config --cflags libusb-1.0` -c -o stlink.o stlink.c
cc -g -O0 --std=gnu99 --pedantic `pkg-config --cflags libusb-1.0` -c -o stlinkv2.o stlinkv2.c
cc -g -O0 --std=gnu99 --pedantic `pkg-config --cflags libusb-1.0` -c -o main.o main.c
cc -g -O0 --std=gnu99 --pedantic `pkg-config --cflags libusb-1.0` -c -o byte_utils.o byte_utils.c
cc -g -O0 --std=gnu99 --pedantic `pkg-config --cflags libusb-1.0` -c -o ihex.o ihex.c
cc -g -O0 --std=gnu99 --pedantic `pkg-config --cflags libusb-1.0` -c -o stm8.o stm8.c
cc -g -O0 --std=gnu99 --pedantic `pkg-config --cflags libusb-1.0` stlink.o stlinkv2.o main.o byte_utils.o ihex.o stm8.o `pkg-config --libs libusb-1.0` -o stm8flash
$ ./stm8flash
Usage: ./stm8flash [-c programmer] [-p partno] [-s memtype] [-b bytes] [-r|-w|-v] <filename>
Options:
-? Display this help
-c programmer Specify programmer used (stlink or stlinkv2)
-p partno Specify STM8 device
-l List supported STM8 devices
-s memtype Specify memory type (flash, eeprom, ram, opt or explicit address)
-b bytes Specify number of bytes
-r <filename> Read data from device to file
-w <filename> Write data from file to device
-v <filename> Verify data in device against file
-u Unlock. Reset option bytes to factory default to remove write protection.
I plugged the four wires as marked: GND
, 3V3
, SWIM
, RST
from the
programmer to the board.
$ ./stm8flash -c stlinkv2 -p stm8s103f3 -r test.out
Determine FLASH area
Reading 8192 bytes at 0x8000... OK
Bytes received: 8192
The file is entirely made up of null bytes. This is a bit strange as flash should reset to all 1 bits.
$ cd ..
$ git clone https://github.com/vdudouyt/sdcc-examples-stm8.git
Cloning into 'sdcc-examples-stm8'...
remote: Counting objects: 27, done.
remote: Total 27 (delta 0), reused 0 (delta 0), pack-reused 27
Unpacking objects: 100% (27/27), done.
Checking connectivity... done.
blades@bastet:/mnt/build$ cd sdcc-examples-stm8
blades@bastet:/mnt/build/sdcc-examples-stm8$ ls
blinky.c Makefile README.md stm8l.h uart.c
$ cat Makefile
SDCC=sdcc
SDLD=sdld
OBJECTS=blinky.ihx uart.ihx sp_test.ihx
.PHONY: all clean flash
all: $(OBJECTS)
clean:
rm -f $(OBJECTS)
flash: $(OBJECT).ihx
stm8flash -cstlink -pstm8l150 -w $(OBJECT).ihx
%.ihx: %.c
$(SDCC) -lstm8 -mstm8 --out-fmt-ihx $(CFLAGS) $(LDFLAGS) $<
$ make
sdcc -lstm8 -mstm8 --out-fmt-ihx blinky.c
sdcc -lstm8 -mstm8 --out-fmt-ihx uart.c
make: *** No rule to make target 'sp_test.ihx', needed by 'all'. Stop.
Bit of a bug there, but two out of three binaries came out. I commented out the missing target in case I run again.
$ ../stm8flash/stm8flash -c stlinkv2 -p stm8s103f3 -w blinky.ihx
Determine FLASH area
Writing Intel hex file 194 bytes at 0x8000... OK
Bytes written: 194
$ ../stm8flash/stm8flash -c stlinkv2 -p stm8s103f3 -r test.hex
Determine FLASH area
Reading 8192 bytes at 0x8000... Reading from Intel hex file OK
Bytes received: 8192
Another little typo in the output.
The filename is used to detect the format (see main.c
).
Comparing the output, there is certainly new data in there and it seems
to match a lot of the hex file sent.
If I was curious, I could walk through those lines sometime and see if
they make sense.
And yes, the read is still mostly zeroes and not 0xFF
.
Is it blinking? I don't know.
Reading some more, apparently the LED on these is in PB5
and that's
0x20
in the registers.
I changed the code to blink that pin and rebuilt and reflashed.
$ vim blinky.c
$ make
sdcc -lstm8 -mstm8 --out-fmt-ihx blinky.c
$ ../stm8flash/stm8flash -c stlinkv2 -p stm8s103f3 -w blinky.ihx
Determine FLASH area
Writing Intel hex file 194 bytes at 0x8000... OK
Bytes written: 194
And it blinks. Hooray! That may have been the most painless and uneventful new microcontroller toolchain setup ever.
Plans
The systemd journal has something to say about this on each run:
kernel: usb 3-1.2: usbfs: process 7331 (stm8flash) did not claim interface 0 before use
I don't know what should be done, but I guess there might be room for a patch there as well. Maybe I'll look into it.
- Make something that works
- Test the stlink with stm32, openocd, stlink, ...