Unable to upload to STC15L2K32S2

[Mrnt]

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.

[grigorig]

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.

[zerog2k]

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

[grigorig]

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

[zerog2k]

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...

[Mrnt]

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.

[zerog2k]

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

[grigorig]

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.

[rfb]

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

[grigorig]

@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.

[rfb]

Thanks @girgoirg, I'll open another ticket.

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

[grigorig]

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

[Mrnt]

@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 *****

[grigorig]

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.

[JohnOH]

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

[grigorig]

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.

[JohnOH]

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$

[grigorig]

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 3ce6b56

[grigorig]

Something else to try:

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

[JohnOH]

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

[JohnOH]

the above using your osx-fix branch.

[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.

[zerog2k]

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...

[grigorig]

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

[JohnOH]

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

[zerog2k]

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...)

[JohnOH]

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

[grigorig]

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).

[nekromant]

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.

[grigorig]

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.

[nekromant]

@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).

[grigorig]

Well, or maybe just use a safe default delay that is so high that it'll always work? Well, that would suck. But we don't actually need to wait after sending every packet, like stcdude does it. It's good enough to wait before a baud rate switch or after every byte sent when "pulsing".

Note that the USB protocol support extensively uses the "safe delay" approach: the bootloader won't react to anything over USB while it is flashing, so you have to wait for a "safe" time when flashing a block or you'll just get USB errors.

[grigorig]

Actually there's already a delay in place of 0.2 seconds before every baud rate change after a write. That should be good enough for badly behaved serial drivers even at low baud rates with the typical packet sizes used when switching the baud rate.

[nekromant]

I don't really remember why I've put the delay there, so that it would delay after every packet, most likely it was just a "temporary" hack. I can recommend allowing user to tune the delay via commandline and see if it affects behavior. If I remember correctly, if the delay is too long, things break as well, and that is all baudrate-dependant, hence I've come up with that mostly 'trial-and-error' formula. 0.2 seconds seems like a lot to me.

[grigorig]

Yeah, it might be too long - I'm going to replace it with a calculated delay. That'll also speed up stcgal and that is of course always a plus.

[Drummerboy458]

LwwdeMacBook-Air：桌面lww $ stcgal -a -P stc89 -p /dev/tty.wchusbserial1410 main.ihx -D
循环功率：完成
等待MCU：< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< -分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：57
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< -分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：63
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
<- 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< -分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：5F
< - 分组数据：25
<- 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< -分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：63
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：65
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
<- 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< -分组数据：25
< - 分组数据：21
< - 分组数据：23
< - 分组数据：2F
< - 分组数据：67
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
<- 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< -分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：5F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：21
<- 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< -分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：6F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
<- 分组数据：21
< - 分组数据：21
< - 分组数据：2F
< - 分组数据：67
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< -分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
有人可以帮我这个吗？它不断读取数据。我遇到了与
循环电源相同的问题：等待MCU

[Drummerboy458]

LwwdeMacBook-Air：桌面lww $ stcgal -a -P stc89 -p /dev/tty.wchusbserial1410 main.ihx -D
循环功率：完成
等待MCU：< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< -分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：57
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< -分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：63
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
<- 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< -分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：5F
< - 分组数据：25
<- 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< -分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：63
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：65
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
<- 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< -分组数据：25
< - 分组数据：21
< - 分组数据：23
< - 分组数据：2F
< - 分组数据：67
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
<- 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< -分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：5F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：21
<- 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< -分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：6F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
<- 分组数据：21
< - 分组数据：21
< - 分组数据：2F
< - 分组数据：67
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< -分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
< - 分组数据：2F
< - 分组数据：25
< - 分组数据：21
< - 分组数据：41
有人可以帮我这个吗？它不断读取数据。我遇到了与
循环电源相同的问题：等待MCU

[Drummerboy458]

It just can't stop.What's wrong...555

[yuyi1005]

I think I have pinpointed a possible reason acounting for this issue. I tried STCGAL on an ARM board running linux, and it failed with "Trimming frequency: Serial port error: pulse timeout".

I noticed that the speed of "print" is quite different between ARM board and Desktop Linux, so I added some debug codes as:
frontend.py (176)

            import time
            time_start = time.time()
            self.protocol.initialize(base_protocol)
            time_end = time.time()
            print('Init time: ', time_end - time_start)

Then, I used the same command to run STCGAL on both ARM board and Desktop Linux platforms:
python3 stcgal.py -p /dev/ttyUSB0 -l 115200 -b 115200 -t 24000 -D -e

On ARM board:
Target options:
...
Init time: 0.35816664695739746
Trimming frequency: -> Packet data: 46 B9 6A 00 20 00 0C 00 00 17 00 2E 00 45 00 5C 00 73 00 8A 00 A1 00 B8 00 CF 00 E6 00 FF 00 06 86 16
Serial port error: pulse timeout

On Desktop Linux:
Target options:
...
Init time: 0.007405757904052734
Trimming frequency: -> Packet data: 46 B9 6A 00 20 00 0C 00 00 17 00 2E 00 45 00 5C 00 73 00 8A 00 A1 00 B8 00 CF 00 E6 00 FF 00 06 86 16
<- Packet data: 46 B9 68 00 20 00 0C 00 86 00 8F 00 98 00 A4 00 AA 00 B6 00 BF 00 C8 00 D1 00 DA 00 E0 00 EC 09 43 16
...

By adding a delay to STCGAL on Desktop Linux like this:
frontend.py (176)

            import time
            time_start = time.time()
            self.protocol.initialize(base_protocol)
            time.sleep(0.1)
            time_end = time.time()
            print('Init time: ', time_end - time_start)

then the STCGAL cannot work on Desktop Linux either!

I guess, the "print" function takes too much time on some platforms that the STC chip detects a timeout. I also notice that this timeout tolerance varies with different handshake baudrate. Specifically, the tolerance is about 0.1 second under -l 115200 and about 0.6 second under -l 2400.

Hope my rely can help a bit! @grigorig