STC15F104w new BSL version?

[Phil67ago]

Hi!

I recently order some new 15F104W. I can't program these items. BSL version has changed from 7.1Q to 7.2.5Q Target frequency is 0.000 MHz vs 92.056 MHz Package data is 9 bytes longer Using latest git (pull 2016-07-09)

New STC15F104W: stcgal -p /dev/ttyUSB0 -D -P stc15 binary.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 92 22 95 B6 F5 7B 9F FF FF FF FF FF 26 38 00 00 72 51 03 F2 94 05 06 70 B6 02 1F 24 25 29 27 80 14 10 04 D0 FF B6 7F FF FF 16 03 31 01 14 7F 16 done Target model: Name: STC15F104W Magic: F294 Code flash: 4.0 KB EEPROM flash: 1.0 KB Target frequency: 0.000 MHz Target BSL version: 7.2.5Q Target wakeup frequency: 37.410 KHz Target options: reset_pin_enabled=False clock_source=internal clock_gain=high watchdog_por_enabled=False watchdog_stop_idle=True watchdog_prescale=64 low_voltage_reset=False low_voltage_threshold=3 eeprom_lvd_inhibit=False eeprom_erase_enabled=True 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: 2071 bytes (Intel HEX) Protocol error: uncalibrated, please provide a trim value -> Packet data: 46 B9 6A 00 07 82 00 F3 16 Disconnected!

Previous STC15F104W: (see issue 6: (here)) stcgal -p /dev/ttyUSB0 -D -P stc15 binary.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 2B 50 91 C5 92 B5 F7 BB 9F 00 A8 C9 60 FF 4E 78 69 6E 71 51 03 F2 94 04 06 58 B5 02 1B 20 22 26 22 80 14 10 04 CF 0F BE 16 done Target model: Name: STC15F104W Magic: F294 Code flash: 4.0 KB EEPROM flash: 1.0 KB Target frequency: 92.056 MHz Target BSL version: 7.1Q Target options: reset_pin_enabled=False watchdog_por_enabled=False watchdog_stop_idle=True watchdog_prescale=64 low_voltage_reset=True low_voltage_threshold=0 eeprom_lvd_inhibit=False eeprom_erase_enabled=True bsl_pindetect_enabled=True Loading flash: 583 bytes (Intel HEX) ....

/Phil

[zerog2k]

Have you tried -P stc15a

Edit: nm sorry I see this was a continuation of the last issue, and that sage advice also didn't work :) Strange though that I have same magic with stc15f204ea, and requires stc15a

[Phil67ago]

Strange! got Target BSL version: 7.2Q

stcgal -p /dev/ttyUSB0 -D -P stc15a binary.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 92 22 95 B6 F5 7B 9F FF FF FF FF FF 26 33 00 00 72 51 03 F2 94 05 06 70 B6 02 1F 24 25 29 27 80 14 10 04 D0 FF B6 7F FF FF 16 03 31 01 14 7A 16 done Target model: Name: STC15F104W Magic: F294 Code flash: 4.0 KB EEPROM flash: 1.0 KB Target frequency: 184.668 MHz Target BSL version: 7.2Q Target options: reset_pin_enabled=False watchdog_por_enabled=False watchdog_stop_idle=True watchdog_prescale=128 low_voltage_reset=True low_voltage_threshold=0 eeprom_lvd_inhibit=False eeprom_erase_enabled=True bsl_pindetect_enabled=True Loading flash: 2071 bytes (Intel HEX) Trimming frequency: -> Packet data: 46 B9 6A 00 0D 50 00 00 36 01 F2 94 02 84 16 <- Packet data: 00 Protocol error: incorrect frame start -> Packet data: 46 B9 6A 00 07 82 00 F3 16 Disconnected!

[grigorig]

It's a new chip, so the RC clock is uncalibrated and you have to provide a target frequency for calibration. stcgal tells you this in the error message. Please try again (with stc15 as protocol or autodetection, stc15a is definitely incorrect!) and specify a trim value with -t. Maybe the error message isn't quite clear?

