A year ago, I wrote about the W806 microcontroller. Back then, I ended with the lack of debugging support.
When the CKLink Lite debugger for C-Sky based chips appeared on AliExpress, I wondered whether it might support the W806. However, being priced ~€50 I didn’t want to gamble. Recently an article regarding turning a Blue Pill into a CKLink Lite debugger to debug a W806 microcontroller appeared. This confirmed to be this is the right debugger for the task. So, I went to try it. Flashed the hex file provided in the git repo to a blue pill, and fired up the software, which happens to be in AUR. The AUR packages doesn’t set up all paths so one must set the library path manually when launching:
$ LD_LIBRARY_PATH=/opt/t-head/csky-debugserver/ csky-debugserver
It didn’t work, the debug server would be reporting an error all the time.
+--- ---+ | T-Head Debugger Server (Build: Nov 16 2021) | User Layer Version : 5.12.09 Target Layer version : 2.0 | Copyright (C) 2021 T-HEAD Semiconductor Co.,Ltd. | +--- ---+ ERROR: Your CKLINK may be used by other program or something wrong with your it, please check if you have opened another DebugServer or try to reconnect your CKLINK ERROR: Cklink connection failed.
Now, looking at that repo again, there is an image with a filename in Chinese characters. It contains a schematic. And this gives a clue what is going on. But before going there, I bought an CKLink Lite on AliExpress. Now I have confirmation this is the right hardware, throwing €50 at it doesn’t feel too much of a risk. When this debugger arrived, it worked just fine:
+--- ---+
| T-Head Debugger Server (Build: Nov 16 2021) |
User Layer Version : 5.12.09
Target Layer version : 2.0
| Copyright (C) 2021 T-HEAD Semiconductor Co.,Ltd. |
+--- ---+
T-HEAD: CKLink_Lite_V2, App_ver 2.32, Bit_ver null, Clock 2526.316KHz,
2-wire, With DDC, Cache Flush On, SN CKLink_Lite_V2-0328F32894.
+-- Debug Arch is CKHAD. --+
+-- CPU 0 --+
T-HEAD Xuan Tie CPU Info:
WORD[0]: 0x04a11453
WORD[1]: 0x11000000
WORD[2]: 0x21400417
WORD[3]: 0x30c00005
Target Chip Info:
CPU Type is CK804FGT, in LITTLE Endian.
L1ICache size 16KByte.
Bus type is AHB32.
Signoff date is 04/0107.
HWBKPT number is 5, HWWP number is 2.
GDB connection command for CPUs(CPU0):
target remote 127.0.0.1:1025
target remote 192.168.178.52:1025
With that working, my software setup is established. Now a look at the hardware, what is going on. A look at the repository where I found that hex file I flashed in Blue Pill, has a file with a Chinese file name, 平头哥.png. This file shows a schematic. It reveals the USB Pullup in controlled by PB5. This, in combination with the working CK-Link, reveals what is going on:
[16844.986200] usb 1-6.4: new full-speed USB device number 15 using xhci_hcd [16845.413203] usb 1-6.4: New USB device found, idVendor=c510, idProduct=b211, bcdDevice= 2.03 [16845.413206] usb 1-6.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [16845.413208] usb 1-6.4: Product: C-SKY CKLink-Lite Firmware Loader [16845.413209] usb 1-6.4: Manufacturer: C-SKY Microsystems [16845.937799] usb 1-6.4: USB disconnect, device number 15 [16846.289540] usb 1-6.4: new full-speed USB device number 16 using xhci_hcd [16846.600188] usb 1-6.4: not running at top speed; connect to a high speed hub [16846.640187] usb 1-6.4: New USB device found, idVendor=32bf, idProduct=b210, bcdDevice= 2.20 [16846.640190] usb 1-6.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [16846.640192] usb 1-6.4: Product: C-Sky CKLink-Lite [16846.640193] usb 1-6.4: Manufacturer: C-Sky MicroSystem Co., Ltd. [16846.640194] usb 1-6.4: SerialNumber: T0000000363650328F32894
When plugging the device in, first the bootloader enumerates, then it disconnects, and the firmware enumerates. When I plug in my Blue Pill with the firmware flashes, the bootloader never disconnects. As it tried to disconnect using the PB5 pin, but on a Blue Pill, the USB pullup is hardwires to VCC.
Well, how can we fix this? Let’s get rid of that bootloader, and jump to the firmware directly. We won’t be able to update through the software, as we get rid of the bootloader, but what gives?
Now I have flashed that hex file from that git repo, but even that was not needed. It seems the firmware hex files are included in the installation. Installed in /opt/t-head/csky-debugserver/links/Ck-Link, there are several hex files. cklink_lite.hex is our firmware and cklink_lite_iap.hex is our bootloader. Now, if we open the firmware hex file, we see it starts at 0x08004000. We are looking at a firmware running on an STM32F103, so flash begins at 0x0800000. So, the bootloader lives in the first 0x4000 bytes. We want to get rid of it. Simple Solution, copy the range 0x08004000-0x08004100 to 0x0800000-0x0800100. This copies the vector table to the beginning of the flash, as a result, it will boot straight into the firmware:
[17797.557309] usb 3-2.3: new full-speed USB device number 39 using xhci_hcd [17797.669071] usb 3-2.3: not running at top speed; connect to a high speed hub [17797.687055] usb 3-2.3: New USB device found, idVendor=32bf, idProduct=b210, bcdDevice= 2.20 [17797.687059] usb 3-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [17797.687060] usb 3-2.3: Product: C-Sky CKLink-Lite [17797.687062] usb 3-2.3: Manufacturer: C-Sky MicroSystem Co., Ltd. [17797.687062] usb 3-2.3: SerialNumber: T000000E47543736803E894
And with that firmware running, the csky-debugserver connects fine. Now have now established a working debugger by programming a Blue Pill with a modified hex file, which was included by the software. Note that due we patched out the bootloader, a newer software version will not be able to perform a firmware update, but as the hex files are included in the software distribution, this process can easily be repeated.
By this, I conclude this post. In the next post I will discuss the actual debugging in eclipse.