stcgal Unable to upload to STC15L2K32S2

Unable to upload to STC15L2K32S2

Open Mrnt opened this issue 8 years ago • 38 comments

Thank you so much for developing this tool!

I am having a little trouble getting it to work with a STC15L2K32S2 with a PL2303 on OSX. It appears to detect the chip correctly:

python3.5 stcgal.py -D -P stc15 -p /dev/cu.usbserial
Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 67 6F 87 A9 F7 BA 9F 01 51 63 E0 FD 4D FE 00 00 72 53 00 F4 84 04 06 70 A9 02 14 19 1C 1E 1E 00 F4 80 04 DC FF 84 7F FF FF 15 06 05 51 13 CB 16
done
Target model:
  Name: STC15L2K32S2
  Magic: F484
  Code flash: 32.0 KB
  EEPROM flash: 29.0 KB
Target frequency: 22.111 MHz
Target BSL version: 7.2.4S
Target wakeup frequency: 26.479 KHz
Target options:
  reset_pin_enabled=False
  clock_source=internal
  clock_gain=high
  watchdog_por_enabled=False
  watchdog_stop_idle=True
  watchdog_prescale=256
  low_voltage_reset=True
  low_voltage_threshold=2
  eeprom_lvd_inhibit=True
  eeprom_erase_enabled=False
  bsl_pindetect_enabled=False
  por_reset_delay=long
  rstout_por_state=high
  uart2_passthrough=False
  uart2_pin_mode=normal
  cpu_core_voltage=unknown
-> Packet data: 46 B9 6A 00 07 82 00 F3 16
Disconnected!

However, when I attempt to flash it using the blinky sample I am seeing this:

python3.5 stcgal.py -D -P stc15 -p /dev/cu.usbserial ../stc_blinky/blinky.hex
Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 67 6F 87 A9 F7 BA 9F 01 51 63 E0 FD 4E 08 00 00 72 53 00 F4 84 04 06 70 A9 02 14 19 1C 1E 1E 00 F4 80 04 DC FF 84 7F FF FF 15 06 05 51 12 D6 16
done
Target model:
  Name: STC15L2K32S2
  Magic: F484
  Code flash: 32.0 KB
  EEPROM flash: 29.0 KB
Target frequency: 22.111 MHz
Target BSL version: 7.2.4S
Target wakeup frequency: 26.479 KHz
Target options:
  reset_pin_enabled=False
  clock_source=internal
  clock_gain=high
  watchdog_por_enabled=False
  watchdog_stop_idle=True
  watchdog_prescale=256
  low_voltage_reset=True
  low_voltage_threshold=2
  eeprom_lvd_inhibit=True
  eeprom_erase_enabled=False
  bsl_pindetect_enabled=False
  por_reset_delay=long
  rstout_por_state=high
  uart2_passthrough=False
  uart2_pin_mode=normal
  cpu_core_voltage=unknown
Loading flash: 1433 bytes (Intel HEX)
Trimming frequency: -> Packet data: 46 B9 6A 00 20 00 0C 00 C0 80 C0 FF C0 00 80 80 80 FF 80 00 40 80 40 FF 40 00 00 80 00 C0 00 0A D3 16
Serial port error: pulse timeout

and stcgal bails.

I'm a newbie to programming the STC chips so I apologize if this is user error.

Feb 15 '16 19:02 Mrnt

I haven't really tested stcgal on OS X, so...

Try different baud rates (-l)
If possible, try a different USB UART device
Maybe it's a driver issue? Try updating it, if possible.

Maybe you could also verify that this isn't an OS specific issue by using another PC with Linux or Windows.

Feb 16 '16 16:02 grigorig

For me at least, on Mac with cp2102 uart and stc15f204ea, I have to set both handshake and transfer speeds to 9600. Nothing else will work. I don't have the problem with same chip and uart on Linux. For whatever reason

Feb 16 '16 17:02 zerog2k

These problems can be caused by bad drivers and certain buggy versions of pyserial. The latest version 3.01 of pyserial should be fine.

Feb 16 '16 22:02 grigorig

Just an update... Tried pyserial 3.01, and no change for my case - still have to use 9600/9600. I am yet to try a different uart chip...

Feb 26 '16 20:02 zerog2k

Thank you for your prompt response and trying to help!

I did try using ISP.exe on a windows vm using the same usb serial adapter with the same binary and that was successful. I'm also using python under OSX to flash ESP8266 using the same usb adapter, so I know the hardware can work (most of the time ;-) ).

Tried with stcgal with 9600/9600:

