search

grigorig / stcgal

Open Source STC MCU ISP flash tool
680 stars 140 forks source link

Unable to upload to STC15L2K32S2 #8

Open Mrnt opened 8 years ago

Mrnt commented 8 years ago

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 commented 8 years ago

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

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

zerog2k commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

grigorig commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

Thanks @girgoirg, I'll open another ticket.

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

grigorig commented 8 years ago

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

Mrnt commented 8 years ago

@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 commented 8 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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:

grigorig commented 7 years ago

Something else to try:

JohnOH commented 7 years ago

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 commented 7 years ago

the above using your osx-fix branch.

JohnOH commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

JohnOH commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

grigorig commented 7 years ago

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 commented 7 years ago

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:

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

yuyi1005 commented 3 years ago

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