stcgal 1.4 in raspberry pi 3 with Stretch

[tijopr]

Hi (newbie here) Installed stcgal 1.4 and tried to program stc15f104w embedded in lc-tech relay with esp8266.

Removed esp8266, connected to rpi.

Program does not recognize option stc15a, it is shown in help.

pi@raspberrypi:~ $ sudo /usr/local/bin/stcgal -h
usage: stcgal [-h] [-a] [-r RESETCMD] [-P {stc89,stc12a,stc12b,stc12,stc15a,stc15,usb15,auto}] [-p PORT] [-b BAUD] [-l HANDSHAKE] [-o OPTION] [-t TRIM] [-D] [code_image] [eeprom_image]

stcgal 1.4 - an STC MCU ISP flash tool (C) 2014-2017 Grigori Goronzy https://github.com/grigorig/stcgal

When trying to use it: pi@raspberrypi:~ $ sudo /usr/local/bin/stcgal -p /dev/serial0 -b 9600 -D -P stc15 Traceback (most recent call last): File "/usr/local/bin/stcgal", line 11, in load_entry_point('stcgal==1.4', 'console_scripts', 'stcgal')() File "/usr/local/lib/python3.5/dist-packages/stcgal-1.4-py3.5.egg/stcgal/frontend.py", line 219, in cli File "/usr/local/lib/python3.5/dist-packages/stcgal-1.4-py3.5.egg/stcgal/frontend.py", line 137, in run File "/usr/local/lib/python3.5/dist-packages/stcgal-1.4-py3.5.egg/stcgal/protocols.py", line 284, in connect File "/usr/lib/python3/dist-packages/serial/serialutil.py", line 352, in timeout self._reconfigure_port() File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 427, in _reconfigure_port [iflag, oflag, cflag, lflag, ispeed, ospeed, cc]) termios.error: (22, 'Invalid argument')

With "auto" option

pi@raspberrypi:~ $ sudo /usr/local/bin/stcgal -p /dev/serial0 -b 9600 -D -P auto Waiting for MCU, please cycle power: <- Packet data: 00 <- Packet data: 00 <========= I get garbage back (suspect stc is not programmed).

[grigorig]

Are you sure the serial port /dev/serial0 is correct? What is it mapped to? Please note that you may not be able to use the Raspberry Pi "Mini UART". It doesn't properly support parity.

Check here how to switch to the "full UART": https://www.raspberrypi.org/documentation/configuration/uart.md

[nekromant]

First, hardware UART is most likely /dev/ttyS0, /dev/ttyS1 and etc. If the problem still persists, it's most likely that hardware serial implementation lacks some ioctl that pyserial uses. You can try wrapping the stcgal call in strace and post the log. We'll see which ioctl is failing.

On the other hand - you can always use a spare usb port and a suported usb<-->uart bridge.

[tijopr]

Apologies for the late response. /dev/serial0 links to /dev/ttyS0. I will wrap the stcgal call in strace and post the log. Thanks for the suggestion for the usb <---> bridge, ordered one.

Is commit eb6df3b related to this issue?

Thanks for your support.

[nekromant]

@tijopr Nope, it's only a fix for debian packaging. It's not related in any way to your problem

[grigorig]

@tijopr You could also try switching to the full-featured UART (if you don't need Bluetooth) as described in the document I linked to.

[tijopr]

strace log info. Thanks again for all your support.

1. root@raspberrypi:/home/pi# ls -la /dev/serial0 lrwxrwxrwx 1 root root 5 Jun 22 21:36 /dev/serial0 -> ttyS0

2. Command used (as root): (Note - I had to interrupt the process, since it remains running, the output continues with these data on screen: <- Packet data: 00 <- Packet data: C0 <- Packet data: 00 ) root@raspberrypi:/home/pi# strace -o /home/pi/straceOut.txt /usr/local/bin/stcgal -p /dev/ttyS0 -b 9600 -D -P auto

3. Output in attached file straceOut.txt

[nekromant]

please attach the sudo strace /usr/local/bin/stcgal -p /dev/serial0 -b 9600 -D -P stc15 output. The one with no ioctl errors won't tell us anything ;)

[grigorig]

ttyS0 means you're still using the mini UART. This cannot work. Please switch to the full (pl011) UART!

[tijopr]

1. Followed instructions to use the PL011 UART: a. Added dtoverlay=pi3-disable-bt to /boot/config.txt b. Disabled Linux console use of the uart (sudo raspi-config, Select option 5, Interfacing options, then option P6, Serial, and select No. Exit raspi-config) c. Disabled the system service that initializes the modem so it doesn't use the UART: sudo systemctl disable hciuart d. reboot system

2. Executed following command, attached output. root@raspberrypi:/home/pi# strace -o /home/pi/straceOut.txt /usr/local/bin/stcgal -p /dev/ttyAMA0 -b 9600 -D -P stc15 Waiting for MCU, please cycle power: <- Packet data: 00 <- Packet data: 00 <- Packet data: 00 <- Packet data: 00 <- Packet data: 00 <- Packet data: 00 <- Packet data: 00 <- Packet data: 00 <- Packet data: 00 <- Packet data: 00 (hit CTRL-C, it continues)

3. I tried again the command without the -D option. Output in strace2.txt. In screen, the stcgal command waits for the MCU to cycle power. After waiting some minutes, I manually removed power from the MCU, reattach power, but it still remained waiting ... please cycle power.

root@raspberrypi:/home/pi# strace -o /home/pi/strace2.txt /usr/local/bin/stcgal -p /dev/ttyAMA0 -b 9600 -P stc15 Waiting for MCU, please cycle power: ^Cinterrupted

straceOut.txt strace2.txt

Thanks for all your help and patience!

[grigorig]

It could be a number of issues - there's a configuration bit (bsl_pindetect_enabled) that disables the bootloader unless specific I/O lines are tied to ground. See STC's manuals for more info. It's also possible that the MCU is phantom powered through I/O lines, even when VCC isn't connected. Unfortunately, STC's power-on-reset method to invoke the bootloader is somewhat fragile.

A resistor (220 ohms or so) between the MCUs GND and VCC can help to avoid phantom powering issues.