sudo python3 stcgal.py -P stc15 -p /dev/cu.usbserial -b 9600 -l 9600 -D ../stc_blinky/blinky.hex

and made sure I'm using pyserial 3.0.1 but get the same message as in the original post. It looks like it fails in the # calibration, round 1, not sure if that helps.

Mar 02 '16 19:03 Mrnt

another stab in the dark: have you tried other protocols, e.g. -P stc15a

Mar 03 '16 00:03 zerog2k

Other protocols definitely won't work, not much use trying. The BSL/bootloader on your device requires stc15.

If flashing works with the VM, maybe you can get a dump of the serial traffic? Maybe there's something special about your device.

Mar 03 '16 12:03 grigorig

Hey all,

I'm having similar issues with my setup.

Linux, CH340 UART, pySerial 3.0.1. I don't have any alternative UARTs at the moment unless I can figure out how to make this work with a bus pirate.

I've tried different baud rates from 9600 to 57600, matching handshake and protocol baud, and the alternative stc12a protocol. Haven't found any combination that works so far.

Is it possible to write protect STC MCUs?

Waiting for MCU, please cycle power: done
Target model:
  Name: STC12C5204AD
  Magic: E164
  Code flash: 4.0 KB
  EEPROM flash: 2.0 KB
Target frequency: 11.981 MHz
Target BSL version: 6.6H
Target options:
  reset_pin_enabled=True
  low_voltage_reset=True
  oscillator_stable_delay=32768
  por_reset_delay=short
  clock_gain=high
  clock_source=external
  watchdog_por_enabled=False
  watchdog_stop_idle=True
  watchdog_prescale=64
  eeprom_erase_enabled=False
  bsl_pindetect_enabled=False
Loading flash: 104 bytes (Intel HEX)
Switching to 19200 baud: Serial port error: read timeout

Mar 18 '16 06:03 rfb

@rfb This problem does not seem to be related, please open a separate issue. The stc12 protocol is quite a bit different. That said, the current Linux driver for ch340 is very buggy. I have several improvements lined up that I'm going to submit for inclusion in the Linux kernel as I have a number of these UARTs. If you are willing to try compiling a Linux kernel with these improvements, I can forward a patch set or publish a branch.

Mar 18 '16 08:03 grigorig

Thanks @girgoirg, I'll open another ticket.

Yes, I'm happy to try one of the kernel patches.

Mar 18 '16 15:03 rfb

@Mrnt any changes with the current version of stcgal? Perhaps try with another UART, updated drivers or Linux.

May 14 '16 23:05 grigorig

@grigorig sorry for the delay in responding. I pulled the latest stcgal and then also set it up on my Windows VM and tried using it to flash from the Windows VM. The good news is that using the same version of pyserial with the same USB/serial adapter, stc gal worked under Windows VM. However it still does not work under OSX for some reason, I even tried updated Prolific drivers for OSX.

I noticed that the info packet when using stcgal under the Windows VM is slightly different than under OSX which seems odd to me. I'm including the debug output here to see if this makes any sense to you:

***** WINDOWS start ***** python ../STCgal_uploader_forT5board/stcgal.py -D -p COM3 -P stc15 main.ihx Waiting for MCU, please cycle power: <- Packet data: FE <- Packet data: 44 <- Packet data: FE <- Packet data: 64 <- Packet data: 46 B9 68 00 34 50 67 6F 87 A9 F7 BA 9F 00 A8 91 20 FD 25 FE 0A 00 72 53 00 F4 84 04 06 70 A9 02 14 19 1C 1E 1E 00 F4 80 04 DC FF 86 BF FF FF 15 06 05 51 1 3 B3 16 done Target model: Name: STC15L2K32S2 Magic: F484 Code flash: 32.0 KB EEPROM flash: 29.0 KB Target frequency: 11.047 MHz Target BSL version: 7.2.4S Target wakeup frequency: 26.479 KHz Target options: reset_pin_enabled=False clock_source=internal clock_gain=high watchdog_por_enabled=False watchdog_stop_idle=True watchdog_prescale=256 low_voltage_reset=True low_voltage_threshold=2 eeprom_lvd_inhibit=True eeprom_erase_enabled=False bsl_pindetect_enabled=False por_reset_delay=long rstout_por_state=high uart2_passthrough=False uart2_pin_mode=normal cpu_core_voltage=unknown Loading flash: 5925 bytes (Intel HEX) Trimming frequency: -> Packet data: 46 B9 6A 00 20 00 0C 00 C0 80 C0 FF C0 00 80 80 80 FF 80 00 40 80 40 FF 40 00 00 80 00 C0 00 0A D3 16 <- Packet data: 46 B9 68 00 20 00 0C 0C 95 11 FE 17 67 18 ED 23 74 2D F1 32 BF 47 5A 5B 50 50 38 6F 4B 7E 41 09 BA 16 -> Packet data: 46 B9 6A 00 20 00 0C 83 80 84 80 85 80 86 80 87 80 88 80 81 40 82 40 83 40 84 40 85 40 86 40 0B 4C 16 <- Packet data: 46 B9 68 00 20 00 0C 23 B5 23 D3 23 E7 24 00 24 14 24 14 47 87 47 AF 47 D2 48 09 48 36 48 5E 08 52 16 11.059 MHz Switching to 19200 baud: -> Packet data: 46 B9 6A 00 0E 01 84 40 FE DF FE 4F 81 04 E8 16 <- Packet data: 46 B9 68 00 07 01 00 70 16 -> Packet data: 46 B9 6A 00 0B 05 00 00 5A A5 01 79 16 <- Packet data: 46 B9 68 00 07 05 00 74 16 done ...flash programming starts and successfully completes... ***** WINDOWS end *****

