STM32F103C8T6 Blue Pill jako debugger CK-Link: C-SKY/T-Head/XuanTie Badanie kopii zapasowej Flash CK

Aktualizacja z września 2025:
zobacz tutaj, aby uzyskać szczegółowe informacje na temat konwersji STM32 przez UART zamiast J-Link (tj. J-Link nie jest wymagany) https://www.elektroda.com/rtvforum/topic4120455.html#21695356 (dzięki @max4elektroda!)
zobacz tutaj, aby uzyskać wyższą wersję przekonwertowanego oprogramowania CK-Link Lite dla STM32 https://www.elektroda.com/rtvforum/topic4120455.html#21554694

---

Tutaj udokumentuję moją podróż z tanią płytką STM32F103C8T6 "blue pill" kupioną w Ali Express. Pomimo układu scalonego oznaczonego jako "STM32F103C8T6" wewnętrzna pamięć flash wydaje się mieć 128k zamiast 64k, co czyni go bardziej podobnym do STM32F103CBT6. Wydaje się, że nie jest to nieoczekiwane w przypadku podróbek/klonów STM32.

Celem tego zakupu jest stworzenie taniego debuggera procesora C-SKY CK-Link / T-Head w nadziei, że będę mógł uzyskać dostęp i zrzucić pamięć flash układów opartych na C-SKY, takich jak WinnerMicro W800/W801/W806, które są C-SKY CK804FGT.




Kupiłem 3 w sklepie YouKeyi https://www.aliexpress.com/item/1005006999051681.html



Korzystając z opracowań cjackera na https://github.com/cjacker/cklink-lite-fw-convertor, możemy przekonwertować plik "cklink_lite.hex" dostarczany z serwerem debugowania T-Head, aby działał na STM32 po flashowaniu. cjacker dostarcza również plik binarny, który został już przekonwertowany https://github.com/cjacker/cklink-lite-fw-con.../blob/main/cklink_lite-2.36_for-stm32f103.hex, a wersję 2.37 wraz ze skryptem konwersji Pythona kompatybilnym z Windows można znaleźć w tym PR https://github.com/cjacker/cklink-lite-fw-convertor/pull/1/files. Załączę tutaj wszystkie pliki dla bezpiecznego przechowywania.

Ale jak zaprogramować STM32? SWD - Serial Wire Debug!

Używając jednego z tych tanich klonów programatora/debuggera J-Link możemy flashować STM32 używając J-Flash.

.

J-Flash można pobrać ze strony https://www.segger.com/products/debug-probes/j-link/technology/flash-download/

Podłącz w następujący sposób
J-Link GND -> STM32 GND
J-Link SWDIO -> STM32 SWIO
J-Link SWCLK -> STM32 SWCLK
J-Link 3V3/VCC - <odłączony>



uruchom J-Flash, utwórz nowy projekt i wybierz "STM32F103CB" (128kb) z listy urządzeń docelowych



przy zasilaniu obu urządzeń z ich portów micro-USB "Target" i "Connect" w menu J-Flash powinny zobaczyć pomyślne połączenie urządzenia


Teraz można skasować/zapisać lub odczytać cały chip z menu Target-> Manual Programming . Najpierw przeczytałem demo emulatora pamięci USB Keil, które zostało dostarczone z STM32.



Aby sflashować cklink_lite-2.37_for-stm32f103.hex wystarczy przeciągnąć plik do okna J-Flash -> Erase Chip -> Program & Verify



Wyłącz zasilanie STM32 i podłącz go ponownie. W przypadku korzystania z systemu Windows powinien on zostać wykryty jako urządzenie C-Sky CKLink-Lite



Teraz musimy połączyć się z serwerem debugowania T-Head, abyśmy mogli połączyć się z urządzeniami opartymi na C-SKY.

Zarejestruj się i pobierz serwer debugowania T-Head ze strony https://www..xrvm.cn/community/download?id=4380347564587814912 - będę demonstrował wariant Windows. Załączam pliki do pobrania dla systemów Windows i Linux w najnowszej wersji w momencie pisania, a także instrukcję debugowania w formacie PDF.

Procesor, z którym będę się łączył, to CK804 w płytce deweloperskiej Hi-Link HLK-W806-KIT, tak samo jak wyjaśniono tutaj https://github.com/cjacker/opensource-toolcha...your-own-ck-link-lite-debugger-with-stm32f103

STM32 jest podłączony do HLK w następujący sposób




