Protocol Analysis of STC12C Series

This version of the protocol has undergone significant changes compared to the previous one, including the packet header, etc. However, STC has a thousand-year-old opening frame: 0x7F. The STC15 series MCU still uses this ISP opening frame. You all know the reason without me having to explain .

Then let's get to the topic: STC12 series download frame format:

Introduction to the protocol frame: The main components are as follows

 

Head

Sign

Reserved

Length

Frame

Data

Checksum

Trail

 

   Detailed description of each filling area:

 

name	length	Function
Head	2-Byte	Packet header (0×46, 0xB9)
Sign	1-Byte	Identification (0x6A or 0x68)
Reserved	1-Byte	Reserved area (filled with 0x00)
Length	1-Byte	Total length of (Head + Length + Frame + Data )
Frame	1-Byte	To distinguish different frames
Da ta	0~0x8A Bytes	data
Checksum	2 Byte	Checksum
Trail	1 Byte	Packet tail (0×16)

 

As for Cmd's protocol response and the like:

Command Description MCU responds
7F Boot MCU into ISP and measure clock 50 MCU option information

50 Set MCU model, etc. 8F Response

8F New baud rate test 8F Test response

8E Formal baud rate change 84 Baud rate change response

84 File capacity, erase chip 00 Response

00 Download program 00/30 Response checksum, success or failure

30 Re-download program 00/30 Response checksum

69 Model, etc. 8D Response

8D Set Option 50 Answer Option

82 Exit Restart to enter user program

As for the interaction process, it is also very simple, it just depends on the reaction speed of your device. This is why some PL2303 line downloads often make mistakes , but at least it works well here.

PC -> 0x7f -> MCU

MCU -> Information -> PC

PC -> Verify? MCU model -> MCU

MCU -> Baud rate change request -> PC

PC -> Baud rate test -> MCU [At this time, calculate the reload value to switch the baud rate]

MCU -> Success/No response -> PC

PC -> Baud rate setting -> MCU [Switch to the lowest baud rate

MCU -> Success/No response -> PC [Switch to data baud rate

PC -> Erase chip -> MCU

MCU -> Success/No response -> PC

PC -> 0x80 bytes of data -> MCU

MCU -> Verification code -> PC

Loop until end of file

PC -> Settings? Model -> MCU

MCU -> Success/No response -> PC

PC -> Settings -> MCU

MCU -> Success/No response -> PC

PC -> Programming completed -> MCU

The checksum algorithm is to add up all the contents marked in the data area and take the lower sixteen bits. See the program:

 

Regarding the information frame of the STC12C5Ax series, here is a picture analyzed by others:

 

As for the firmware versions I tested here are:

About the calculation of crystal oscillator speed:

If it is a standard 12M clock and 1200Kps baud rate, the count value is 1/1200*7 = 5833uS, and the value is also 5833. The average of eight times (assuming 18 94=6292), then the MCU clock frequency = 6292*12M/5833 = 12.994MHz. [page]

I was wondering, is the C-level microcontroller xx 43?

The following data frames omit the frame header, frame tail, and frame length check code.

——————–Check MCU model frame————————-

 

Send data 50 07 00 36 01 MCU model

Receive data 8F

——————-Baud rate experiment frame——————————–

Send data 8F xx yy zz aa dd 83

xx=0xC0 (C0=1100 0000, which means T1x12, double the baud rate)

yy=timer reload value, calculated as double/1T.

zz=set checksum, calculated as ff=xx

aa=baud rate check value, calculated as aa=2 * (0×100 -yy)

dd=delay value, how much time is delayed before switching

83 is the ISP timing constant. This value is applicable to the 12M crystal oscillator. There is an unclear description in the STC manual:

But in actual testing, it seems that the value 83 has no problem at 40M.

Accept data:

8F xx yy zz aa dd 83

—————————–Baud rate confirmation frame

Send data 8E xx yy zz dd 83

Receive data as above

——————————Erase frame:

I have every reason to suspect that the old demon is sick. Even when it comes to downloading the program, it still uses such a weird erase command:

Response:

00 00

-------Data Frame

Send 00 00 00 ADDR 00 LEN EF 0×80 bytes data

ADDR = 2BYTE address, high byte first, low byte last

LEN seems to be the data length

If the data field is less than 80 bytes, fill it with ff

Response 07 ChkSum

The ChkSum algorithm is the same as described above, except that it only verifies the data part.

——————Set model frame:

69 07 00 36 01 MCU_MODEL

MCU_MODEL is the MCU model

The response is just one word 8D

——————-Set option frame

Send: 8D FF x1 x2 FF FF FF FF FF x3 FF FF FF FF FF FF 00 A9 0A A6

x1, x2, x3 see previous option information

Accept: 50 FF x1 x2 FF x3 03 FF Firmware version FF x1 x2 FF x3 FF 00 A9 00 03 00 9A 04 79 1A 00 AD FF 00 62

——————RESET frame

Send: 82 00 00

no respond.

For specific implementation, please refer to the implementation of kSTC12-ISP