September 2025 Update: see here for details about converting STM32 over UART instead of J-Link (ie, J-Link not required) (thanks @max4elektroda!) see here for higher version converted CK-Link Lite firmware for STM32 Here I'll document my journey with a cheap STM32F103C8T6 blue pill dev/hobby...

since posting, I've taken a different approach. I've opened up Upgrade_Tools_V1.5.9.exe with pyinstxtractor in search of the main flashing code. The most interesting stuff (I've seen so far) is in SerialThread.pyc icons_rc.pyc ImageThread.pyc MainWindow.pyc ConfigHelper.pyc after uncompyle6 on each we see commands like these that will be used to return information seen in the Upgrade Tools GUI when flashing Code: PythonLog in, to see the code Code: PythonLog in, to see the code These commands, and others, can be seen in various WinnerMicro documentation eg We know the GUI doesn't offer a flash read option, but there might be something in the code to suggest this is possible. In SerialThread.py: Code: PythonLog in, to see the code but how and what is needed to be running on the chip before these commands can be received and actioned? there is no sign of w800_fls_erase.img in any of the extractions so far. Fast-forward several hours of trying things, it turns out to be some virtual path in some Qt resource. It's pieced together from this Python byte code string in icons_rc.py Confirming the extraction was sound took some working out. As it happens, you can also see the same code in HxD live memory viewer. Here's the start of the same data as from byte code extraction Using SerialThread as a reference point GPT and I made some script to mimic resetting the device via AT+Z command and RTS, waiting for Xmodem CCC, uploading flash stub and sending commands. This script gets wifi mac, ble mac, flash ID and gain info from the device, it also asks which com port you want to use first. Flash ID 85, 15 = manufacturer and size, so, Puya and 2mb. The official tool uses this to detect flash size Script correctly detects 14 as the flash size on W806 - 1MB (wifi and ble macs are FF even in GUI flasher tool, so not worried about that) what about adapting the flash read so the whole 2mb can be captured? in the dump we see data at 2400, the main image and some other bits before that 0 and 2000 I've had quite a few variation of script and it seems timing and flushes are critical to a clean dump. Oftentimes without the right flush or pause the end or beginning of flash would contain Xmodem CCC. I also played with set gain a little, but I think this is in ROM so cannot be changed. My 3 boards return this though for the gain read HLK-W806 Code: TextLog in, to see the code HLK-W801 Code: TextLog in, to see the code HLK-W800 Code: TextLog in, to see the code In ConfigHelper.py we see a gain value for W600 and W800. I'm not sure why this is set or its effect. It does not appear to be persistent. I think that's as far as I've got for now. I'll attach the scripts used in the screenshots (and more - some may not work), the stub and the py files. If anyone wants more let me know. TODO/questions: Where does official flasher start writing from and how does it handle .fls and .img files differently? Can a device backup be flashed back to make a working device? What differences are there between a backup taken from CKLink method and UART? Why does W806 not read flash when W800/W801 does? Does this work on a real device? And does anyone have a real W800 with factory Tuya firmware intact?

I remembered I had a Hi-Link HLK-B36 - a W800 module - that I had not flashed OBK to. It still boots Hi-Link firmware Code: TextLog in, to see the code and broadcasts AP HI-LINK-184C Dump using w800_flash_read_crc_flush_double.py shows no captured CCCC whereas w800_flash_read.py does Code: TextLog in, to see the code we clearly see data at the expected points in file and signs of HLK despite soldering and short cables, I have not been able to get the CK-Link method to connect to the CPU

Maybe you allow for a short alternate approach (if it's there and I simply overlooked it, sorry). I didn't have a J-Link programmer at hand, so I tried with a simple UART (as done here). Connect GND -> G UARTs RX -> A9 UARTs TX -> A10 Download Flasher from ST site (you'll need to get an access code with a valid mail address, mailinator.com works ) The process is straight forward, but you need to set the Boot0 jumper (the one opposite to the button): Setting both BOOT jumpers to 0 again and re-connecting STM to USB: Done!

and following the Bouffalo Lab part we can connect to BL602 MCU with the T-Head debug server too Code: TextLog in, to see the code I am using BL602 Ai-Thinker NodeMCU Ai-WB2-32S-Kit STM32F103 assignments for BL STM32F103FunctionBL602/BL604BL702/BL704/BL706BL616/BL618BL808A5TMSGPIO12GPIO0GPIO0GPIO6A1TCKGPIO14GPIO2GPIO1GPIO12A4TDOGPIO11GPIO9GPIO2GPIO7B9TDIGPIO17GPIO1GPIO3GPIO13 This is maybe how you could fix your BL602 @p.kaczmarek2 if UART is not successful

higher version ck-link lite files. converted and original - 2.38 Code: TextLog in, to see the code

Anybody having the TXW8301 FLASH ALGORITHM ELF file ? Getting the error ERROR: Current CPU is not in debug-mode, can't do any flash operations while trying to dump the flash when using other elf files. P.S. The flash is SPI 16Mbit W25Q16JVSSIG The CPU inside TXW8301 is CK803SG: Code: text Expand Select all Copy to clipboard+-- Debug Arch is CKHAD. --+ +-- CPU 0 --+ XuanTie CPU Info: WORD[0]: 0x04901053 WORD[1]: 0x11000000 WORD[2]: 0x21400417 WORD[3]: 0x30c00000 Target Chip Info: CPU Type is CK803SG, in LITTLE Endian. Bus type is AHB32. Signoff date is 04/0107. HWBKPT number is 9, HWWP number is 2.

im not seeing any additional flash algorithm files in the TXW8301 SDK. Your error sounds more like a not connecting type of thing though rather than a flash read problem. looks like we have read CK803SG variant successfully here Maybe this is the kind of error you'd expect with wrong flash algo file? Have you tried lower ICE Clk speeds?

The TXW8301 SDK never contained flash algorithm files. These files were supplied with programmer. I see the files: Taixin_TXW80X_FLASH_ALGORITHM.elf Taixin_TXW81X_FLASH_ALGORITHM.elf WinnerMicro_W800_FLASH_ALGORITHM.elf WinnerMicro_W806_FLASH_ALGORITHM.elf But there are no TXW83X files present! This link is about TXW816 for which algorithm file is definitely present. Exactly as I have no TXW83X FLASH ALGORITHM file. This was the my question. Will try, but seems like Linux Debug server app just ignores ICE speed command line option and I do not use Windows. P.S. Tried with 12kHz Code: text Expand Select all Copy to clipboardXuanTie: CKLink_Lite_V2, App_ver 2.38, Bit_ver null, Clock 12.027KHz, The same error

sure. The TXW80X and TX81X algorithm files were pulled from the SDKs for those platforms so I wondered if the TXW8301 SDK might also contain some specific to that platform with reference to this error: anyway, I'm not sure what to suggest next regarding the TXW8301 and flash dump/programming.

Okay, debug mode error gone just after connecting gdb to the debugserver. But new error appeared:Now is definitely clear that proper TXW83x elf file is needed.

beginning to think it may be a different beast and a different approach may be required. may I ask what device you have with TXW8301 in? I do not have any so may try to source something if it's cheap enough.

oh wow. cool! that's a bit easier Added after 36 :easier as in no J-Link requirement

STM32F103C8T6 Blue Pill as CK-Link Debugger: C-SKY/T-Head/XuanTie CK804 Flash Backup Investigations

divadiow 4146 15

Report a violation of the law

Reply | New topic

Helpful post

#1 21539711 05 May 2025 13:00

divadiow divadiow

Level 38
Topic author

Helpful post
Post #1
21539711 05 May 2025 13:00

September 2025 Update:
see here for details about converting STM32 over UART instead of J-Link (ie, J-Link not required) https://www.elektroda.com/rtvforum/topic4120455.html#21695356 (thanks @max4elektroda!)
see here for higher version converted CK-Link Lite firmware for STM32 https://www.elektroda.com/rtvforum/topic4120455.html#21554694

Here I'll document my journey with a cheap STM32F103C8T6 "blue pill" dev/hobby board bought from Ali Express. Despite the IC labelled as "STM32F103C8T6" the internal flash appears to be 128k instead of 64k making it more like an STM32F103CBT6. It seems this is not unexpected with STM32 fakes/clones.

The purpose of this purchase is to make a cheap C-SKY CK-Link / T-Head CPU debugger in the hope that I can access and dump the flash of C-SKY based chips like the WinnerMicro W800/W801/W806 which are C-SKY CK804FGT.

I bought 3 from the YouKeyi Store https://www.aliexpress.com/item/1005006999051681.html

Using cjacker's developments at https://github.com/cjacker/cklink-lite-fw-convertor we can convert the 'cklink_lite.hex' file that ships with the T-Head debug server so it will run on the STM32 after flashing. cjacker also supplies a binary that's already been converted https://github.com/cjacker/cklink-lite-fw-con.../blob/main/cklink_lite-2.36_for-stm32f103.hex and version 2.37, along with a Windows-compatible Python conversion script can be found in this PR https://github.com/cjacker/cklink-lite-fw-convertor/pull/1/files. I'll attach all files here for safe-keeping.

But how do we program the STM32? SWD - Serial Wire Debug!

Using one of these cheap clone J-Link programmer/debuggers we can flash the STM32 using J-Flash.

J-Flash can be downloaded from https://www.segger.com/products/debug-probes/j-link/technology/flash-download/

Connect like so
J-Link GND -> STM32 GND
J-Link SWDIO -> STM32 SWIO
J-Link SWCLK -> STM32 SWCLK
J-Link 3V3/VCC - <disconnected>

run J-Flash, make a new project and select "STM32F103CB" (128kb) from the target device list

with both devices powered from their micro-USB ports 'Target' and 'Connect' in J-Flash menus should see the device connect successfully

Now you can erase/write or read entire chip from the Target-> Manual Programming menu. First I read the Keil USB memory stick emulator demo thing that shipped with the STM32.

To flash cklink_lite-2.37_for-stm32f103.hex just drag the file into J-Flash window -> Erase Chip -> Program & Verify

Power off the STM32 and re-plug it. If using Windows it should be detected as a C-Sky CKLink-Lite device

Now that this is done we need to engage with the T-Head debugging server so we can interface with C-SKY-based devices.

Register for and download the T-Head debug server from https://www.xrvm.cn/community/download?id=4380347564587814912 - I'll be demonstrating the Windows variant. I attach Windows and Linux downloads at the latest version at time of writing, as well as the debug user guide PDF.

The CPU I'll be connecting to is the CK804 in a Hi-Link HLK-W806-KIT dev board, the same as explained here https://github.com/cjacker/opensource-toolcha...your-own-ck-link-lite-debugger-with-stm32f103

STM32 is connected to the HLK like so

With power to STM32 and the W806, running the DebugServerConsole app should put the CPU into debug mode and show information about the CK-Link firmware version and the W806 CPU

Code: Text
Log in, to see the code

Extract the attached w806.elf file and put it into the \bin folder alongside the debug console executable - C:\Users\xxxx\AppData\Roaming\T-Head\T-HeadDebugServer\bin if installed to default location

Code: Text
Log in, to see the code

Information about the elf file can be obtained with command flash -al w806.elf from the debug console

DebuggerServer$ flash -al w806.elf
Code: Text
Log in, to see the code

For reference the entire flash command list is as follows

Code: Text
Log in, to see the code

so we should be able to dump the W806 flash content with a command like this

Code: Text
Log in, to see the code

those arguments meaning:

Code: Text
Log in, to see the code

The dump appears to work. 1mb took 56 seconds.

Code: Text
Log in, to see the code

The dump lands in \bin folder

The resultant file appears to contain data and even some plain text from the W806 demo flashed using Upgrade Tools

Unfortunately flashing back as-is using command flash program -f blinkydump.bin -b -a 0x08000000 -al w806.elf does not appear to result in a bootable app, leaving the device waiting for an upload in the xmodem "CCCCCCCCCCC" mode

Also curious is that erasing flash even though 'successful', doesn't appear to actually zero the flash, a subsequent dump appears to be almost identical to one taken before the erase - this is also true if using wm_tool (wm_tool_1.0.4.exe -c com79 -eo all) to erase the W806 over UART - no empty flash, though it does appear to go into CCCCC mode after the erase, so maybe it's changing some byte to mark as empty?
debug console erase commands tried:

flash erase -a 0x08000000 -s 0x100000 -al w806.elf
flash erase -c -al w806.elf

Other observations:

COM port outputs this during read operations
Code: Text
Log in, to see the code

and this with write
Code: Text
Log in, to see the code

That's where I've got to right now. A working restore of the flash I think is the priority thing to work out. Unfortunately I do not have any C-Sky devices with their original firmware on to dump something new and interesting from a company like Tuya.

Attachments:

emptymaybedump.bin (1 MB) You must be logged in to download this attachment.

blinkydump.bin (1 MB) You must be logged in to download this attachment.

UPDATED-cklink-lite-fw-convertor-main.zip (71.7 KB) You must be logged in to download this attachment.

keil_usb_app_dump_from_swd_128kb.bin (128 KB) You must be logged in to download this attachment.

W806.elf.zip (21.54 KB) You must be logged in to download this attachment.

XuanTie-DebugServer-linux-x86_64-V5.18.3-20241119.sh.tar.gz (2.09 MB) You must be logged in to download this attachment.

T-Head-DebugServer-windows-V5.18.0-20230926-1711.zip (16.88 MB) You must be logged in to download this attachment.

JLink_Windows_V830_x86_64.exe (56.27 MB) You must be logged in to download this attachment.

Debugger+Server+User+Guide(ZH-CN)_20241122.pdf (3.62 MB) You must be logged in to download this attachment.

cklink-lite-fw-convertor-main.zip (75.1 KB) You must be logged in to download this attachment.

ADVERTISEMENT
Helpful post

#2 21542722 07 May 2025 23:39

divadiow divadiow

Level 38
Topic author Helpful post? (+1)

Helpful post
Post #2
21542722 07 May 2025 23:39

since posting, I've taken a different approach. I've opened up Upgrade_Tools_V1.5.9.exe with pyinstxtractor in search of the main flashing code. The most interesting stuff (I've seen so far) is in

SerialThread.pyc
icons_rc.pyc
ImageThread.pyc
MainWindow.pyc
ConfigHelper.pyc

after uncompyle6 on each we see commands like these that will be used to return information seen in the Upgrade Tools GUI when flashing

Code: Python
Log in, to see the code

Code: Python
Log in, to see the code

These commands, and others, can be seen in various WinnerMicro documentation eg https://arduino.winnermicro.com/w800/en/2.3-beta.1/component_guides/rom.html

We know the GUI doesn't offer a flash read option, but there might be something in the code to suggest this is possible.

In SerialThread.py:

Code: Python
Log in, to see the code

but how and what is needed to be running on the chip before these commands can be received and actioned?

there is no sign of w800_fls_erase.img in any of the extractions so far. Fast-forward several hours of trying things, it turns out to be some virtual path in some Qt resource. It's pieced together from this Python byte code string in icons_rc.py

Confirming the extraction was sound took some working out.
As it happens, you can also see the same code in HxD live memory viewer. Here's the start of the same data as from byte code extraction

Using SerialThread as a reference point GPT and I made some script to mimic resetting the device via AT+Z command and RTS, waiting for Xmodem CCC, uploading flash stub and sending commands. This script gets wifi mac, ble mac, flash ID and gain info from the device, it also asks which com port you want to use first.

Flash ID 85, 15 = manufacturer and size, so, Puya and 2mb.

The official tool uses this to detect flash size

Script correctly detects 14 as the flash size on W806 - 1MB

(wifi and ble macs are FF even in GUI flasher tool, so not worried about that)

what about adapting the flash read so the whole 2mb can be captured?

in the dump we see data at 2400, the main image

and some other bits before that 0 and 2000

I've had quite a few variation of script and it seems timing and flushes are critical to a clean dump. Oftentimes without the right flush or pause the end or beginning of flash would contain Xmodem CCC.

I also played with set gain a little, but I think this is in ROM so cannot be changed. My 3 boards return this though for the gain read

HLK-W806
Code: Text
Log in, to see the code

HLK-W801
Code: Text
Log in, to see the code

HLK-W800
Code: Text
Log in, to see the code

In ConfigHelper.py we see a gain value for W600 and W800. I'm not sure why this is set or its effect. It does not appear to be persistent.

I think that's as far as I've got for now. I'll attach the scripts used in the screenshots (and more - some may not work), the stub and the py files. If anyone wants more let me know.

TODO/questions:
Where does official flasher start writing from and how does it handle .fls and .img files differently?
Can a device backup be flashed back to make a working device?
What differences are there between a backup taken from CKLink method and UART?
Why does W806 not read flash when W800/W801 does?
Does this work on a real device? And does anyone have a real W800 with factory Tuya firmware intact?

Attachments:

PYZ-00.pyz_extracted-uncompylle6-py-files.zip (212.35 KB) You must be logged in to download this attachment.

w800-python-flash-read.zip (2.67 MB) You must be logged in to download this attachment.

w800-python-info-read.zip (5.96 KB) You must be logged in to download this attachment.
ADVERTISEMENT
Helpful post

#3 21544784 10 May 2025 09:03

divadiow divadiow

Level 38
Topic author Helpful post? (+1)

Helpful post
Post #3
21544784 10 May 2025 09:03

I remembered I had a Hi-Link HLK-B36 - a W800 module - that I had not flashed OBK to. It still boots Hi-Link firmware

Code: Text
Log in, to see the code

and broadcasts AP "HI-LINK-184C"

Dump using w800_flash_read_crc_flush_double.py shows no captured CCCC whereas w800_flash_read.py does

Code: Text
Log in, to see the code

we clearly see data at the expected points in file

and signs of HLK

despite soldering and short cables, I have not been able to get the CK-Link method to connect to the CPU

Attachments:

HLK-B36_w800_flash_read_crc_flush_double.py.bin (2 MB) You must be logged in to download this attachment.

HLK-B36_w800_flash_read.py.bin (2 MB) You must be logged in to download this attachment.
#4 21550397 15 May 2025 22:11

divadiow divadiow

Level 38

Topic author Helpful post? (0)

Post #4
21550397 15 May 2025 22:11

and following the Bouffalo Lab part we can connect to BL602 MCU with the T-Head debug server too
https://github.com/cjacker/opensource-toolchain-bouffalo-lab

Code: Text
Log in, to see the code

I am using BL602 Ai-Thinker NodeMCU Ai-WB2-32S-Kit

STM32F103 assignments for BL
STM32F103 Function BL602/BL604 BL702/BL704/BL706 BL616/BL618 BL808
A5 TMS GPIO12 GPIO0 GPIO0 GPIO6
A1 TCK GPIO14 GPIO2 GPIO1 GPIO12
A4 TDO GPIO11 GPIO9 GPIO2 GPIO7
B9 TDI GPIO17 GPIO1 GPIO3 GPIO13

This is maybe how you could fix your BL602 @p.kaczmarek2 if UART is not successful
#5 21554694 20 May 2025 12:53

divadiow divadiow

Level 38
Topic author Helpful post? (0)

Post #5
21554694 20 May 2025 12:53

higher version ck-link lite files. converted and original - 2.38
Code: Text
Log in, to see the code

Attachments:

cklink_lite-2.38.zip (70.82 KB) You must be logged in to download this attachment.
ADVERTISEMENT
#6 21642427 23 Aug 2025 17:41

Harbour Harbour

Level 3
Helpful post? (0)

Post #6
21642427 23 Aug 2025 17:41

Anybody having the TXW8301 FLASH ALGORITHM ELF file ? Getting the error "ERROR: Current CPU is not in debug-mode, can't do any flash operations" while trying to dump the flash when using other elf files.

P.S.

The flash is SPI 16Mbit W25Q16JVSSIG

The CPU inside TXW8301 is CK803SG:

Code: text Expand Select all Copy to clipboard
+-- Debug Arch is CKHAD. --+ +-- CPU 0 --+ XuanTie CPU Info: WORD[0]: 0x04901053 WORD[1]: 0x11000000 WORD[2]: 0x21400417 WORD[3]: 0x30c00000 Target Chip Info: CPU Type is CK803SG, in LITTLE Endian. Bus type is AHB32. Signoff date is 04/0107. HWBKPT number is 9, HWWP number is 2.
#7 21643082 24 Aug 2025 13:16

divadiow divadiow

Level 38

Topic author Helpful post? (0)

Post #7
21643082 24 Aug 2025 13:16

im not seeing any additional flash algorithm files in the TXW8301 SDK.

Your error sounds more like a not connecting type of thing though rather than a flash read problem.

looks like we have read CK803SG variant successfully here https://www.elektroda.com/rtvforum/topic4129331.html

Maybe this is the kind of error you'd expect with wrong flash algo file?

https://www.elektroda.com/rtvforum/topic4134923.html#21640179

Have you tried lower ICE Clk speeds?
ADVERTISEMENT
#8 21643230 24 Aug 2025 16:12

Harbour Harbour

Level 3
Helpful post? (0)

Post #8
21643230 24 Aug 2025 16:12

divadiow wrote:
I'm not seeing any additional flash algorithm files in the TXW8301 SDK.

The TXW8301 SDK never contained flash algorithm files. These files were supplied with programmer. I see the files:

Taixin_TXW80X_FLASH_ALGORITHM.elf
Taixin_TXW81X_FLASH_ALGORITHM.elf
WinnerMicro_W800_FLASH_ALGORITHM.elf
WinnerMicro_W806_FLASH_ALGORITHM.elf

But there are no TXW83X files present!

Quote:

Your error sounds more like a not connecting type of thing though rather than a flash read problem.

looks like we have read CK803SG variant successfully here https://www.elektroda.com/rtvforum/topic4129331.html

This link is about TXW816 for which algorithm file is definitely present.

Quote:

Maybe this is the kind of error you'd expect with wrong flash algo file?

Exactly as I have no TXW83X FLASH ALGORITHM file. This was the my question.

Quote:

https://www.elektroda.com/rtvforum/topic4134923.html#21640179

Have you tried lower ICE Clk speeds?

Will try, but seems like Linux Debug server app just ignores ICE speed command line option and I do not use Windows.

P.S. Tried with 12kHz

Code: text Expand Select all Copy to clipboard
XuanTie: CKLink_Lite_V2, App_ver 2.38, Bit_ver null, Clock 12.027KHz,

The same error
#9 21643295 24 Aug 2025 17:43

divadiow divadiow

Level 38

Topic author Helpful post? (0)

Post #9
21643295 24 Aug 2025 17:43

sure. The TXW80X and TX81X algorithm files were pulled from the SDKs for those platforms so I wondered if the TXW8301 SDK might also contain some specific to that platform

Quote:
Maybe this is the kind of error you'd expect with wrong flash algo file?

with reference to this error: https://obrazki.elektroda.pl/6958044300_1755725962_bigthumb.jpg

anyway, I'm not sure what to suggest next regarding the TXW8301 and flash dump/programming.
#10 21643718 25 Aug 2025 07:23

Harbour Harbour

Level 3

Helpful post? (0)

Post #10
21643718 25 Aug 2025 07:23

Okay, debug mode error gone just after connecting gdb to the debugserver. But new error appeared:

Quote:
DebuggerServer$ flash dump -o dump.bin -b -a 0x0 -s 0x1000000 -al Taixin_TXW81X_FLASH_ALGORITHM.elf
flash dump -o dump.bin -b -a 0x0 -s 0x1000000 -al Taixin_TXW81X_FLASH_ALGORITHM.elf
ERROR: Load Flash Algorithm File: Failed to load algorithm to target.
Can't run FlashAlgorithm to bkpt_label, restore destoryed registers and memory.
Dump failed.

Now is definitely clear that proper TXW83x elf file is needed.
#11 21646652 28 Aug 2025 07:43

divadiow divadiow

Level 38

Topic author Helpful post? (0)

Post #11
21646652 28 Aug 2025 07:43

beginning to think it may be a different beast and a different approach may be required. may I ask what device you have with TXW8301 in? I do not have any so may try to source something if it's cheap enough.

#12 21646786 28 Aug 2025 10:19

Harbour Harbour

Level 3

Post #12

21646786 28 Aug 2025 10:19

There are plenty of it. The famous is LilyGO T-Hallow, second is MaduinoZeroWiFiHalow and many others. I see that you are partially right - there is the flash template project in SDK. Usually they placed the compiled ELF file but not in TXW8301 case. Will try to compile and test it. The current main problem for me - is the buggy debug server. It is constantly failing to put CPU in debug mode. But the debug API example that is supplied with the debug server is constantly can do this:

./example/Output/Example 
 ---                                                    --- 
|  XuanTie Debugger Server (Build: Jun 12 2025, Linux)      |
   User   Layer Version : 5.18.05 
   Target Layer version : 2.0
|  Copyright (C) 2025 Hangzhou C-SKY MicroSystems Co., Ltd.|
 ---                                                    --- 
XuanTie: CKLink_Lite_V2, App_ver 2.38, Bit_ver null, Clock 2526.316KHz,
       2-wire, With DDC, Cache Flush On, SN CKLink_Lite_V2-T000000D4B453139675A794.
 --  Debug Arch is CKHAD.  -- 
 --  CPU 0  -- 
XuanTie CPU Info:
   WORD[0]: 0x04901053
   WORD[1]: 0x11000000
   WORD[2]: 0x21400417
   WORD[3]: 0x30c00000
Target Chip Info:
   CPU Type is CK803SG, in LITTLE Endian.
   Bus type is AHB32.
   Signoff date is 04/0107.
   HWBKPT number is 9, HWWP number is 2.
=================== memory access test ==================

memory read/write successfully

=================== register access test ==================

CPU generate register:
r0: write 0x12345678, read 0x12345678
r1: write 0x12345678, read 0x12345678
r2: write 0x12345678, read 0x12345678
r3: write 0x12345678, read 0x12345678
r4: write 0x12345678, read 0x12345678
r5: write 0x12345678, read 0x12345678
r6: write 0x12345678, read 0x12345678
r7: write 0x12345678, read 0x12345678
r8: write 0x12345678, read 0x12345678
r9: write 0x12345678, read 0x12345678
r10: write 0x12345678, read 0x12345678
r11: write 0x12345678, read 0x12345678
r12: write 0x12345678, read 0x12345678
r13: write 0x12345678, read 0x12345678
r14: write 0x12345678, read 0x12345678
r15: write 0x12345678, read 0x12345678
CPU PC register:
PC: write 0x12345678, read 0x12345678


=================== breakpoint test ==================

WARNING: Address 0x00000000 can't be written when remove soft-bkpt.
Breakpoint add successfully

WARNING: CPU_0: success to enter debug mode asynchronously.
Debug state: reason: 0x0, PC: 0x2e32, add_len: 0x4, status: 0x1302, status2: 0x0

Helpful post

#13 21695356 20 Sep 2025 12:14

max4elektroda max4elektroda

Level 24

Helpful post? (+2)

Helpful post
Post #13
21695356 20 Sep 2025 12:14

divadiow wrote:
But how do we program the STM32? SWD - Serial Wire Debug!

Using one of these cheap clone J-Link programmer/debuggers we can flash the STM32 using J-Flash.

Maybe you allow for a short alternate approach (if it's there and I simply overlooked it, sorry).

I didn't have a J-Link programmer at hand, so I tried with a simple UART (as done here).

Connect
GND -> G
UARTs RX -> A9
UARTs TX -> A10

Download Flasher from ST site https://www.st.com/en/development-tools/flasher-stm32.html#get-software (you'll need to get an access code with a valid mail address, mailinator.com works )

The process is straight forward, but you need to set the "Boot0" jumper (the one opposite to the button):

Setting both "BOOT" jumpers to 0 again and re-connecting STM to USB:

Done!
#14 21695365 20 Sep 2025 12:22

divadiow divadiow

Level 38

Topic author Helpful post? (0)

Post #14
21695365 20 Sep 2025 12:22

oh wow. cool! that's a bit easier

Added after 36 [seconds]:

easier as in no J-Link requirement
#15 21695375 20 Sep 2025 12:42

max4elektroda max4elektroda

Level 24

Helpful post? (0)

Post #15
21695375 20 Sep 2025 12:42

Yes, easier for me, for I didn't find my J-Link clone
Thanks for your work, I just successfully dumped my X5 Cam and flashed OpenTXW81X with help of this and this post!

Maybe you want to mention or even better "integrate" this approach in your initial post?
Feel free to use all images or text
#16 21695389 20 Sep 2025 13:05

divadiow divadiow

Level 38

Topic author Helpful post? (0)

Post #16
21695389 20 Sep 2025 13:05

cheers. added update note header for now
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Didn't find an answer? Ask Artificial Intelligence

*I agree to send the question to OpenAI, Anthropic PBC, Perplexity AI, Inc., Kagi Inc., Google LLC - owners of language models in order to prepare the best response. The companies may monitor and log information entered into the form.

*I agree to publicly display my question and answer. The question and answer will be publicly available to everyone. The process may take a few minutes. Upon completion, you will be redirected to the page with the answer.

Wait...(2min)

Reply | New topic

Report a violation of the law

Topic summary

✨ The discussion documents the use of a low-cost STM32F103C8T6 "Blue Pill" development board, which appears to have 128kB internal flash instead of the expected 64kB, resembling an STM32F103CBT6 variant, a known characteristic of some STM32 clones. The main goal is to repurpose this board as a C-SKY CK-Link / T-Head CPU debugger to access and dump flash memory from C-SKY CK804FGT-based chips such as the WinnerMicro W800/W801/W806 series. The user explores firmware conversion using cjacker's cklink-lite-fw-convertor to adapt the T-Head debug server's cklink_lite.hex file. Further investigation involves reverse engineering the Upgrade_Tools_V1.5.9.exe using pyinstxtractor and uncompyle6 to analyze Python bytecode files (SerialThread.pyc, MainWindow.pyc, etc.) revealing serial commands for reading BLE and Wi-Fi MAC addresses, consistent with WinnerMicro documentation. The user also tests a Hi-Link HLK-B36 W800 module running original firmware, observing UART debug output. Additionally, the T-Head debug server successfully connects to Bouffalo Lab BL602 MCU, with STM32F103 pin assignments detailed for various BL series chips. The latest CK-Link Lite firmware version 2.38 is noted, supporting XuanTie CK804 CPUs with features like 5-wire debug, DDC, and cache flush. The discussion highlights practical steps and tools for flashing, debugging, and interfacing with C-SKY/T-Head CPUs using affordable STM32 hardware.
Generated by the language model.

FAQ

TL;DR: A $2–$4 STM32F103C8T6 “Blue Pill” can run CK-Link Lite to dump a CK804/W806 flash; a 1 MB dump took 56 seconds. “The dump appears to work.” [Elektroda, divadiow, post #21539711]

Why it matters: This FAQ helps makers and firmware analysts turn a Blue Pill into a budget C-SKY/T-Head/XuanTie debugger and reliably back up or inspect SPI flash on W80x/CK80x parts.

Quick Facts

CK-Link Lite firmware confirmed at v2.38 for STM32F103 after conversion; earlier work used v2.37. [Elektroda, divadiow, post #21554694]
W806 mapped flash range used for dump: start 0x08000000, length 0x00100000 (1 MB). [Elektroda, divadiow, post #21539711]
Measured throughput: 1 MB flash dump completed in 56 seconds via DebugServerConsole. [Elektroda, divadiow, post #21539711]
Blue Pill can be flashed via SWD (J-Link) or UART using ST’s Flasher with BOOT0=1. [Elektroda, max4elektroda, post #21695356]
CK-Link connection modes observed: 2‑wire for CK804 targets; 5‑wire for some RISC‑V (BL602). [Elektroda, divadiow, post #21550397]

How do I turn a Blue Pill (STM32F103C8T6) into a CK-Link Lite debugger?

Flash a converted CK-Link Lite firmware onto the Blue Pill, then connect it to the target via SWD/JTAG. You can program the Blue Pill using ST’s Flasher over UART (set BOOT0=1), or use a J‑Link clone with J‑Flash selecting STM32F103CB. After power cycling, Windows will detect it as CKLink‑Lite, and T-Head DebugServerConsole will report firmware version on connect. [Elektroda, max4elektroda, post #21695356]

What pins do I wire between J-Link and the Blue Pill for SWD flashing?

Wire GND→GND, SWDIO→SWIO, and SWCLK→SWCLK. Leave the J‑Link 3V3/VCC disconnected because both boards power over their own USB ports. In J‑Flash, select STM32F103CB (128 KB) and use Target → Connect to confirm the link before erasing and programming the HEX. [Elektroda, divadiow, post #21539711]

How do I install and use T‑Head DebugServerConsole to talk to a W806 (CK804)?

Install the T‑Head Debug Server, place the w806.elf flash algorithm in the bin folder, connect the Blue Pill CK-Link to the HLK‑W806 pins, and run DebugServerConsole. On success it prints CKLink firmware version and CK804 CPU info with GDB endpoints. Use 'flash -al w806.elf' to select the algorithm. [Elektroda, divadiow, post #21539711]

What’s the exact command to dump W806 flash, and where does the file land?

Use: flash dump -o dump.bin -b -a 0x08000000 -s 0x100000 -al w806.elf. The '-b' flag outputs binary, '-a' sets start address, and '-s' sets size (bytes). The dump saves in the Debug Server bin folder. Example output shows "Dump success." after a 1 MB, 56‑second read. [Elektroda, divadiow, post #21539711]

My restored dump won’t boot and the UART shows CCCCC… What went wrong?

Writing the raw dump back with 'flash program -b' may not recreate a bootable image. One observed failure left the W806 in xmodem "CCCC" mode after flashing, and erases reported "successful" yet dumps stayed nearly identical. This suggests metadata or non‑obvious regions need handling beyond a blind binary write. [Elektroda, divadiow, post #21539711]

Can I read W800/W801/W806 flash over UART without CK-Link?

Yes. Reverse‑engineered Upgrade_Tools UART commands and the embedded w800_fls_erase.img stub enable full flash reads. A Python script triggers bootloader via AT+Z and RTS, uploads the stub, then issues read commands, returning flash IDs (e.g., Puya 0x85 with size code 0x15). "Timing and flushes are critical to a clean dump." [Elektroda, divadiow, post #21542722]

Why do I see stray 'C' bytes or CRC mismatches in UART dumps?

The bootloader’s XMODEM handshake can bleed 'C' characters into the stream if serial flushes and delays aren’t tuned. One test showed clean images only after adding double flushes; another completed a dump but ended with a CRC mismatch despite visible, valid payload at expected offsets. Retune delays and verify with a second pass. [Elektroda, divadiow, post #21544784]

What is a flash algorithm ELF (e.g., w806.elf), and why do I need it?

It’s a target‑side routine the Debug Server loads to perform erase/read/program operations safely. Selecting 'w806.elf' exposes device info (name, ID, NAND/SPI type, ranges, sector size) and config like destroyed RAM and buffer sizes. Without the correct ELF, operations may fail or be unsafe for that chip. [Elektroda, divadiow, post #21539711]

How do I dump or program TXW8301 (CK803SG)? Do I need a TXW83x algorithm?

Yes. Attempts using TXW81x ELFs on TXW8301 returned “Failed to load algorithm to target,” confirming a proper TXW83x flash algorithm ELF is required. Connecting GDB first cleared a debug‑mode error, but without the correct ELF, flash dump still failed. [Elektroda, Harbour, post #21643718]

What ICE clock speed should I try if the link is unstable on Linux?

Lower the CK-Link clock drastically and retry. One report showed the Linux server honoring ~12 kHz but still failing to enter robust debug mode until GDB attached. Behavior varied, suggesting toolchain quirks rather than pure signal integrity in that case. [Elektroda, Harbour, post #21643230]

Can the Blue Pill CK-Link talk to Bouffalo Lab parts like BL602?

Yes. Users connected to BL602 with CK-Link Lite 2.37–2.38 under the same T‑Head Debug Server. The console identified RISC‑V features (e.g., MISA RV32IMAFCX) and reported 5‑wire mode. A small pin‑map table was shared for BL6xx/7xx/8xx families. [Elektroda, divadiow, post #21550397]

How fast is CK-Link Lite in practice?

Measured throughput on a CK804/W806 target was about 1 MB in 56 seconds using DebugServerConsole with w806.elf. Speed varies with cable quality, clock setting, and the algorithm’s block size. For larger images, estimate linearly unless you change transport or clock. [Elektroda, divadiow, post #21539711]

What is Tuya in this context?

Tuya is a popular IoT platform used by many consumer devices. In this thread, the goal was to access C‑SKY devices that might still contain stock Tuya firmware for research or backup. The author asked whether anyone had a W800 with factory Tuya intact. [Elektroda, divadiow, post #21539711]

What is OpenBeken (OBK)?

OpenBeken is an open-source firmware used to replace vendor images on certain Wi‑Fi MCUs and modules. One user preserved a Hi‑Link W800 module that still booted the original firmware because they had not flashed OBK yet, enabling a clean dump for analysis. [Elektroda, divadiow, post #21544784]

How do I flash the Blue Pill over UART instead of using a J‑Link?

Quick 3‑step method:

Set BOOT0=1, connect USB‑UART: RX→A9, TX→A10, GND→G.
Use ST’s Flasher to program the converted CK‑Link Lite HEX.
Set BOOT0=0 again, reconnect USB; Windows should enumerate as CKLink‑Lite. [Elektroda, max4elektroda, post #21695356]

Why does an erase say "successful" but the subsequent dump looks unchanged?

One case showed a chip erase reported OK via both DebugServerConsole and wm_tool over UART, yet a new dump looked nearly identical to the prior image. The device did drop into CCCC mode, suggesting flags changed while main contents persisted, so the erase routine or mapping may differ from expectations. [Elektroda, divadiow, post #21539711]

Generated by the language model.

STM32F103	Function	BL602/BL604	BL702/BL704/BL706	BL616/BL618	BL808
A5	TMS	GPIO12	GPIO0	GPIO0	GPIO6
A1	TCK	GPIO14	GPIO2	GPIO1	GPIO12
A4	TDO	GPIO11	GPIO9	GPIO2	GPIO7
B9	TDI	GPIO17	GPIO1	GPIO3	GPIO13