Po podłączeniu zasilania do STM32 i W806, uruchomienie aplikacji DebugServerConsole powinno przełączyć procesor w tryb debugowania i wyświetlić informacje o wersji oprogramowania CK-Link i procesorze W806.





Wyodrębnij załączony plik w806.elf i umieść go w folderze \bin obok pliku wykonywalnego konsoli debugowania - C:\Users\xxxx\AppData\Roaming\T-Head\T-HeadDebugServer\bin jeśli został zainstalowany w domyślnej lokalizacji.



Informacje o pliku elf można uzyskać za pomocą polecenia flash -al w806.elf z konsoli debugowania.

DebuggerServer$ flash -al w806.elf


Dla porównania, cała lista poleceń flash jest następująca



więc powinniśmy być w stanie zrzucić zawartość flash W806 za pomocą polecenia takiego jak to



te argumenty oznaczają:



Zrzut wydaje się działać. 1mb zajął 56 sekund.

.

Zrzut ląduje w folderze \bin


Wynikowy plik wydaje się zawierać dane, a nawet zwykły tekst z W806 demo sflashowanego przy użyciu Upgrade Tools .

Niestety flashowanie z powrotem za pomocą polecenia flash program -f blinkydump.bin -b -a 0x080000 -al w806.elf nie wydaje się skutkować uruchomieniem aplikacji, pozostawiając urządzenie oczekujące na przesłanie w trybie xmodem "CCCCCCCCCCCCC"



Ciekawe jest również to, że wymazanie pamięci flash, mimo że "udane", nie wydaje się faktycznie zerować pamięci flash, kolejny zrzut wydaje się być prawie identyczny z tym wykonanym przed wymazaniem - jest to również prawdą, jeśli używa się wm_tool (wm_tool_1.0.4.exe -c com79 -eo all) do wymazania W806 przez UART - brak pustej pamięci flash, chociaż wydaje się, że po wymazaniu przechodzi w tryb CCCCC, więc może zmienia jakiś bajt, aby oznaczyć go jako pusty?
wypróbowane polecenia wymazywania konsoli debugowania:

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

Inne obserwacje:

Port COM wysyła to podczas operacji odczytu

i to podczas zapisu


Do tego właśnie doszedłem. Działające przywracanie flasha myślę, że jest priorytetową rzeczą do dopracowania. Niestety nie mam żadnych urządzeń C-Sky z wgranym oryginalnym firmware, żeby wrzucić coś nowego i ciekawego od takiej firmy jak Tuya.

od czasu opublikowania, przyjąłem inne podejście. Otworzyłem Upgrade_Tools_V1.5.9.exe za pomocą pyinstxtractor w poszukiwaniu głównego kodu flashowania. Najciekawsze rzeczy (które do tej pory widziałem) znajdują się w

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

po uncompyle6 na każdym z nich widzimy polecenia takie jak te, które będą używane do zwracania informacji widocznych w GUI Upgrade Tools podczas flashowania







Te i inne polecenia można znaleźć w różnych dokumentacjach WinnerMicro, np. https://arduino.winnermicro.com/w800/en/2.3-beta.1/component_guides/rom.html

Wiemy, że GUI nie oferuje opcji odczytu pamięci flash, ale w kodzie może być coś, co sugeruje, że jest to możliwe.

W SerialThread.py:

.

ale jak i co musi być uruchomione na chipie, zanim te polecenia będą mogły zostać odebrane i wykonane?



nie ma śladu w800_fls_erase.img w żadnej z dotychczasowych ekstrakcji. Po kilku godzinach prób okazało się, że jest to wirtualna ścieżka w jakimś zasobie Qt. Jest on złożony z tego ciągu kodu bajtowego Pythona w icons_rc.py .



Potwierdzenie, że ekstrakcja była prawidłowa, wymagało trochę pracy.
Tak się składa, że ten sam kod można również zobaczyć w przeglądarce pamięci na żywo HxD. Oto początek tych samych danych, co w przypadku ekstrakcji kodu bajtowego





Używając SerialThread jako punktu odniesienia GPT i ja stworzyliśmy skrypt naśladujący resetowanie urządzenia za pomocą komendy AT+Z i RTS, czekanie na Xmodem CCC, wgrywanie flash stub i wysyłanie komend. Ten skrypt pobiera wifi mac, ble mac, flash ID i informacje o wzmocnieniu z urządzenia, pyta również, który port com chcesz użyć jako pierwszy.



Flash ID 85, 15 = producent i rozmiar, czyli Puya i 2mb.

