gicking / stm8gal Goto Github PK

see old repo

I cannot program my STM8S105K6-based boards anymore, which used to work.

Versions prior to 1d91c12:

> ./stm8gal -p /dev/ttyUSB0 -u 2 -R 1 -w /tmp/arduino_build_28225/Blink.ino.hex  

stm8gal (v1.2.0 beta)
  load Intel hex file 'Blink.ino.hex' ... ok (2.7kB)
  reset STM8 and press <return>
  open serial port '/dev/ttyUSB0' with 230.4kBaud ... ok
  synchronize ... ok (ACK)
  determine device ... ok (STM8S; 32kB flash; BSL v1.3)
  Uploading RAM routines ... ok (304B from 0x00a0)
  write 2.7kB (0x8000 to 0x8aa5) ... ok   
  read 2.7kB (0x8000 to 0x8aa4) ... ok
  verify memory ... ok
  activate bootloader ... ok
  jump to address 0x8000 ... ok
done with program

1d91c12 and later:

> ./stm8gal -p /dev/ttyUSB0 -u 2 -R 1 -w /tmp/arduino_build_28225/Blink.ino.hex 

stm8gal (v1.2.0 beta)
  load Intel hex file 'Blink.ino.hex' ... ok (2.7kB)
  reset STM8 and press <return>
  open serial port '/dev/ttyUSB0' with 230.4kBaud ... ok
  synchronize ... 

error in 'bsl_sync()': no response from BSL, exit!

They are connected via a CH340G USB-to-serial interface on the same board and I'm using Linux.

stm8gal currently contains some non-free binary blobs for some target devices. They should be replaced by free software.

Philipp

The bsl_getInfo() function in bootloader.c attempts to determine memory size of the device by reading from the last byte of flash. I notice that it does not have a case for 64K devices. I believe this will mis-classify some 64K devices as having 32K of flash memory and being 'medium density' devices, when they should be 'high density'.

For example, the STM8AF5288 is a 64K device and is classified as 'high density'. See Table 1 (pg. 6) of UM0560. ST's website product page also says this: "They are referred to as high density STM8A devices in STM8S series and STM8AF series 8-bit microcontrollers reference manual (RM0016)".

I think this will lead to stm8gal incorrectly erroring with an "unsupported device" message, when in fact it should install the RAM routines for a 128K device (further evidenced by the ROM BL of a STM8AF5288 being byte-for-byte identical to a STM8S208).

see old repo

stm8gal help: -W/-write-byte [addr value] change value at given address (as dec or hex)

However, an address or value in decimal is wrongly interpreted as hexadecimal.

Update: also true for -j, -w (bin), -r and -e

The link is for STM32, it should be:
https://my.st.com/content/my_st_com/en/products/development-tools/software-development-tools/stm8-software-development-tools/stm8-programmers/flasher-stm8.html

I get the error open serial port '/dev/bus/usb/001' ... Error: in 'init_port(/dev/bus/usb/001)': open port failed
under mac and ubuntu wsl
lsusb output:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0483:3748 STMicroelectronics ST-LINK/V2
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

command i run:
sudo stm8gal -p /dev/bus/usb/001 -w STM8L15X_MD.hex with and without sudo

stm8gal -p does not list anything

maybe its my programmeri dont know. just wanted to let you know!
stm8flash is working - if we work this out together i can provide Mac os m1 builds :)

Resetting a board via DTR pin does not work anymore.
The guilty commit appears to be cd470a7, which kind of makes sense. I.e. you'll have to open the port before you can toggle DTR.

I hope you are still around :)

I am trying to learn how to use an STM8S with a STM8S-discovery board and I can flash using STVP, but I'd like to incorporate a command line flash into my VS Code (tasks.json calling the Makefile flash option I wrote)

I have gcc installed, but I don't want to have to start installing mingw etc.

I don't suppose you have a pre-built win10 version available for me to use do you?

Gordon

Compilation on OSX and on Windows fails for two reasons:

• the Makefile tries to compile spi_spidev_comm.c (shouldn't be compiled at all on these platforms)
• the flag -DUSE_SPIDEV is automatically set for OSX.

An easy workaround is to delete spi_spidev_comm.c from the list in SOURCES in the Makefile and start the compilation with this call: make OS=Win. Yes, even on OSX it needs OS=Win.

This is not really a bug report, but a report of an odd finding. I am posting here instead of PM in the hope that this might be useful information for others as well.

I am using stm8gal (on mint19/ubuntu 18.4) with the simple breakout boards from China for the STM8S105K4T6 but the default communication fails:

$ stm8gal -p /dev/ttyUSB0

stm8gal (v1.1.8)
  reset STM8 and press <return>
  open serial port '/dev/ttyUSB0' with 230.4kBaud ... ok
  synchronize ... ok (ACK)
  determine device ... 

error in 'bsl_memCheck()': ACK1 timeout (expect 1, received 0), exit!

It turns out, that the MCU expects data transfer without parity (8N1), despite UM0560 specifically asking for even parity (8E1). This (surprisingly) works:

$ stm8gal -u 2 -p /dev/ttyUSB0

stm8gal (v1.1.8)
  reset STM8 and press <return>
  open serial port '/dev/ttyUSB0' with 230.4kBaud ... ok
  synchronize ... ok (ACK)
  determine device ... ok (STM8S; 32kB flash; BSL v1.3)
  Uploading RAM routines ... ok (304B from 0x00a0)
  jump to address 0x8000 ... ok
done with program

Do you have any idea why? I couldn't find a detailed list about the expected data format for each CPU.

Reading out and/or verifying data in "UART reply mode" is very slow over 2-wire interface. This is caused by a few ms latency for each byte which must be echoed by the PC. Using a FT232R, reading back 14kB takes ~5min

It would be useful to be able to access and modify the option bytes using stm8gal. Especially the ROP (read out protection) bit for unlocking a locked MCU is important.