STC-ISP Download (v6.96S): Setup, Wiring & the “Checking Target MCU” Fix

You wired up a CH340 module, opened STC-ISP, clicked Download/Program — and the log has been sitting on Checking target MCU ... ever since. Nothing is broken. STC’s 8051 parts only listen for a new program during the first few hundred milliseconds after power-on, so the tool is waiting for you to cut the power and put it back. Here’s the official software, the cold-start sequence in the right order, and the pin that locks people out for days.

What STC-ISP actually is

STC-ISP is not a hardware programmer and it does not talk to a TL866 or a CH341A. It is a serial terminal with a very specific job: it speaks STC’s in-system programming protocol over a plain UART, at TTL levels, to a bootloader that is burned into every STC chip at the factory.

That has one practical consequence worth the whole article. There is no programming adapter to buy, no SWD, no JTAG, no ISP header — three wires and a USB-to-serial cable flash any STC part on the planet. It also means the chip has to be willing to listen, and it only is at one very particular moment.

What you need on the bench

P3.0 and P3.1 are not negotiable — STC’s own manual is blunt about it: “download/simulation interface is only available [P3.0, P3.1]”. If your design needs a serial port for something else, STC recommends moving that traffic to P3.6/P3.7 or P1.6/P1.7.

If Windows shows no COM port at all when you plug the adapter in, stop here — that’s a driver problem, not an STC problem. We have the fixes: CH340 driver for Windows 11, CP2102 / CP210x driver, the PL2303 “phased out” fix, and FT232R on Windows 11.

The cold-start rule, which is the whole game

Every other 8051 tool in the world expects the target to be running when you connect. STC works the opposite way, and this single fact explains almost every failed first attempt.

When an STC chip powers up, it runs its ISP monitor program first and watches P3.0 for a valid download command stream. STC’s manual gives the window: “tens of milliseconds to several hundred milliseconds. If there is no legal download command stream, it will immediately run the user program.” Miss that window and the chip is gone — off running whatever was already flashed, deaf to the PC until the next power-on.

So the order is inverted. The PC has to be shouting before the chip wakes up:

1. Leave the target powered off. USB-to-serial adapter plugged into the PC;
2. Open STC-ISP and pick the exact MCU model in the top-left dropdown;
3. Pick the COM port. Tick “Only show available serial port numbers” so you’re not guessing between eight ghost ports;
4. Click Open Code File and load your .hex or .bin;
5. Click Download/Program. The log shows Checking target MCU ... and appears to hang. It hasn’t — it is transmitting the handshake on a loop;
6. Now power the target on. Programming starts within a second and the log ends at Download completed !

Unplugging only the serial line is not a substitute — it has to be a genuine power-off/power-on of the MCU’s supply. Bench habit worth forming: put a switched USB hub, or a jumper on the VCC line, between the supply and the board. You will be doing this on every single build.

P3.2 and P3.3: the lockout nobody warns you about

STC-ISP has a hardware option that most people click through without reading, and it can make a board look permanently dead:

“P3.2 and P3.3 need to be low for next download.”

Enable that and the chip will refuse every future ISP attempt unless both pins are pulled to ground at cold start. The tool is at least honest about what happened — it comes back with Please connect P3.2/P3.3 to GND and try again ! or Please check P3.2/P3.3 switch to download mode !. Two jumper wires to GND and you’re back in.

Two footnotes worth having. On STC15, STC8 and later parts the protection pins are P3.2/P3.3; on older chips they are P1.0/P1.1. And if you flash an STC8H or STC32 over its native USB rather than a serial adapter, P3.2 has to be grounded to enter ISP mode at all — that’s by design, not a fault.

When it starts but fails halfway

A download that begins and then dies is almost always a baud rate or a power problem, not a corrupt file.

On the clock: STC parts run from an internal RC oscillator that STC-ISP trims at download time. Flash code compiled for 11.0592 MHz into a chip you just set to 24 MHz and every delay loop and baud rate in your firmware is wrong. Nothing in the log will tell you.

The part nobody covers: STC-ISP has a command line

Buried in that Chinese GUI is a fully documented batch mode, and we have never seen it written up in English. Run the executable with arguments and it programs without you touching the window:

STC-ISP-v6.96S.exe -port=COM3 -mcu=STC8H8K64U -codefile="test.hex"

The useful switches, straight from the tool’s own help text: -port= takes COM1–COM255, or USB, HID, Link1D. -baud0= sets the minimum baud (default 2400) and -baud1= the maximum (default 115200). -task=checkmcu just reports what’s on the other end; -task=program is the default. -cfgfile= loads your saved hardware options, -offset= lets you place multiple files, and -info=hide silences the option dump.

You still have to power-cycle the target — the chip’s rules don’t change. But for programming a run of thirty boards, a one-line batch file beats clicking through the GUI thirty times.

Linux and macOS

STC-ISP is a 32-bit Windows executable and STC ships nothing else. The community answer is stcgal (v1.10, MIT licence), a Python tool that reimplements the ISP protocol for the STC 89/90/10/11/12/15/8/32 families over UART and USB. It runs anywhere Python and pyserial run, and it can automate the power cycle by toggling DTR or calling a shell command — which is more than the official tool does.

Coming at this from the AVR side instead? The equivalent tool there is AVRDUDE, and it has its own version of the cold-start trap — not a timing window, but a clock speed the chip is too slow to follow. See AVRDUDE for Windows and the USBasp bit clock.

FAQ

Do I need a programmer like a TL866 or CH341A for STC chips?
No. That’s the appeal of the family — the bootloader is already in silicon and a $1 serial adapter is the entire toolchain. Those programmers are for a different job: SPI flash and EEPROM, standalone chip programming.

Can I read the code back off an STC chip?
No. STC’s parts have no code-read-out path over ISP — that’s the point of the design. Any site promising an STC “read” or “dump” function is selling you something else. If you need to recover firmware, it has to come from a chip you can physically read, which is a different class of tool entirely.

Why does my download only work when I hold the board’s reset?
Because your “power cycle” isn’t one. An external manual reset does restart the ISP monitor on many parts, so if that works for you, use it — but if the supply never actually drops, some designs won’t re-enter ISP at all.

Is v6.96S the right version for an old STC89C52?
Yes. The current release still carries the full device list back to the STC89 series, and newer builds mostly add parts rather than remove them. There’s no reason to hunt for a 2012 copy.

Do I need STC’s U8W programmer board?
Only for offline or production work. The U8W stores the code and flashes without a PC attached, which matters on a factory line. On a bench, a CH340 module does the same job — the U8W board uses a CH340 internally anyway.

Verdict

STC-ISP is a capable tool wearing an off-putting coat: dense Chinese-first UI, a hundred hardware options, and a workflow that feels broken until someone tells you it isn’t. The cold-start rule is the entire learning curve. Once clicking Download before powering the board becomes muscle memory, STC parts go from frustrating to the fastest 8051s to work with — no adapter, no dongle, three wires. Set Max Baud to 9600 on the first run, and leave P3.2/P3.3 protection alone until you have a reason to enable it.

Software checked against STC’s official release and STC’s own tool manual on 19 August 2026.