***** OSX start ***** python3.5 ../STCgal_uploader_forT5board/stcgal.py -D -p /dev/cu.usbserial -P stc15 main.ihx Waiting for MCU, please cycle power: <- Packet data: 4A <- Packet data: 8C <- Packet data: 48 <- Packet data: 40 <- Packet data: 2A <- Packet data: B4 <- Packet data: FE <- Packet data: 8D <- Packet data: 46 B9 68 00 34 50 67 6F 87 A9 F7 BA 9F 00 A8 C0 00 FD 28 01 0A 00 72 53 00 F4 84 04 06 70 A9 02 14 19 1C 1E 1E 00 F4 80 04 DC FF 86 BF FF FF 15 06 05 51 12 C8 16 done Target model: Name: STC15L2K32S2 Magic: F484 Code flash: 32.0 KB EEPROM flash: 29.0 KB Target frequency: 11.059 MHz Target BSL version: 7.2.4S Target wakeup frequency: 26.479 KHz Target options: reset_pin_enabled=False clock_source=internal clock_gain=high watchdog_por_enabled=False watchdog_stop_idle=True watchdog_prescale=256 low_voltage_reset=True low_voltage_threshold=2 eeprom_lvd_inhibit=True eeprom_erase_enabled=False bsl_pindetect_enabled=False por_reset_delay=long rstout_por_state=high uart2_passthrough=False uart2_pin_mode=normal cpu_core_voltage=unknown Loading flash: 5925 bytes (Intel HEX) Trimming frequency: -> Packet data: 46 B9 6A 00 20 00 0C 00 C0 80 C0 FF C0 00 80 80 80 FF 80 00 40 80 40 FF 40 00 00 80 00 C0 00 0A D3 16 <- Packet data: FE Protocol error: incorrect frame start -> Packet data: 46 B9 6A 00 07 82 00 F3 16 Disconnected! ***** OSX end *****

May 24 '16 22:05 Mrnt

Thanks, that is valuable feedback. The slight differences in the info packet are fine. The info packet includes some timing measurements based on the serial baudrate. These are used to determine the clock frequency of the MCU. Clocks of both serial adapter and MCU jitter and depend on operating conditions, so these differences are expected.

Of course it is rather unfortunate that there is an incompatibility with OS X. Maybe I can ask some of my colleagues with Mac computers to get this fixed. If I have anything specific for you to test, I'll post it here.

May 24 '16 23:05 grigorig

I am also having this issue on OSX using a Prolific adapter. No joy at all with an FTDI adapter.

Johns-MacBook-Pro:stc_diyclock john$ stcgal -p /dev/cu.usbserial -b 115200 -b 9600 -l 9600 main.hex Waiting for MCU, please cycle power: done Protocol detected: stc15 Target model: Name: STC15W404AS Magic: F51E Code flash: 4.0 KB EEPROM flash: 9.0 KB Target frequency: 11.069 MHz Target BSL version: 7.2.5T Target wakeup frequency: 37.087 KHz Target options: reset_pin_enabled=False clock_source=internal clock_gain=high watchdog_por_enabled=False watchdog_stop_idle=True watchdog_prescale=256 low_voltage_reset=True low_voltage_threshold=3 eeprom_lvd_inhibit=True eeprom_erase_enabled=False bsl_pindetect_enabled=False por_reset_delay=long rstout_por_state=high uart2_passthrough=False uart2_pin_mode=normal cpu_core_voltage=unknown Loading flash: 4372 bytes (Intel HEX) WARNING: code_image overflows into eeprom segment! Trimming frequency: Serial port error: pulse timeout

