I was looking through the code and noticed some writes to hardware registers
that I can't match up to the ST documents. I've given the registers and the
code lines that seem a little off to me and the reason why.

It doesn't seem like these are causing any real issues, but I thought I would
document what I see.

SWIM_CSR (0x7f80)
        bit7    SAFE_MASK (rw)
        bit6    NO_ACCESS (ro)
        bit5    SWIM_DM   (rw)
        bit4    HS        (rw)
        bit3    OSCOFF    (rw)
        bit2    RST       (rw)
        bit1    HSIT      (ro)
        bit0    PRI       (rw)

in stlink2_init_session()
        // I think this is just a mistake in the comment, 0xa0 seems
        // like the correct value to write (setting SAFE_MASK and SWIM_DM)
        stlink2_write_byte(pgm, 0xa0, 0x7f80); // mov 0x0a, SWIM_CSR2 ;; Init SWIM

at the end of stlinkv2_swim_write_range()
        // This one may be ok, but it seems odd that we would be switching to HS mode
        // and setting the HSIT bit which is read only
        stlink2_write_byte(pgm, 0xb6, 0x7f80);

DM_CSR2 (0x7f99)
        bit7    Reserved Must be kept 0
        bit6    Reserved Must be kept 0
        bit5    SWBKE (rw)
        bit4    SWBKF (ro)
        bit3    STALL (rw)
        bit2    Reserved Must be kept 0
        bit1    Reserved Must be kept 0
        bit0    FLUSH (set by sw, cleared by hw)

in stlink2_init_session()
        // This would seem ok if it were 0x20, but it has a reserved bit set
        stlink2_write_and_read_byte(pgm, 0xa0, 0x7f99);

FLASH_IAPSR
        bit7    Reserved
        bit6    HVOFF  (readonly)
        bit5    Reserved, forced by hardware to 0
        bit4    Reserved, forced by hardware to 0
        bit3    DUL  (set by hw, write to 0 to clear)
        bit2    EOP  (read to clear)
        bit1    PUL  (set by hw, write to 0 to clear)
        bit0    WR_PG_DIS (read to clear)

in stlink2_wait_until_transfer_completes()
        // This seems odd, in that it it sets a reserved bit, and it clears DUL (locks eeprom memory)
        // and writes a 1 to a bit that can only be set by unlocking the flash area, however the value
        // is being tested against the EOP bit, so the read part seems ok.
        TRY(8, stlink2_write_and_read_byte(pgm, 0x82, device->regs.FLASH_IAPSR) & 0x4);

in stlink2_swim_write_range()
        // Another strange value to right, sets a read only bit and reserved bit in the upper nibble
        // and sets EOP and PUL, reading will clear EOP and WR_PG_DIS if they are set.
        stlink2_write_and_read_byte(pgm, 0x56, device->regs.FLASH_IAPSR); // mov 0x56, FLASH_IAPSR

Hi,
I have been trying to program multiple boards connected to single pc. I tried to use an additional argument iSerialNumber of the device to distinguish between multiple programmers. But when I run your flash code , the iserial number of the programmer seem to get corrupted after one attempt and I am unable to use that for the next time(I have to plug out the device and plug in again to get correct serial number). If I just try to open and close the usb port using libusb , the number doesn't get corrupted. Does your code access device config parameters somewhere ? or changes it somewhere while writing into STM flash ? Kindly help

I’m not sure exactly how though. But this seems to already have been spotted in #14
Verify for binary files works.