I'm not quite sure why you see that strange high clock speed for your old STC15F104W chip. That's odd!

[Phil67ago]

Hi, I were unaware of the fact of the need to setup the internal oscillator!! Previous items were already programmed before. Maybe the option -t TRIM is unclear. I interpreted it as trim the oscillator frequency +/- x Khz in float and didn't know what to enter. When reading README.md now it's much more clear!

But I can't program these items with -t! Even STC-ISP V6.28 can't do it.

---

stcgal -p /dev/ttyUSB0 -D -t 24971 binary.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 92 86 88 A8 F5 7B 9F FF FF FF FF FF 28 27 00 00 72 51 03 F2 94 05 06 70 A8 02 1E 25 27 2A 22 80 14 10 04 CA FF A8 7F FF FF 16 03 31 01 14 95 16 done Protocol detected: stc15 Target model: Name: STC15F104W Magic: F294 Code flash: 4.0 KB EEPROM flash: 1.0 KB Target frequency: 0.000 MHz Target BSL version: 7.2.5Q Target wakeup frequency: 37.510 KHz Target options: reset_pin_enabled=False clock_source=internal clock_gain=high watchdog_por_enabled=False watchdog_stop_idle=True--------- watchdog_prescale=64 low_voltage_reset=False low_voltage_threshold=3 eeprom_lvd_inhibit=False eeprom_erase_enabled=True 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: 2071 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 48 11 93 16 ED 18 D2 23 63 2D EF 32 AE 47 A3 5C 2A 4F EB 6F 8F 7E BC 0A DD 16 -> Packet data: 46 B9 6A 00 20 00 0C B9 40 BA 40 BB 40 BC 40 BD 40 BE 40 7F 40 80 40 81 40 82 40 83 40 84 40 0B 04 16 <- Packet data: 46 B9 68 00 20 00 0C 50 F4 51 17 51 44 51 76 51 9E 51 C1 47 C1 47 A3 47 CB 47 F8 48 1B 48 52 0A DD 16 24.965 MHz Switching to 19200 baud: -> Packet data: 46 B9 6A 00 0E 01 82 40 FB 7F BB 40 81 04 31 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: 00 Protocol error: incorrect frame start -> Packet data: 46 B9 6A 00 07 82 00 F3 16 Disconnected!

---

With STC-ISP (v6.28):

Checking target MCU ... MCU type: STC15F104W F/W version: 7.2Q

Current H/W Option: . IRC is unadjusted . Wakeup Timer frequency: 37.510KHz . Do not detect the level of P3.2 and P3.3 next download . Power-on reset, use the extra power-on delay . RESET pin behaves as I/O pin . Interrupt while detect a Low-Voltage . Thresh voltage level of the built-in LVD : 3.82 V . Permit EEPROM operation under Low-Voltag . Hardware do not enable Watch-Dog-Timer . Watch-Dog-Timer pre-scalar : 64 . Watch-Dog-Timer stop count in idle mode . Program can modify the Watch-Dog-Timer scalar . Do not erase user EEPROM area at next download . Do not control 485 at next download . TXD is independent IO . TXD pin as quasi-bidirectional mode after reset . P3.3 output HIGH level after reset

MCU type: STC15F104W