Oficjalne narzędzie używa tego do wykrywania rozmiaru pamięci flash



Skrypt poprawnie wykrywa 14 jako rozmiar flash na W806 - 1MB


(wifi i ble macs są FF nawet w GUI flasher tool, więc nie martw się o to)

co z dostosowaniem odczytu flasha, aby można było przechwycić całe 2mb?


w zrzucie widzimy dane przy 2400, obraz główny


i kilka innych bitów przed 0 i 2000






Miałem do czynienia z kilkoma odmianami skryptu i wydaje się, że czas i płukanie są kluczowe dla czystego zrzutu. Często bez odpowiedniego spłukiwania lub pauzy koniec lub początek flasha zawiera Xmodem CCC.

Bawiłem się również z set gain trochę, ale myślę, że jest to w pamięci ROM, więc nie można tego zmienić. Moje 3 płyty zwracają to jednak dla odczytu wzmocnienia

HLK-W806


HLK-W801


HLK-W800


W ConfigHelper.py widzimy wartość wzmocnienia dla W600 i W800. Nie jestem pewien, dlaczego jest to ustawione ani jaki jest tego efekt. Nie wydaje się to być trwałe.



Myślę, że to na razie tyle. Dołączę skrypty użyte na zrzutach ekranu (i więcej - niektóre mogą nie działać), stub i pliki py. Jeśli ktoś chce więcej, dajcie znać.

TODO/pytania:
Skąd oficjalny flasher zaczyna zapis i jak inaczej obsługuje pliki .fls i .img?
Czy kopia zapasowa urządzenia może zostać zarchiwizowana w celu utworzenia działającego urządzenia?
Jakie są różnice między kopią zapasową wykonaną metodą CKLink i UART?
Dlaczego W806 nie odczytuje pamięci flash, a W800/W801 tak?
Czy to działa na prawdziwym urządzeniu? I czy ktoś ma prawdziwy W800 z nienaruszonym fabrycznym firmware Tuya?

Przypomniałem sobie, że mam Hi-Link HLK-B36 - moduł W800 - do którego nie sflashowałem OBK. Nadal uruchamia firmware Hi-Link





i nadaje AP "HI-LINK-184C"


Zrzut przy użyciu w800_flash_read_crc_flush_double.py nie pokazuje żadnego przechwyconego CCCC, podczas gdy w800_flash_read.py tak.



wyraźnie widzimy dane w oczekiwanych punktach pliku



i oznaki HLK


mimo lutowania i krótkich kabli nie udało mi się uzyskać połączenia metodą CK-Link z CPU

i zgodnie z częścią Bouffalo Lab możemy również połączyć się z BL602 MCU za pomocą serwera debugowania T-Head
https://github.com/cjacker/opensource-toolchain-bouffalo-lab





Używam BL602 Ai-Thinker NodeMCU Ai-WB2-32S-Kit


Przypisania STM32F103 dla BL

STM32F103	Funkcja	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

Być może w ten sposób można naprawić BL602 @p.kaczmarek2, jeśli UART się nie powiedzie

wyższa wersja plików ck-link lite. przekonwertowane i oryginalne - 2.38

Czy ktoś ma plik TXW8301 FLASH ALGORITHM ELF? Otrzymuję błąd "ERROR: Current CPU is not in debug-mode, can't do any flash operations" podczas próby zrzucenia pamięci flash przy użyciu innych plików elf.

P.S.

Pamięć flash to SPI 16Mbit W25Q16JVSSIG

Procesor wewnątrz TXW8301 to CK803SG:

.

Nie widzę żadnych dodatkowych plików algorytmu flash w TXW8301 SDK.

Twój błąd brzmi bardziej jak niepołączenie niż problem z odczytem flash.

Wygląda na to, że wariant CK803SG został pomyślnie odczytany tutaj https://www.elektroda.com/rtvforum/topic4129331.html

Może jest to rodzaj błędu, którego można się spodziewać po nieprawidłowym pliku algo flash?

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

Czy próbowałeś niższych prędkości ICE Clk?

divadiow napisał:

Nie widzę żadnych dodatkowych plików algorytmów flash w TXW8301 SDK.

TXW8301 SDK nigdy nie zawierał plików algorytmów flash. Pliki te były dostarczane wraz z programatorem. Widzę te pliki:

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

Ale nie ma żadnych plików TXW83X!

Cytat:

Twój błąd brzmi bardziej jak niepołączenie niż problem z odczytem flash.