Jun 15 '17 20:06 JohnOH

Can you please try again with the dump option (-D)? I have a hunch it's related to baud rate changes, but I'd like to verify.

Jun 16 '17 07:06 grigorig

Thanks for the swift response:

Johns-MacBook-Pro:stc_diyclock john$ stcgal -p /dev/cu.usbserial -D -b 9600 -l 9600 main.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 90 DF 79 9B F7 BB 9F 00 A8 E5 80 FD 09 C8 DF FF 72 54 00 F5 1E 05 06 70 9B 02 1B 20 23 26 2D 00 34 10 04 DD EC 7A BF FF FF 16 12 09 40 14 D4 16 done Protocol detected: stc15 Target model: Name: STC15W404AS Magic: F51E Code flash: 4.0 KB EEPROM flash: 9.0 KB Target frequency: 11.069 MHz Target BSL version: 7.2.5T Target wakeup frequency: 37.087 KHz Target options: reset_pin_enabled=False clock_source=internal clock_gain=high watchdog_por_enabled=False watchdog_stop_idle=True watchdog_prescale=256 low_voltage_reset=True low_voltage_threshold=3 eeprom_lvd_inhibit=True eeprom_erase_enabled=False bsl_pindetect_enabled=False por_reset_delay=long rstout_por_state=high uart2_passthrough=False uart2_pin_mode=normal cpu_core_voltage=unknown Loading flash: 4372 bytes (Intel HEX) WARNING: code_image overflows into eeprom segment! Trimming frequency: -> Packet data: 46 B9 6A 00 20 00 0C 00 C0 80 C0 FF C0 00 80 80 80 FF 80 00 40 80 40 FF 40 00 00 80 00 C0 00 0A D3 16 Serial port error: pulse timeout Johns-MacBook-Pro:stc_diyclock john$

Jun 16 '17 07:06 JohnOH

Scratch that, baud rate changes only happen later. I suspect it's some buffering issue with OSX drivers or pyserial. Can you try these workarounds:

Increase the sleep interval in StcBaseProtocol.pulse in protocols.py
Alternatively, reduce sleep interval
Try commit 3ce6b565

Jun 16 '17 07:06 grigorig

Something else to try:

Set the pulse character in StcBaseProtocol.pulse to 0xfe instead of 0x7f.

Jun 16 '17 07:06 grigorig

I am not sure I have made the correct change. I have changed line 163 in protocols.py to:

def pulse(self, character=b"\0xfe", timeout=0):

AFter doing this i get streams of characters:

<- Packet data: FC <- Packet data: FC

This continues and the request to power cycle the processor doesn't wait. The particular character output varies depending on the baud rate selected by -b. The above at 9600 and below at 19200 default.

Johns-MacBook-Pro:stc_diyclock john$ stcgal -p /dev/cu.usbserial -D main.hex Waiting for MCU, please cycle power: <- Packet data: C0 <- Packet data: FE <- Packet data: 80 <- Packet data: FE <- Packet data: 80 <- Packet data: FE <- Packet data: 80 <- Packet data: FE <- Packet data: 80 <- Packet data: FE <- Packet data: 80 <- Packet data: FE <- Packet data: 80 <- Packet data: FE <- Packet data: 80 <- Packet data: FE <- Packet data: 80 <- Packet data: FE <- Packet data: 80 <- Packet data: FE

Jun 16 '17 07:06 JohnOH

the above using your osx-fix branch.

Jun 16 '17 20:06 JohnOH

I have loaded up stcgal on a Win7 machine to prove the stc15w408as hardware. The hardware is good and I can program the chip under Win7. Still unable to program using OSX.

Jun 30 '17 13:06 JohnOH

if using pl2303 on mac, are you sure it's geniune pl2303? I have seen some problems with clone chipsets while working on chirp project...

(I guess the deciding factor is if you had to rollback the prolific driver on win7 to a previous version to get it to work)

Some notes here: http://chirp.danplanet.com/projects/chirp/wiki/MacOS_Tips#Generic-PL-2303-cables-counterfeit-andor-%E2%80%9CGeneric%E2%80%9D-If-you-arent-sure-what-kind-of-inexpensive-cable-you-have-try-this-one-first

Unsure if this is valid for later versions of macos...

Jun 30 '17 22:06 zerog2k

Oh, interesting @zerog2k. I hope it's a driver issue because the dumps don't make much sense.

Jul 03 '17 02:07 grigorig