Determine FLASH area
stm8flash: stlink.c:162: stlink_send_cbw: Assertion `actual == USB_CBW_SIZE' failed.
Aborted (core dumped)

I can't compare [use diff] writed and readed image by reason I get same result after following command:

$ stm8flash -cstlinkv2 -pstm8s103 -r main.ihx
$ stm8flash -cstlinkv2 -pstm8s103 -r main.bin

the same binary file as output. For burning I use HEX fileformat.

How does work option -v? Unfortunately, my verification procedure by using stm8flash always fail.

The README.md states "This is a free and opensource software distributed under the terms of GNU General Public License v2."

I suggest to change the license to GPLv2 or later, i.e. change the text to ""This is a free and opensource software distributed under the terms of GNU General Public License; either version 2 of the License, or (at your option) any later version."

This would be a license change, so all authors would have to agree.

However, I think it would be good to make this change, to allow combining stm8flash with software released under later GPL versions, should the need arise. It would be quite frustrating to not be able to do some things due to license issues, even when all involved software is GPL-licensed.

Philipp

I tried flashing the STM8L001J3 with binary contained in vdudouyt/stm8flash
3e034d3 (master, Dec 13, 2017). Flashing the device doesn't work for unknown reasons. I tried using the "-d slow" option to no avail. Setting the option bits, however, works. Note that the device doesn't have a NRST pin.

Note:
I had a look at the code (which doesn't compile for me), and found that stm8flash doesn't cluster technical information about STM8 variants into family and density. It simply uses the marketing name, and leaves QA to the user (the list in README.md).

Also note that I published information, derived from the STM8CubeMX db/mcu folder, on hypothetical common silicon properties in the Wiki of my fork of this repository.

Hi,

I tried flash over STLink v2 on Mac OS X, but get libusb error:

./stm8flash -c stlinkv2 -p stm8s103 -w /Users/MartianZ/Documents/STM8_INITIAL/x.inx
Determine FLASH area
libusb:info [process_new_device] allocating new device for location 0xfa000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8006-09-00
libusb:info [process_new_device] allocating new device for location 0xfd000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8006-09-00
libusb:info [process_new_device] allocating new device for location 0xfd100000
libusb:info [process_new_device] found device with address 2 at 002-0424-2513-09-00
libusb:info [process_new_device] allocating new device for location 0xfa100000
libusb:info [process_new_device] found device with address 2 at 002-0424-2513-09-00
libusb:info [process_new_device] allocating new device for location 0xfa110000
libusb:warning [process_new_device] could not retrieve device descriptor: device not responding. skipping device
libusb:info [process_new_device] allocating new device for location 0xfd120000
libusb:info [process_new_device] found device with address 4 at 004-0424-5534-09-00
libusb:info [process_new_device] allocating new device for location 0xfa130000
libusb:info [process_new_device] found device with address 6 at 006-0409-005a-09-00
libusb:info [process_new_device] allocating new device for location 0xfa200000
libusb:info [process_new_device] found device with address 3 at 003-05ac-8509-ef-02
libusb:info [process_new_device] allocating new device for location 0xfd110000
libusb:info [process_new_device] found device with address 3 at 003-05ac-8242-00-00
libusb:info [process_new_device] allocating new device for location 0xfa120000
libusb:info [process_new_device] found device with address 4 at 004-05ac-0245-00-00
libusb:info [process_new_device] allocating new device for location 0xfa113000
libusb:warning [process_new_device] could not retrieve device descriptor: pipe is stalled. skipping device
libusb:info [process_new_device] allocating new device for location 0xfa133000
libusb:info [process_new_device] found device with address 9 at 009-1532-0016-00-00
libusb:info [process_new_device] allocating new device for location 0xfa131000
libusb:info [process_new_device] found device with address 8 at 008-0853-0100-00-00
libusb:info [process_new_device] allocating new device for location 0xfd124000
libusb:info [process_new_device] found device with address 5 at 005-0483-3748-00-00
libusb:info [process_new_device] using existing device for location 0xfa000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8006-09-00
libusb:info [process_new_device] using existing device for location 0xfd000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8006-09-00
libusb:info [process_new_device] using existing device for location 0xfd100000
libusb:info [process_new_device] found device with address 2 at 002-0424-2513-09-00
libusb:info [process_new_device] using existing device for location 0xfa100000
libusb:info [process_new_device] found device with address 2 at 002-0424-2513-09-00
libusb:info [process_new_device] allocating new device for location 0xfa110000
libusb:warning [process_new_device] could not retrieve device descriptor: device not responding. skipping device
libusb:info [process_new_device] using existing device for location 0xfd120000
libusb:info [process_new_device] found device with address 4 at 004-0424-5534-09-00
libusb:info [process_new_device] using existing device for location 0xfa130000
libusb:info [process_new_device] found device with address 6 at 006-0409-005a-09-00
libusb:info [process_new_device] using existing device for location 0xfa200000
libusb:info [process_new_device] found device with address 3 at 003-05ac-8509-ef-02
libusb:info [process_new_device] using existing device for location 0xfd110000
libusb:info [process_new_device] found device with address 3 at 003-05ac-8242-00-00
libusb:info [process_new_device] using existing device for location 0xfa120000
libusb:info [process_new_device] found device with address 4 at 004-05ac-0245-00-00
libusb:info [process_new_device] allocating new device for location 0xfa113000
libusb:warning [process_new_device] could not retrieve device descriptor: pipe is stalled. skipping device
libusb:info [process_new_device] using existing device for location 0xfa133000
libusb:info [process_new_device] found device with address 9 at 009-1532-0016-00-00
libusb:info [process_new_device] using existing device for location 0xfa131000
libusb:info [process_new_device] found device with address 8 at 008-0853-0100-00-00
libusb:info [process_new_device] using existing device for location 0xfd124000
libusb:info [process_new_device] found device with address 5 at 005-0483-3748-00-00
libusb:info [darwin_open] device open for access
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:warning [ep_to_pipeRef] no pipeRef found with endpoint address 0x02.
libusb:error [submit_bulk_transfer] endpoint not found on any open interface
IO error: expected 16 bytes but 0 bytes transferred

I'm using OS X 10.9.4 and libusb 1.0.19 version.
any help would be appreciated

cc -g -O0 --std=gnu99 --pedantic `pkg-config --cflags libusb-1.0`    -c -o stlink.o stlink.c
Package libusb-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libusb-1.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libusb-1.0' found
In file included from stlink.c:17:0:
pgm.h:7:21: fatal error: libusb.h: Немає такого файла або каталогу
compilation terminated.
<вбудований>: спроба виконання рецепта для мети «stlink.o» зазнала невдачі
make: *** [stlink.o] Помилка 1

but libusb-1.0 really exists

I'm not filing this as a pull request because it wasn't code that I wrote, but @swegener has some useful commits on their master branch that improve code quality and may improve reliability. Filing this issue as a ping to all involved so a pull request might be filed and good work might not go un-noticed.

I try flash over stlink v2, but get 'Tries exceeded'.

$ ./stm8flash -cstlinkv2 -pstm8l150 -w ../blink/blinky.bin
TRACE: stlinkv2_open
TRACE: programmer stlinkv2
Writing at 0x8000... TRACE: stlink2_swim_write_range
TRACE: stlinkv2_init_session
TRACE: stlinkv2_wirte_byte a0 00007f80
TRACE: stlinkv2_write_and_read_byte a0 00007f99
TRACE: stlinkv2_wirte_byte 00 000050c6
TRACE: stlinkv2_write_and_read_byte 00 00005054
TRACE: stlinkv2_wirte_byte 56 00005052
TRACE: stlinkv2_wirte_byte ae 00005052
TRACE: stlinkv2_wirte_byte ae 00005053
TRACE: stlinkv2_wirte_byte 56 00005053
TRACE: stlinkv2_write_and_read_byte 56 00005054
TRACE: stlinkv2_wirte_word 01fe 00005051
TRACE: stlink2_wait_until_transfer_completes
TRACE: stlinkv2_write_and_read_byte 00 00005054
TRACE: stlinkv2_wirte_word 01fe 00005051
Tries exceeded

$ ./stm8flash -cstlinkv2 -pstm8s105 -w ../blink/blinky_s105.bin
TRACE: stlinkv2_open
TRACE: programmer stlinkv2
Writing at 0x8000... TRACE: stlink2_swim_write_range
TRACE: stlinkv2_init_session
TRACE: stlinkv2_wirte_byte a0 00007f80
TRACE: stlinkv2_write_and_read_byte a0 00007f99
TRACE: stlinkv2_wirte_byte 00 000050c6
TRACE: stlinkv2_write_and_read_byte 00 0000505f
TRACE: stlinkv2_wirte_byte 56 00005062
TRACE: stlinkv2_wirte_byte ae 00005062
TRACE: stlinkv2_wirte_byte ae 00005064
TRACE: stlinkv2_wirte_byte 56 00005064
TRACE: stlinkv2_write_and_read_byte 56 0000505f
TRACE: stlinkv2_wirte_word 01fe 0000505b
TRACE: stlink2_wait_until_transfer_completes
TRACE: stlinkv2_write_and_read_byte 00 0000505f
TRACE: stlinkv2_wirte_word 01fe 0000505b
Tries exceeded

It seems OK to me - doesn't display any FAILED message (though verification fails)

Hello,

I have problem with clearing ROP (Read-Out Ptotection) byte in STM8L150.
I have device with protected bytes set.
I trying to set this byte to 0xAA, then reset the device and again set ROP to 0xAA - according ST PM0054, p.5.2.
After this procedure ROP is still equal 0x00 and writing is disabled.

I checked that I can freely modify bytes 0x4801 - 0x480C.
I can't modify only 0x4800.

BR

When using stm8flash with original ST-Link V2, I have a troubles with very low speed of flash writting. It seems like 20..50 bytes per second.

.

hi Valentin,

as discussed in #16 there is an issue under MacOSX to claim the USB interface for stm8flash. Any idea what is going wrong? Thanks a lot in advance!

Georg

Hello,

I'm trying to programm option bytes at stm8s003 using stlinkv2.
There is an information about opt2 writing in compatibility table - there is no suppoprt for opt's yet.

Theoretically there is almost all what you need to run opt writing.
When I try to write at 0x4800 stm8 returned write confirmation but after reading using veryfi option there are old values.

What missing in source code to write and check opt values?
How can I modify project to run this feature?

br

Hi folks!

Since a couple of days I wasn't able to read or write to any of my ESP14 modules with "stm8s003f3 inside".

Occasionally it seemed to work very few times ... but then stalled again getting the "Tries exceeded".

Suggestions given here in other posts didn't work either.

Totally stuck I had a look into the sources ... especially the try.h file. Accordingly to the commit history the delay value had been changed recently from 3000us to 10000us in order to get a higher rate of success using the ST-LinkV2 clones.

Since mine was not working at all I decided to go back to the original 3000us. After a quick build I've to say that it magically started to work, from the very first try ... alter having failed with the original 10000us before.

I don't know if this may be circuit related, platform or usblib related ... but the important thing for now is that it works and I can proceed exploring the STM8 devices.

In order to be able to adjust the delay values I added an -d option under Troubleshooting section which allows to choose between default (3ms), slow (10ms) or even a numeric value in ms.

The diff to the original source is attached below. This patch also corrects the no permission issue from my previous post when running [sudo] make install.

stm8flash.diff.txt

Regards.

hi Valentin,

I would very much like to use your stm8flash tool under MacOS X 10.10.3. However, I ran into a problem for which I need your help. Here's my steps with observations:

• installed pkg-config and libusb --> worked
• compile of stlink.c gave
  • many warning messages like (ignored):
    stlink.c:37:71: warning: passing 'char [32]' to parameter of type 'unsigned char *' converts between pointers to integer types with different sign [-Wpointer-sign]
    --> suppose this is not critical...? Disabled all warnings by CFLAGS += -w in Makefile
  • many error messages like (fixed):
    /usr/local/Cellar/libusb/1.0.19/include/libusb-1.0/libusb.h:1696:10: error: use of undeclared identifier 'NULL'
    --> fixed by #include <stddef.h> in stlink.c before #include <libusb.h>
  • many error message like (open):
    stlink.c:340:12: error: use of undeclared identifier 'stderr'
    fprintf(stderr, "Unknown status: %x\n", status);
    In addition it warns that
    declaration of built-in function 'fprintf' requires inclusion of the header <stdio.h>
    --> it seems like the inclusion of <stdio.h> in line 4 of stlink.c has no effect... :-(
• to make sure my toolchain is ok, I compiled a dummy program with fprintf(stderr,"test"); and it was ok

--> I played around a lot but can't get that stdio.h point fixed :-( Any idea what's going on here? For your help thanks a lot in advance!

Regards, Georg

on macOS "Sierra" 10.12.6 (16G29) the "make install" gives an error stating it has no permission to copy stm8flash:

localhost:stm8flash ts$ make install
mkdir -p /usr/bin/
cp stm8flash /usr/bin/
cp: /usr/bin/stm8flash: Operation not permitted
make: *** [install] Error 1

This error happens regardless if executed with normal user privileges or via sudo.

Adding a 'Darwin' condition to the install target in the Makefile resolves this issue:

$ git diff Makefile 
diff --git a/Makefile b/Makefile
index bc1a9c2..b74fc15 100644
--- a/Makefile
+++ b/Makefile
@@ -65,7 +65,11 @@ install:
 ifeq ($(PLATFORM),FreeBSD)
        mkdir -p $(DESTDIR)/usr/local/bin/
        cp $(BIN)$(BIN_SUFFIX) $(DESTDIR)/usr/local/bin/
+else ifeq ($(PLATFORM),Darwin)
+       mkdir -p $(DESTDIR)/usr/local/bin/
+       cp $(BIN)$(BIN_SUFFIX) $(DESTDIR)/usr/local/bin/
 else
        mkdir -p $(DESTDIR)/usr/bin/
        cp $(BIN)$(BIN_SUFFIX) $(DESTDIR)/usr/bin/
 endif

Regards.

I initially used the stm8flash on my stlinkv2 and it worked, then I needed to erase the ROP and used the windows flasher. Now the windows flasher works but stm8flash doesn't.

I wonder how to debug that as I never debugged a USB protocol. I can sniff the windows app behavior but can't make much sense out of it.

Some STM8 parts have an eeprom of configurable start address and location: Option bytes allow to use some memory either as flash or as eeprom. An example would be the STM8L101K3 on the STM8L101-EVAL evaluation board.
How would one add support for such a part to stm8flash?

Philipp

hi Valentin,

after updating to MacOSX 10.11.1 "el Capitan" I wanted to check if claiming the USB port now works under OS X (see also #16). Unfortunately make aborts with the below errors. Any ideas? Thanks a lot in advance!

$ make
cc pkg-config --cflags libusb-1.0 -g -O0 --std=gnu99 --pedantic -Ixcrun --show-sdk-path/usr/include/ -Ixcrun --show-sdk-path/usr/include/sys -Ixcrun --show-sdk-path/usr/include/machine -c -o stlink.o stlink.c
stlink.c:247:3: warning: implicit declaration of function 'usleep' is invalid in C99 [-Wimplicit-function-declaration]
usleep(10000);
^
stlink.c:342:4: warning: implicit declaration of function 'fprintf' is invalid in C99 [-Wimplicit-function-declaration]
fprintf(stderr, "Unknown status: %x\n", status);
^
stlink.c:342:4: warning: declaration of built-in function 'fprintf' requires inclusion of the header <stdio.h>
[-Wbuiltin-requires-header]
stlink.c:342:12: error: use of undeclared identifier 'stderr'
fprintf(stderr, "Unknown status: %x\n", status);
^
stlink.c:542:12: error: use of undeclared identifier 'stderr'
fprintf(stderr, "Write error\n");
^
3 warnings and 2 errors generated.
make: *** [stlink.o] Error 1

Best regards,
Georg

Work with a flash and eeprom not tested.

Hi,

Do you plan to implement Erase command to clear flash/eeprom area?

BR

to flash a protected STM8S003F3, using single byte 0x55 file ROP_CLEAR.bin to erase ROP:

$ echo "aa" | xxd -r -p >ROP_CLEAR.bin
$ stm8flash -c stlinkv2 -p stm8s003f3 -s opt -w ROP_CLEAR.bin 
Determine OPT area
Writing binary file 2 bytes at 0x4800... OK
Bytes written: 1
$ stm8flash -c stlinkv2 -p stm8s003f3 -s flash -r nothing.bin ; xxd nothing.bin
Determine FLASH area
Reading 8192 bytes at 0x8000... OK
Bytes received: 8192
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
.
.

(very strange, erased flash should reads ffffff) Now the MCU really is not running old program, but it cannot be flashed

$ make flash 
stm8flash -cstlinkv2 -pstm8s003f3 -w blink.ihx
Determine FLASH area
Writing Intel hex file 202 bytes at 0x8000... Tries exceeded

erase it again

$ stm8flash -c stlinkv2 -p stm8s003f3 -s opt -w ROP_CLEAR.bin 
Determine OPT area
Writing binary file 1 bytes at 0x4800... OK
Bytes written: 1
$ stm8flash -c stlinkv2 -p stm8s003f3 -s flash -r nothing.bin ; xxd nothing.bin
Determine FLASH area
Reading 8192 bytes at 0x8000... OK
Bytes received: 8192
00000000: 7171 7171 7171 7171 7171 7171 7171 7171  qqqqqqqqqqqqqqqq
00000010: 7171 7171 7171 7171 7171 7171 7171 7171  qqqqqqqqqqqqqqqq
.
.
.

repeat erase and read, readout data stuck in this 000000 and 717171 loop.

same issue on ubuntu 15.10 and OS X 10.11.2

$ uname -a
Linux [hostname] 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

# uname -a
Darwin  [hostname] 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

AFAIK, there are three official variants: ST-LINK, ST-LINK/v2, ST-LINK/V2-1. For all three, there exist various firmware version.
A non-free update utility for the non-free firmware can be found at:
http://www.st.com/en/development-tools/stsw-link007.html

How does this affect stm8flash? Maybe some issues we see are not just specific to certain hardware clones, but also to certain firmware versions?

Philipp

P.S.: In the end, it would be best, if we had free firmware for some ST-LINK variant or some other device, such as the Black Magic Probe.

stm8flash has problem parsing S-record files with addresses longer than 16 bits (2 bytes) as being out of range, which is not true.
I propose we read 32 bits (4 bytes) instead of only 16 bits (2 bytes) and throw them away if not needed:
srec.c

sscanf(line, "S%01x%02x%08x", &chunk_type, &chunk_len, &chunk_addr)
chunk_addr = chunk_addr >> (8*(3-chunk_type));

I will prepare pull request.

Apparently, ST is about to release version 3 of the ST-Link:

https://community.st.com/thread/46479-stlinkv3

Once sufficient documentation becomes available, stm8flash should add support.

Philipp

sudo apt-get install pkg-config
sudo apt-get install libusb-1.0-0-dev
You need to change the path to the libusb in the stm8flash/pgm.h file on #include </usr/include/libusb-1.0/libusb.h>

STM8 assembly language programs built using the ASxxxx (V5.20) STM8 assembler and linker are by default given names ending ".i86" - presumably indicating Intel 8086 format. stm8flash loads such a file as a binary. If you miss the word "BINARY" when flashing, it looks like flashing has been successful but of course the flash memory contains the hex records. Please consider changing your program flow so that ".bin" is required for binary flashing and anything else is just passed to the Intel hex routines which will quit with an error if the file is not valid Intel hex records. This way you will not need to add new ".xxx" entries if (when?) new hex file naming conventions appear. This will interfere with Motorola S-record support but since you have none now there will be no loss. If SDCC upgrades to a version of ASxxxx that writes ".i86" files everyone using SDCC will have this problem too.

Hi.
I am trying to create an RPM package for stm8flash and rpmlint is complaining about incorrect fsf address.

stm8flash.x86_64: E: incorrect-fsf-address /usr/share/doc/stm8flash/COPYING

https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address sais I should report this here.

According to http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt, the current address is

51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

Please change it.

Attached is a document that attempts to put the Read-out Protection (ROP) option byte information for all STM8 devices in one place.

The mechanism to disable ROP varies between STM8 types, and sometimes within the type.

The documentation is not as clear nor as consistent as it might be, and this can lead to confusion.

This information does not concern itself with any other option byte, in any way.

STM8_ROPOptionByte.xlsx

NB: This is the author's interpretation of the many and varied STM8 documentation; please satisfy yourself that the information following is correct

Attached is (hopefully, as this site would not allow an OpenOffice spreadsheet) an Excel spreadsheet showing the ROP option byte for the various devices within the STM8 families.

Here is a summary

1. STM8S ROP Option Byte
   Factory Default: 0x00
   Enable ROP: Write 0xAA to 1st Option Byte
   ROP Disable: Write a single byte that is NOT 0xAA (e.g. 0x00) to 1st Option Byte, then reset device

2. STM8AF ROP Option Byte
   Factory Default: 0x00
   Enable ROP: Write 0xAA to 1st Option Byte
   ROP Disable: Write a single byte that is NOT 0xAA (e.g. 0x00) to 1st Option Byte, then reset device

3. STM8AL ROP Option Byte
   Factory Default: 0xAA
   Enable ROP: Write any byte other than 0xAA (e.g. 0x00) to 1st Option Byte
   ROP Disable: 1st Option Byte, write 0xAA, read EOP, write 0xAA, read EOP

4. STM8L (except STM8L101xx) ROP Option Byte
   Factory Default: 0xAA
   Enable ROP: Write any byte other than 0xAA (e.g. 0x00) to 1st Option Byte
   ROP Disable: 1st Option Byte, write 0xAA, read EOP, write 0xAA, read EOP

5. STM8L101xx ROP Option Byte
   Factory Default: 0x00
   Enable ROP: Write 0xAA to 1st Option Byte
   ROP Disable: Write a single byte that is NOT 0xAA (e.g. 0x00) to 1st Option Byte, then reset device

Also note that the documentation for the STM8L052R8 device gives a factory default value of 0x00 for the ROP option byte; this differs from the other devices in the same series (although this could be an error in the documentation).

I love the programmer you put together so far. However, one annoyance is that it keeps the device in reset after it terminates, despite having reset routines in the code.

My configuration

• stm8prog @ f4b19f2
• OS Ubuntu Linux 12.04 (amd64)
• stm8vldiscovery (using onboard stlinkv1 debugger, STM8S003k3)
• newest stlink firmware flashed to the programmer (2.21.4, from here http://www.st.com/web/en/catalog/tools/PF258194#)

The only remedy I currently have to reset the device is to replug the USB cable or to manually assert the resetline of the STLink MCU.

Hello to All.

STM8S903K3 with stlinkv2 and stm8flash results:

Determine FLASH area
Writing Intel hex file 2550 bytes at 0x8000... Tries exceeded

With stlink flashing suspends. It is done after few Bytes. I found out this by STVP.

Chip is not write protected and is unlocked - checked by STVP.

Any reasons?

stm8flash can't clear flash of STM8S003 protected from reading by ROP:

stm8flash -cstlinkv2 -pstm8s003 -w testproj.bin
Determine FLASH area
Writing binary file 2271 bytes at 0x8000... Tries exceeded

The same problem when I try to clear ROP:
stm8flash -cstlinkv2 -pstm8s003 -s 0x4800 -b 1 -w ROP_clear.bin
Writing at 0x4800... Tries exceeded

Currently stm8flash is using libusb_open_device_with_vid_pid function that returns handle to the first device that match vID and pID.
I've created a simple patch that adds -S option that allows for specifying the desired programmer.
I have some difficulties creating pull-request so feel free to use my change if you find it useful.

I can also confirm the tool works flawlessly for target stm8l151?6 (STML151G6 in my case)
multiple.diff.gz

Hi,

uname -a:
Linux betta 4.1.13-1-ARCH #1 PREEMPT Fri Nov 13 20:10:41 MST 2015 armv6l GNU/Linux

stm8flash is the latest master code.
I just clone from git and make.

The command line I call stm8flash in Makefile is:
stm8flash -c stlinkv2 -p stm8s103 -w blinky.ihx uart.ihx

This not work. Seems that main.c (line: while((c = getopt (argc, argv, "r:w:v:nc:p:s:b:")) != -1)) getopt returns wrong result.
If I add "if(c == 255) break;" to first line in the while block, It can break and execute following code.

stm8flash currently is an essential part of the free toolchain for STM8. I'd suggest to make a release. Releases tend to be more trusted by users and tend to make it more likely that the software gets picked up by distributions. There is probably still a bit of work in getting stm8flash into a state fit for release (and I'm willing to help), but even in its current state it is quite useful software that should be good enough for the vast majority of use cases.

Philipp

stm8link is mostly licensed under GPLv2 (not "GPLv2 or later"). But part of it is under GPLv3. This is a major issue and needs to be fixed, as these two licenses are incompatible. My suggestion would be to change it to "GPLv2 or later".

Philipp

PS C:\Users\admin\Desktop\stm8flash> make -j5
GCC -g -O0 --std=gnu99 --pedantic     -c -o stlink.o stlink.c
GCC -g -O0 --std=gnu99 --pedantic     -c -o stlinkv2.o stlinkv2.c
GCC -g -O0 --std=gnu99 --pedantic     -c -o espstlink.o espstlink.c
GCC -g -O0 --std=gnu99 --pedantic     -c -o main.o main.c
espstlink.c:27:10: fatal error: termios.h: No such file or directory
#include <termios.h>
          ^~~~~~~~~~~
GCC -g -O0 --std=gnu99 --pedantic     -c -o byte_utils.o byte_utils.cco
mpilation terminated.
make.exe": *** [espstlink.o] Error 1
make.exe": *** Waiting for unfinished jobs....
PS C:\Users\admin\Desktop\stm8flash>

It seems that the header termios.h is required and not presented by mingw64. By the way, what is espstink ? A wifi stlink made by ESP8266 ?
I use common usb stlink for STM8s. So can I remove this part code directly or how to make it works under Windows?

make
cc -g -O0 --std=gnu99 --pedantic -I/usr/include/ -I/usr/include/sys -I/usr/include/machine -I/usr/local/Cellar/libusb/1.0.21/include/libusb-1.0 -c -o stlink.o stlink.c
stlink.c:250:3: warning: implicit declaration of function 'usleep' is invalid in
C99 [-Wimplicit-function-declaration]
usleep(10000);
^
stlink.c:345:4: warning: implicit declaration of function 'fprintf' is invalid
in C99 [-Wimplicit-function-declaration]
fprintf(stderr, "Unknown status: %x\n", status);
^
stlink.c:345:4: warning: declaration of built-in function 'fprintf' requires
inclusion of the header <stdio.h> [-Wbuiltin-requires-header]
stlink.c:345:12: error: use of undeclared identifier 'stderr'
fprintf(stderr, "Unknown status: %x\n", status);
^
stlink.c:545:12: error: use of undeclared identifier 'stderr'
fprintf(stderr, "Write error\n");
^
3 warnings and 2 errors generated.
make: *** [stlink.o] Error 1

in OS X 10.11.1, compiled stm8flash with libusb1.0.20 (homebrew)

# make
cc `pkg-config --cflags libusb-1.0` -g -O0 --std=gnu99 --pedantic -I`xcrun --show-sdk-path`/usr/include/ -I`xcrun --show-sdk-path`/usr/include/sys -I`xcrun --show-sdk-path`/usr/include/machine   -c -o stlink.o stlink.c
cc `pkg-config --cflags libusb-1.0` -g -O0 --std=gnu99 --pedantic -I`xcrun --show-sdk-path`/usr/include/ -I`xcrun --show-sdk-path`/usr/include/sys -I`xcrun --show-sdk-path`/usr/include/machine   -c -o stlinkv2.o stlinkv2.c
cc `pkg-config --cflags libusb-1.0` -g -O0 --std=gnu99 --pedantic -I`xcrun --show-sdk-path`/usr/include/ -I`xcrun --show-sdk-path`/usr/include/sys -I`xcrun --show-sdk-path`/usr/include/machine   -c -o main.o main.c
main.c:239:10: warning: enumeration value 'UNKNOWN' not handled in switch [-Wswitch]
                switch(memtype) {
                       ^
1 warning generated.
cc `pkg-config --cflags libusb-1.0` -g -O0 --std=gnu99 --pedantic -I`xcrun --show-sdk-path`/usr/include/ -I`xcrun --show-sdk-path`/usr/include/sys -I`xcrun --show-sdk-path`/usr/include/machine   -c -o byte_utils.o byte_utils.c
cc `pkg-config --cflags libusb-1.0` -g -O0 --std=gnu99 --pedantic -I`xcrun --show-sdk-path`/usr/include/ -I`xcrun --show-sdk-path`/usr/include/sys -I`xcrun --show-sdk-path`/usr/include/machine   -c -o ihex.o ihex.c
cc `pkg-config --cflags libusb-1.0` -g -O0 --std=gnu99 --pedantic -I`xcrun --show-sdk-path`/usr/include/ -I`xcrun --show-sdk-path`/usr/include/sys -I`xcrun --show-sdk-path`/usr/include/machine   -c -o stm8.o stm8.c
cc stlink.o stlinkv2.o main.o byte_utils.o ihex.o stm8.o `pkg-config --libs libusb-1.0` -o stm8flash
# sudo make install 
cp stm8flash /opt/bin/

has the following issues:

• 1. there's a 3-second pause before read/write operation, like this:

# stm8flash -c stlinkv2 -p stm8s003f3 -s eeprom -r eep.bin 
Determine EEPROM area
[pause here for ~3 seconds]
Reading 128 bytes at 0x4000... OK
Bytes received: 128

• 2. after one read or write, (either successful or failure), next read/write will stuck like this:

stm8flash -c stlinkv2 -p stm8s003f3 -s eeprom -r eep.bin 
Determine EEPROM area
[stuck here forever, until STLinkv2 is unplugged]
libusb: warning [darwin_transfer_status] transfer error: device not responding (value = 0xe00002ed)
IO error: expected 2 bytes but 0 bytes transferred

unplug STLinkv2 and plug again, flash goes well (still has mentioned ~3-second pause)

Additional info (might be relevant):
st-flash suffers from pause issue (flashing STM32 MCUs) also, between 3-8 seconds, but no issue 2. on OS X 10.11 and 10.10

I accidentially specified s- eeprom instead of -s eeprom:

./stm8flash -c stlinkv2 -p stnrg388a s- eeprom -w /tmp/1k

stm8flash wrote to flash, while I would have expected an error.

Philipp

./stm8flash -c stlinkv2 -p stm8s103?3 -w ../sdcc-examples-stm8/blinky.ihx

results into

Determine FLASH area
Writing Intel hex file 194 bytes at 0x8000... Tries exceeded

There is stm8s103f3 controller on the "minimal system board". Can I help (e.g. providing of additional logs, testing) to make this toolset work with the controller mentioned?

Also, is there any native Linux way to flash stm8 as a temporary solution?

Hardware is similar to the listed in this article

$ ./stm8flash -c stlinkv2 -p stm8af528? -s flash2 -w ./myprog.hex
Determine RAM area
Due to its file extension (or lack thereof), "./myprog.hex" is considered as INTEL HEX format!
Address 8000 + 4 is out of range at line 1

In ST Visual Develop it works without problems.

Can't write to stm8l151k4 due to block size. In family "stm8l151?4" is block size 128 bytes instead of 64 bytes, please check PM0054 page 26. It is in file stm8.c line 474 (e.g. 72be7ba).

I did a bit further testing on chips with more than 32K (results in the README.md of my branch). It seems I cannot write outside the lower 32K of flash, i.e. I cannot write outside the lower 64K of the address space.

Philipp

Older commit:

$ time stm8flash -c stlinkv2 -p stm8s003f3 -w empty.bin 
Determine FLASH area
Writing binary file 6144 bytes at 0x8000... OK
Bytes written: 6144

real    0m2.735s
user    0m0.020s
sys     0m0.000s

Master:

$ time stm8flash -c stlinkv2 -p stm8s003f3 -w empty.bin 
Determine FLASH area
Writing binary file 6144 bytes at 0x8000... OK
Bytes written: 6144

real    0m4.124s
user    0m0.000s
sys     0m0.020s

The issue seems to be introduced in b8dcaa1. Also, what is the purpose of usleep(2000) in stlink2_write_ functions? Code uses blocking libusb transfers so I'm not exactly sure why this delay is needed.

ST has controllers for wireless charging that have an integrated STM8 microcontroller: STWBC, STWBC-EP, STWBC-WA. Possibly also ASTWBC5V and STWBC-MC, though I only found the latter two mentioned at IAR, not ST itself.

stm8flash should get support for those.
Unfortunately, it seems sufficient documentation to support them in stm8flash is not yet available.

Philipp