Wygląda na to, że wariant CK803SG został pomyślnie odczytany tutaj https://www.elektroda.com/rtvforum/topic4129331.html

.

Ten link dotyczy TXW816, dla którego plik algorytmu jest zdecydowanie obecny.

Cytat:

Może to jest rodzaj błędu, którego można się spodziewać po nieprawidłowym pliku algo flash?

Dokładnie, ponieważ nie mam pliku TXW83X FLASH ALGORITHM. To było moje pytanie.

Cytat:

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

Czy próbowałeś niższych prędkości ICE Clk?

Spróbuję, ale wygląda na to, że aplikacja serwera debugowania Linux po prostu ignoruje opcję wiersza poleceń prędkości ICE, a nie używam systemu Windows.

P.S. Próbowałem z 12 kHz



Ten sam błąd

na pewno. Pliki algorytmów TXW80X i TX81X zostały pobrane z zestawów SDK dla tych platform, więc zastanawiałem się, czy zestaw SDK TXW8301 może również zawierać niektóre specyficzne dla tej platformy

Cytat:

Może to jest rodzaj błędu, którego można się spodziewać po nieprawidłowym pliku flash algo?

w odniesieniu do tego błędu: https://obrazki.elektroda.pl/6958044300_1755725962_bigthumb.jpg

W każdym razie nie jestem pewien, co zasugerować dalej w odniesieniu do TXW8301 i zrzutu / programowania pamięci flash.

Ok, błąd trybu debugowania zniknął zaraz po podłączeniu gdb do debugservera. Ale pojawił się nowy błąd:

Cytat:

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
BŁĄD: Załaduj plik algorytmu Flash: Nie udało się załadować algorytmu do celu.
Nie można uruchomić FlashAlgorithm do bkpt_label, przywrócić zniszczonych rejestrów i pamięci.
Zrzut nie powiódł się.

Teraz jest zdecydowanie jasne, że potrzebny jest odpowiedni plik elf TXW83x.

Zaczynam myśleć, że to może być inna bestia i może być wymagane inne podejście. czy mogę zapytać, jakie masz urządzenie z TXW8301? Nie mam żadnego, więc mogę spróbować coś znaleźć, jeśli jest wystarczająco tanie.

Jest ich mnóstwo. Słynny jest LilyGO T-Hallow, drugi to MaduinoZeroWiFiHalow i wiele innych. Widzę, że częściowo masz rację - w SDK jest projekt szablonu flash. Zwykle umieszczają skompilowany plik ELF, ale nie w przypadku TXW8301. Spróbuję go skompilować i przetestować. Obecnie głównym problemem jest dla mnie wadliwy serwer debugowania. Ciągle nie udaje mu się przełączyć procesora w tryb debugowania. Ale przykład API debugowania, który jest dostarczany z serwerem debugowania, stale może to robić:

divadiow napisał:

Ale jak zaprogramować STM32? SWD - Serial Wire Debug!

Używając jednego z tych tanich programatorów/debuggerów J-Link możemy flashować STM32 używając J-Flash.

Może pozwolisz na krótkie alternatywne podejście (jeśli tam jest, a ja po prostu przeoczyłem, przepraszam).

Nie miałem pod ręką programatora J-Link, więc spróbowałem z prostym UART (tak jak to zrobiono tutaj ).

Podłącz
GND -> G
UARTs RX -> A9
UART TX -> A10

Pobierz Flasher ze strony ST https://www.st.com/en/development-tools/flasher-stm32.html#get-software (musisz uzyskać kod dostępu z ważnym adresem e-mail, mailinator.com działa )

Proces jest prosty, ale trzeba ustawić zworkę "Boot0" (tę naprzeciwko przycisku):

.









Ponowne ustawienie obu zworek "BOOT" na 0 i ponowne podłączenie STM do USB:




Gotowe!

Oh wow. super! to trochę łatwiejsze

Dodano po 36 [sekundach]: .

łatwiejsze, ponieważ nie wymaga J-Link

Tak, łatwiej dla mnie, bo nie znalazłem mojego klona J-Link .
Dzięki za twoją pracę, właśnie z powodzeniem wyrzuciłem moją X5 Cam i sflashowałem OpenTXW81X z pomocą tego i tego postu!

Może chcesz wspomnieć lub nawet lepiej "zintegrować" to podejście w swoim pierwszym poście?
Zachęcamy do wykorzystania wszystkich obrazów lub tekstu

dzięki. na razie dodałem nagłówek notatki o aktualizacji