Adjusting frequency ... [0.938"] Adjusted frequency: 29.999MHz (-0.004%)

Re-handshaking ... Successful [0.141"] Current Baudrate: 57600 Erasing MCU flash ...
No response, download failed !

---

It could either be something wrong with items I got. Or something with the USB/RS232/TTL this Same USB/RS232/TTL worked last time!

I start to suspect these items not are original items. Marking is slightly different: STC (not cursive) 15F104W HKF089.BAD (nothing on backside) Items are from aliexpress.com.... New ones are on the way now.

[zerog2k]

Have you tried latest 6.85 Stc isp?

[grigorig]

Huh, apparently the baudrate handshake and everything works fine, but then the device doesn't like the packet that unlocks the flash memory. Before jumping to conclusions I'd try the latest STC-ISP as well. And if that works, it should be easy to see what need to be changed.

[Phil67ago]

Ok, at last I got it working with the latest STC-ISP V6.85O. The flash sequence did stop some times at 15% (once) and 85% ( ~5 times) Can I provide a dump/trace of the protocol (USB/TTL) STC-ISP using? And if so, how?

[zerog2k]

you mean even with the official stc-isp, the flash was still flakey (failing/hanging sometimes) or did it just stall, but eventually complete?

Does the flash with stcgal work now (after having been programmed at least once with stc-isp)?

Just curious - Where did you get the chips from (which aliexpress seller)?

[Phil67ago]

Yes with the one in the link above (offical I think), one time at 15% (once) and five times at 85% ( ~5 times). No I have not test stcgal after I succeeded with STC-ISP This seller jiaxiang IC Integrated circuit Shop but he has no more left (picture is wrong)

[grigorig]

I seriously doubt anyone is going to fake STC MCUs... not worth the effort, they are too cheap already.

Anyway, there are various ways to capture serial port traffic on Windows with software. I think Portmon still works? If you can capture a programming procedure with this that would be great.

[Phil67ago]

Ok, here are some files.... If you need more please let me know.

Check MCU-short.txt ProgOk1-short.txt ProgTimeout1-short.txt

[grigorig]

Thank you for the data. That doesn't look unusual on first look. What happens if you change the baud rate with -b? Try something higher, like 38400, or something lower, like 9600. Also, please try to revert commit 53f95442810c8f074b518bd2e2db6508d7106604.

[Phil67ago]

No 9600/19200/38400 same as below:

---

stcgal -p /dev/ttyUSB0 -b 38400 -D -t 11.057 binary.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 92 86 88 A8 F7 BB 9F 00 A8 CE 10 FD 28 27 F7 FF 72 51 03 F2 94 05 06 70 A8 02 1E 25 27 2A 22 80 14 10 04 CA FF 88 BF FF FF 16 03 31 01 14 75 16 done Protocol detected: stc15 Target model: Name: STC15F104W Magic: F294 Code flash: 4.0 KB EEPROM flash: 1.0 KB Target frequency: 11.063 MHz Target BSL version: 7.2.5Q Target wakeup frequency: 37.510 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: 2071 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 4D 11 8E 16 E8 18 D2 23 63 2D EF 32 A9 47 A3 5C 25 4F EB 6F 80 7E BC 0A BF 16 Protocol error: frequency trimming unsuccessful -> Packet data: 46 B9 6A 00 07 82 00 F3 16 Disconnected!

[grigorig]

You get frequency trimming unsuccessful because you try to set a frequency of approximately 11 kHz... and that's outside the range that is possible. Please specify the target frequency in KHz, not MHz.

[Phil67ago]

Oh, Sorry for that!!! But things is not going my way.... Tried 9600/19200/38400

---

stcgal -p /dev/ttyUSB0 -b 9600 -D -t 11057 binary.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 92 86 88 A8 F7 BB 9F 00 A8 CE 10 FD 28 22 00 00 72 51 03 F2 94 05 06 70 A8 02 1E 25 27 2A 22 80 14 10 04 CA FF 88 BF FF FF 16 03 31 01 12 7A 16 done Protocol detected: stc15 Target model: Name: STC15F104W Magic: F294 Code flash: 4.0 KB EEPROM flash: 1.0 KB Target frequency: 11.063 MHz Target BSL version: 7.2.5Q Target wakeup frequency: 37.510 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: 2071 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 48 11 93 16 E3 18 CD 23 5E 2D E5 32 A4 47 99 5C 16 4F E6 6F 80 7E B7 0A 7E 16 -> Packet data: 46 B9 6A 00 20 00 0C 85 80 86 80 87 80 88 80 89 80 8A 80 7F 40 80 40 81 40 82 40 83 40 84 40 0B 4C 16 <- Packet data: 46 B9 68 00 20 00 0C 23 C7 23 E0 23 F4 24 03 24 17 24 2B 47 B2 47 99 47 C1 47 E4 48 0C 48 43 09 34 16 11.063 MHz Switching to 9600 baud: -> Packet data: 46 B9 6A 00 0E 01 83 40 F6 FF 88 80 81 04 BA 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 Serial port error: read timeout

[grigorig]

Can you provide a log with 38400 baud, the same used in the STC-ISP logs you provided before? That could be helpful to compare both cases.

[Phil67ago]

Ok! Here we go...

---

stcgal -p /dev/ttyUSB0 -b 38400 -D binary.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 92 86 88 A8 F7 BB 9F 00 A8 CE 10 FD 28 22 00 00 72 51 03 F2 94 05 06 70 A8 02 1E 25 27 2A 22 80 14 10 04 CA FF 88 BF FF FF 16 03 31 01 12 7A 16 done Protocol detected: stc15 Target model: Name: STC15F104W Magic: F294 Code flash: 4.0 KB EEPROM flash: 1.0 KB Target frequency: 11.063 MHz Target BSL version: 7.2.5Q Target wakeup frequency: 37.510 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: 2071 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 48 11 93 16 E8 18 D7 23 5E 2D EF 32 A9 47 9E 5C 25 4F E6 6F 85 7E BC 0A BA 16 -> Packet data: 46 B9 6A 00 20 00 0C 85 80 86 80 87 80 88 80 89 80 8A 80 7F 40 80 40 81 40 82 40 83 40 84 40 0B 4C 16 <- Packet data: 46 B9 68 00 20 00 0C 23 CC 23 E5 23 F4 24 08 24 1C 24 35 47 BC 47 9E 47 CB 47 F3 48 1B 48 52 09 98 16 11.069 MHz Switching to 38400 baud: -> Packet data: 46 B9 6A 00 0E 01 82 40 FD BF 88 80 81 04 80 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 Serial port error: read timeout

---

stcgal -p /dev/ttyUSB0 -b 38400 -t 11057 -P stc15 -D binary.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 92 86 88 A8 F7 BB 9F 00 A8 CE 10 FD 26 24 00 00 72 51 03 F2 94 05 06 70 A8 02 1E 25 27 2A 22 80 14 10 04 CA FF 88 BF FF FF 16 03 31 01 12 7A 16 done Target model: Name: STC15F104W Magic: F294 Code flash: 4.0 KB EEPROM flash: 1.0 KB Target frequency: 11.063 MHz Target BSL version: 7.2.5Q Target wakeup frequency: 37.510 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: 2071 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 48 11 8E 16 E8 18 D2 23 59 2D EA 32 A4 47 9E 5C 1B 4F E1 6F 7B 7E B2 0A 7E 16 -> Packet data: 46 B9 6A 00 20 00 0C 85 80 86 80 87 80 88 80 89 80 8A 80 7F 40 80 40 81 40 82 40 83 40 84 40 0B 4C 16 <- Packet data: 46 B9 68 00 20 00 0C 23 CC 23 E0 23 F4 24 03 24 17 24 30 47 BC 47 9E 47 C1 47 EE 48 16 48 4D 09 6B 16 11.063 MHz Switching to 38400 baud: -> Packet data: 46 B9 6A 00 0E 01 82 40 FD BF 88 80 81 04 80 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 Serial port error: read timeout

[grigorig]

@Phil67ago I know it's been quite a long time, but can you possibly send me one of the affected device by mail (to Germany)? I bought some, but still got the old ones.

[Edragon]

Switching to 38400 baud: Protocol error: incorrect frame start :( same

[HairyPi]

I notice this issue is old but still open, hopefully the following can help: I found this GitHub thread while researching the STC15F104W that i purchased on impulse along with other items from electrodragon. You might find their wiki page on 8051 interesting, it suggests to use a really slow baud rate 1200!! yep that low? haven't received my order quite yet but will be trying this out first before raising the baud :) Good luck.

http://www.electrodragon.com/w/8051 ... Flash in Linux use stcgal: python stcgal.py -P stc15 led.hex -b 1200, stc15 can only work on a low speed ... https://github.com/Edragon/51/blob/master/stc/STC15-English.pdf - a great reference for their chips if like me you have trouble with chinese

[Edragon]

It can work, but the best options is use the latest version flash tool from STC, otherwise old version english also can work, but not support latest ICs.

[grigorig]

That's interesting if only 1200 baud works, points to a possible issue with the baud rate calculations. Maybe I should try again to get hold of these chips with new firmware.

[grigorig]

Note: all my STC15 chips work fine with high baud rates, up 115200.

[tilator]

Hi, Is it possible to backup STC15F104w somehow?

[marcan]

I have a similar issue with an STC15L101W (BSL 7.2.5Q). 1200 baud mode works, though I haven't actually gotten a flashed program to work yet (but this may be a different problem).

[marcan]

Yup, works fine once I got my program in order. So there's something weird about the baud switching / trimming, but at 1200 baud it happens to work.

[mrdudz]

i also have this issue here... interestingly, out of 8 pieces i tried to program, 5 work fine with stcgal, 3 do not (but i can programm them with the windows tool). even after succesfully programming them on windows, those 3 will still not work with stc-gal (so its not the initial setup). no idea wth the problem could be. if i can help somehow, let me know - that windows tool is so terrible, i am out of words, no way i am using that for daily work :)

[pilol34]

I have a solution for the STC15F104W device problem, because I modified line 1399 of the protocol.py file and reinstall. Now it works up to 38400 baud. OLD 1399 packet += bytes(user_trim) NEW 1399 packet += struct.pack(">H", int(65535 - program_speed / 2 * 3 / bauds)) if (self.mcu_magic >> 8) == 0xf2 else bytes(user_trim)

[PSLLSP]

I confirm that patch from user pilol34 works. This is a patch, please, apply:

diff --git a/stcgal/protocols.py b/stcgal/protocols.py
index 6ce408a..d535638 100644
--- a/stcgal/protocols.py
+++ b/stcgal/protocols.py
@@ -1396,7 +1396,7 @@ class Stc15Protocol(Stc15AProtocol):
         # This is a bit of a hack, but it works.
         bauds = self.baud_transfer if (self.mcu_magic >> 8) == 0xf2 else self.baud_transfer * 4
         packet += struct.pack(">H", int(65535 - program_speed / bauds))
-        packet += bytes(user_trim)
+        packet += struct.pack(">H", int(65535 - program_speed / 2 * 3 / bauds)) if (self.mcu_magic >> 8) == 0xf2 else bytes(user_trim)
         iap_wait = self.get_iap_delay(program_speed)
         packet += bytes([iap_wait])
         self.write_packet(packet)

stcgal that is in PIP3 repository ($ pip3 install -U stcgal); it cannot upload firmware to STC15104W:

$ stcgal -V
stcgal 1.6

$ stcgal -p /dev/ttyUSB2 blinky3.ihx 
Waiting for MCU, please cycle power: done
Protocol detected: stc15
Target model:
  Name: STC15F104W
  Magic: F294
  Code flash: 4.0 KB
  EEPROM flash: 1.0 KB
Target frequency: 11.057 MHz
Target BSL version: 7.2.5Q
Target wakeup frequency: 35.907 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: 211 bytes (Intel HEX)
Trimming frequency: 11.051 MHz
Switching to 19200 baud: Serial port error: read timeout

stcgal modified with a patch described before:

$ ../stcgal/stcgal.py -p /dev/ttyUSB2 blinky3.ihx 
Waiting for MCU, please cycle power: done
Protocol detected: stc15
Target model:
  Name: STC15F104W
  Magic: F294
  Code flash: 4.0 KB
  EEPROM flash: 1.0 KB
Target frequency: 11.057 MHz
Target BSL version: 7.2.5Q
Target wakeup frequency: 35.907 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: 211 bytes (Intel HEX)
Trimming frequency: 11.051 MHz
Switching to 19200 baud: done
Erasing flash: done
Writing flash: 576 Bytes [00:00, 1487.02 Bytes/s]                                                                                                      
Finishing write: done
Setting options: done
Target UID: F29424D610AAC9
Disconnected!

Simple kit with STC15F104W that I use to test this issue... https://www.aliexpress.com/item/4000560952377.html

[qiwenmin]

I have a solution for the STC15F104W device problem, because I modified line 1399 of the protocol.py file and reinstall. Now it works up to 38400 baud. OLD 1399 packet += bytes(user_trim) NEW 1399 packet += struct.pack(">H", int(65535 - program_speed / 2 * 3 / bauds)) if (self.mcu_magic >> 8) == 0xf2 else bytes(user_trim)

This patch works for me (stc15w104)! Thanks!

[markuspi]

The patch solved the same problem on my STC15F101W. Thanks! Are you planning to make a pull request with this patch? It would be really useful.

[grigorig]

This is quite weird... I'd appreciate a dump of a programming cycle of STC-ISP.

Any idea what that value programmed does? My first guess would be that it influences sampling of the software UART when receiving data.

I just ordered an STC15F104W board locally. If everything goes well I should be able to look into this next weekend.

[PSLLSP]

I agree, something is wrong. The latest stcgal from git doesn't work, it ends with an error Switching to 19200 baud: Serial port error: read timeout. This is not a surprise, it was not working in the past...

$ ./stcgal.py -p /dev/ttyUSB2 blinky3.ihx

Waiting for MCU, please cycle power: done
Protocol detected: stc15
Target model:
  Name: STC15F104W
  Magic: F294
  Code flash: 4.0 KB
  EEPROM flash: 1.0 KB
Target frequency: 11.075 MHz
Target BSL version: 7.2.5Q
Target wakeup frequency: 36.776 KHz
Target options:
  reset_pin_enabled=False
  clock_source=internal
  clock_gain=high
  watchdog_por_enabled=False
  watchdog_stop_idle=True
  watchdog_prescale=64
  low_voltage_reset=False
  low_voltage_threshold=3
  eeprom_lvd_inhibit=False
  eeprom_erase_enabled=True
  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: 211 bytes (Intel HEX)
Trimming frequency: 11.075 MHz
Switching to 19200 baud: Serial port error: read timeout

stcgal with patch from this issue works when I do not touch baud rate:

$ ./stcgal-patched.py -p /dev/ttyUSB2 blinky3.ihx

Waiting for MCU, please cycle power: done
Protocol detected: stc15
Target model:
  Name: STC15F104W
...
Loading flash: 211 bytes (Intel HEX)
Trimming frequency: 11.075 MHz
Switching to 19200 baud: done
Erasing flash: done
Writing flash: 576 Bytes [00:00, 1500.26 Bytes/s]
Finishing write: done
Setting options: done
Target UID: F29424D610AADB
Disconnected!

When I try to force baud rate to 9600 (to capture serial communication), it ends with an error:

$ ./stcgal-patched.py -p /dev/ttyUSB2 -b 9600 -l 9600 blinky3.ihx 

Waiting for MCU, please cycle power: done
Protocol detected: stc15
Target model:
  Name: STC15F104W
...
Trimming frequency: 11.059 MHz
Switching to 9600 baud: Serial port error: read timeout

When I force baud rate 19200, it works...

$ ./stcgal-patched.py -p /dev/ttyUSB2 -b 19200 -l 19200 blinky3.ihx 

I am going to capture STC-ISP communication.

[PSLLSP]

I attach file, with sniff of serial communication. I use 3 USB serial adapters with CH340E chip, first is connected to Windows and this one was used to communicate with STC MCU. Other two serial adapters are connected to Linux box and these monitor RX and TX line, they work in read only mode and store communication to log file. Program jpnevulator is used to monitor these two serial ports.

I attached log from Linux where patched stcgal was forced to communicate at speed 19200 and two files from windows, at speeds 9600 and 19200. The same program was programmed. I started with "chip detect", then I executed "download".

stc15f104w-snff.zip

[grigorig]

Thanks. The stcgal patch actually looks good to me (in comparison to STC-ISP dumps) and it matches my initial reverse engineering notes based on an older STC15L104W chip. Apart from some minor rounding differences, it's similar. I wonder why I didn't implement it correctly according to my own notes before (oops).

The timing constant calculation seems to have a minor off-by-one error though. We probably need to subtract from 65536 instead of 65535. Does it help if you change that? The resulting timings are really close, so I can't imagine that, but let's give it a try.

[grigorig]

I did some testing with the older STC15L104W device I had lying around. Please try MR #62.

[PSLLSP]

I tried to change 65535 to 65536 but it doesn't fix the issue. I can flash MCU at 19200 but it fails when I try 9600. This is the patch:

diff --git a/stcgal/protocols.py b/stcgal/protocols.py
index 6ce408a..e76259b 100644
--- a/stcgal/protocols.py
+++ b/stcgal/protocols.py
@@ -1395,8 +1395,8 @@ class Stc15Protocol(Stc15AProtocol):
         # UART, and we can isolate those with a check on the magic.
         # This is a bit of a hack, but it works.
         bauds = self.baud_transfer if (self.mcu_magic >> 8) == 0xf2 else self.baud_transfer * 4
-        packet += struct.pack(">H", int(65535 - program_speed / bauds))
-        packet += bytes(user_trim)
+        packet += struct.pack(">H", int(65536 - program_speed / bauds))
+        packet += struct.pack(">H", int(65536 - program_speed / 2 * 3 / bauds)) if (self.mcu_magic >> 8) == 0xf2 else bytes(user_trim)
         iap_wait = self.get_iap_delay(program_speed)
         packet += bytes([iap_wait])
         self.write_packet(packet)
@@ -1413,7 +1413,7 @@ class Stc15Protocol(Stc15AProtocol):
         sys.stdout.flush()
         packet = bytes([0x01])
         packet += bytes([self.freq_count_24, 0x40])
-        packet += struct.pack(">H", int(65535 - self.mcu_clock_hz / self.baud_transfer / 4))
+        packet += struct.pack(">H", int(65536 - self.mcu_clock_hz / self.baud_transfer / 4))
         iap_wait = self.get_iap_delay(self.mcu_clock_hz)
         packet += bytes([0x00, 0x00, iap_wait])
         self.write_packet(packet)

[grigorig]

OK. My educated guess for the second timing parameter is that it determines the sampling position after the falling edge of the start bit. Do you have any more luck if you modify the timing parameter? E.g. use "3 4" instead of "2 3".

Please try other baud rates as well.

[grigorig]

I finally good my STC15F104W and my fake (?) FT232 modules.

Here's what I found:

The STC15F104W works well with MR #62 on both CH340 and FTDI UARTs.

However, apparently there's some kind of timing issue. stcgal sleeps for 200 ms after switching the baudrate (the idea is to give the MCU some time to actually settle and switch baudrate before stcgal sends the next packet). Apparently that's too long and sometimes runs into some timeout on the MCU side. I've seen that in particular with high handshake baudrates (makes sense, I guess) such as in your "-l 9600 -b 9600" sample. Reducing the sleep to 100 ms fixes the problem for me.

[grigorig]

So this is finally fixed after a really long time.