I have tried the the open driver and still have an issue. I have also tried with two FTDI serial adapters and can't get past "Waiting for MCU, please cycle power: " with those two.

I have finally located an English version of STC-ISP, again only Windows but it does allow setting the clock speed to 22.1184 Mhz which doesn't appear possible with the -t command.

Johns-MacBook-Pro:stc-led-clock john$ stcgal -D -p /dev/cu.usbserial main.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 93 A3 77 9F F7 BB 9F 01 51 B8 40 FD 27 05 04 01 72 54 00 F5 1F 05 06 70 9F 02 10 16 19 1A 21 00 34 20 04 DF EC 77 7F FF FF 17 02 09 40 10 EA 16 done Protocol detected: stc15 Target model: Name: STC15W408AS Magic: F51F Code flash: 8.0 KB EEPROM flash: 5.0 KB Target frequency: 22.133 MHz Target BSL version: 7.2.5T Target wakeup frequency: 37.795 KHz Target options: reset_pin_enabled=False clock_source=internal clock_gain=high watchdog_por_enabled=False watchdog_stop_idle=True watchdog_prescale=256 low_voltage_reset=True low_voltage_threshold=3 eeprom_lvd_inhibit=True eeprom_erase_enabled=False bsl_pindetect_enabled=False por_reset_delay=long rstout_por_state=high uart2_passthrough=False uart2_pin_mode=normal cpu_core_voltage=unknown Loading flash: 3927 bytes (Intel HEX) Trimming frequency: -> Packet data: 46 B9 6A 00 20 00 0C 00 C0 80 C0 FF C0 00 80 80 80 FF 80 00 40 80 40 FF 40 00 00 80 00 C0 00 0A D3 16 Serial port error: pulse timeout

Jul 03 '17 14:07 JohnOH

curious, can you run wine on your mac? I was able to run the stc-isp windows tool on wine on mac successfully, and may be useful to establish whether the serial port driver/setup on your mac is functional vs some bug in stcgal.

Their latest stc-isp software in english is here: http://www.stcmcu.com/STCISP/stc-isp-15xx-v6.86c.zip (firefox has been complaining that they might have "unwanted software" for a while... I'm not sure if there is any issue with it - can't vouch for them...)

Jul 03 '17 14:07 zerog2k

I have just installed VirtualBox on my Mac and loaded a copy of Win7. STC-ISP works OK.

Jul 03 '17 15:07 JohnOH

again only Windows but it does allow setting the clock speed to 22.1184 Mhz which doesn't appear possible with the -t command.

That should work fine. Note that you need to specify the clock in KHz, not MHz.

Anyway, I'm not sure this is just one issue. There appears to be driver trouble, or something along these lines, with various serial adapters on OSX. On the other hand, it's possible that the new firmware/BSL (7.2.5) has some incompatibilities as well, so stcgal needs to be updated.

I'll order some new chips. If I get chips with the new BSL, it should be possible to update stcgal.

It might also help if you can provide dumps of the serial port traffic when running with STC-ISP (where everything seems to work for you).

Jul 03 '17 19:07 grigorig

If I remember correctly, there are some problems with some usb-serial drivers, when switching baudrate. It brought me a LOT of pain when i was hacking my own stc programming solution. The problem behind it is that the kernel driver switches the baudrate BEFORE all bytes are out of the hardware fifo. This can be easily picked by a logic analyzer.

The workarounds are:

Use the same handshake and upload baudrate (slow!)
Calculate and insert an artificial delay before switching the baudrate, so that all bytes are out of the fifo.
Fix the damned driver ;)

@grigorig - FYI this is my implementation of the hack: https://github.com/nekromant/stcdude/blob/7af99a6dcea2e5b721398cf36ed6e955f455e06a/src/stcdude.c#L85 this may need to be adjusted a bit to be ported to stcgal. i'll see if i find one of those 'broken' serial dongles to give it a spin.

Oct 08 '17 11:10 nekromant

I don't like such hacks, but with all these various issues, it seems like a good idea to implement such a delay. Thanks for the pointer.

Oct 08 '17 15:10 grigorig

@grigorig The worst part of this hack is, that it has to be applied either manually (thus spoiling user experience), or to certain combinations of usb2uart dongles/OS (even OS versions), and that's another list to maintain. ;(

The delay calculated in stcdude's code should be okay for CP2103 and linux (If I'm not mistaken, it's been some 4 years already).

Oct 08 '17 20:10 nekromant

stcgal stcgal copied to clipboard

Unable to upload to STC15L2K32S2

stcgal
stcgal copied to clipboard