Qiachip Smart Switch BK7231N/CB2S – Innenansicht, Flashen

Hallo liebe Freunde
Ich präsentiere hier das Innere eines anderen Tuya-Relais, das dieses Mal ein eher ungewöhnliches CB2S-Modul enthält, das auf dem BK7231N-Schaltung basiert (nicht zu verwechseln mit dem BK7231T). Ich werde auch versuchen, SDK dafür vorzubereiten und meine eigene Batch­da­tei darauf hochzuladen. Ich werde beschreiben, welche Tools hierfür nützlich sein können und welche Probleme ich lösen musste, um meiner Software BK7231N-Unterstützung hinzuzufügen. Das Ziel wird wie immer darin bestehen, eine Verbindung zu Home Assistant herzustellen und die Unabhängigkeit von den Servern des Herstellers.

Qiachip Smart Switch
Qiachip ist nur ein weiteres intelligentes Relais, das über Wi-Fi durch die mobile Anwendung des Herstellers gesteuert wird. Es verfügt über einen Knopf am Gehäuse, mit dem man es auch manuell steuern kann. Dieses Mal ist das Set mit ihm ziemlich dürftig:


Der Hersteller empfiehlt dafür die SmartLife-Anwendung, die ich in den vorherigen Themen der Serie beschrieben habe.

Innenansicht des Qiachip Smart Switch
Das Gehäuse wird nur an den Rastnasen gehalten:

Das Layout im Inneren ist klassisch – ein transformatorloses Netzteil auf Basis BP2525:

AMS1117 LDO-Regler (5 V Eingang, 3,3 V Ausgang für Wi-Fi-Modul):

Wi-Fi-Modul – hier CB2S – und ein Transistor zur Steuerung des Relais:


CB2S ist ein Wi-Fi/Bluetooth-Modul, das auf einem 32-Bit-Mikrocontroller BK7231N basiert.
CB2S-Anschlüsse:

Das Layout sieht dem auf BK7231T implementierten WB2S sehr ähnlich:

Diese PWMs sind mit den CB2S-Pins kompatibel – schauen wir uns die Erklärung an:

PWM0 ist P8 – das stimmt.

Flashen des BK7321N
Ich habe das Problem des Flashens der Schwester BK7231T bereits gelöst. Ich betreibe ein universelles Open-Source-Batch-Projekt für diesen Chip.
Leider ist BK7231T nicht BK7231N – die Architektur ist etwas anders. Dies wird beispielsweise durch das Vorhandensein zweier unterschiedlicher Versionen des SDK für diese Chips belegt:
https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231n
https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231t
Ich kenne bereits Version T. N habe ich versucht, ähnlich auszuführen, bin aber schnell auf ein seltsames Problem gestoßen.
Beim Kompilieren aus Cygwin habe ich Folgendes erhalten:

Ich habe herausgefunden, dass es daran liegt, dass Cygwin Windows-Toolchain-Dateien verwenden sollte.
Hier ist die Lösung:
https://github.com/openshwprojects/OpenBK7231N/commit/61b4204aa0677a8fc886f4e6bd4e235337eb1e85

Die nächsten Änderungen, die ich vorgenommen habe, waren das Hinzufügen des SDK zum Repository (wie es in der T-Version war, denn hier musste ich sie von der T-Version kopieren).
Am Ende bin ich bei der Version gelandet, die ich hier gepostet habe:
https://github.com/openshwprojects/OpenBK7231N/
Das so vorbereitete SDK ist mit meiner Anwendung (Tasmota-Äquivalent) für die T-Version kompatibel, die hier verfügbar ist:
https://github.com/openshwprojects/OpenBK7231T_App
Auf der Anwendungsseite musste ich einige Korrekturen vornehmen (z. B. wurden der Name und der Speicherort mehrerer Dateien geändert, außerdem korrigierte Tuya Tippfehler – vorher war es "tuya_hal_storge.h" und jetzt ist es "tuya_hal_storage.h", aber das meiste blieb ähnlich).
Ein weiterer Unterschied zwischen der N- und der T-Version des SDK ist das Vorhandensein des Tuya-Quellcodes – in der N-Version liegt er nur in Form von lib (libtuya.a) vor, und in der T-Version haben wir C-Quellen. Hier meine ich beispielsweise Funktionen wie tuya_hal_flash_read oder tuya_hal_wifi_all_ap_scan.
Auch die Adressen der Speicherabschnitte unterscheiden sich zwischen der N- und T-Version:
https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231n/blob/f95ecac1c9e2c22135332aca88e86b884856373d/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c
https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231t/blob/5e28e1f9a1a9d88425f3fd4b658e895a8ee7b83b/platforms/bk7231t/bk7231t_os/beken378/func/user_driver/BkDriverFlash.c

Ein weiterer Unsinn, den ich beheben musste, war ein Konfigurationsproblem – irgendetwas überschrieb meine BK_PARTITION_NET_PARAM-Abschnitte. Es stellte sich heraus, dass die Einstellung RL_SUPPORT_FAST_CONNECT schuld ist, die die gleiche Adresse erhält, an der sich die Konfiguration befinden soll. Nun, Tuya hat ein Durcheinander im SDK:

Abschließend kompiliert sich die Anwendung:


Anschließen des Flashgeräts
Hier ist alles wie beim zuvor beschriebenen WB2S bzw. WB3S (BK7231T). USB-zu-UART-Konverter und wir schließen nur TX1 und RX1 an:

Darüber hinaus auch CEN, um das Modul zurücksetzen zu können (man kann aber auch ohne CEN zurücksetzen und durch Unterbrechen der Stromversorgung zurücksetzen, solange es nach dem Anschließen des Relais nicht zu einem Reset des USB-Ports aufgrund zu hoher Stromaufnahme kommt). Natürlich auch Masse und Stromversorgung (5V, angeschlossen an den 3,3V-Eingang des LDO-Reglers).


Ein Versuch, einen Batch von BKwriter 1.60 hochzuladen
Zuerst habe ich versucht, dasselbe Programm zu verwenden, mit dem ich den Batch auf BK7231T hochgeladen habe – BKwriter 1.60. Ich habe dort zwei Modi überprüft, einer ist als BK7231 gekennzeichnet:


Im BK7231-Modus kommt es bei der Batch-Überprüfung immer zu einem CRC-Fehler.
Und der zweite BK7231N:


Im BK7231N gibt es einen Fehler beim "Unprotect" des Flash-Speichers. Handelt es sich um eine gesperrte Schaltung?

Versuch, einen Batch mit einem Python-Tool hochzuladen
Mit BKwriter hat es nicht geklappt, aber es gibt eine andere Möglichkeit. Ein von Tuya in Python geschriebenes Tool, verfügbar z. B. hier:
https://github.com/OpenBekenIOT/hid_download_py
Das obige Repo enthält bereits unsere Modifikationen.
In readme dieses Tools wird die N-Version des Chips erwähnt:

Zitat:

For BK7231N, set download address to 0x0, and set -u option.

Wird es funktionieren? Lass es uns versuchen. Ich habe eine solche .bat-Datei entwickelt (man kann sie auch über die cmd-Ebene eingeben):

Ich habe es mit bereits angeschlossenem Modul ausgeführt:

Dann (in der Phase "Getting bus") setze ich das Modul zurück (man kann einen Zyklus mit Anschließen und Trennen der Stromversorgung durchführen, aber ich habe den CEN-Pin für einen Moment mit Masse kurzgeschlossen. Wenn es nicht funktioniert, kann man versuchen einen Pull-Up-Widerstand an CEN anzuschließen und erst dann versuchen mit dem Kurzschluss zur Masse zurückzusetzen) und das Flashen wurde gestartet:

Fertig:

Ohne Fehler hochgeladen. Ich sehe, dass der Konfigurations-AP erscheint – Batch funktioniert!

Was bietet mein Batch?
Mein Batch ist im Grunde das Äquivalent von Tasmota. Wenn es ausgeführt wird, erstellt es seinen eigenen AP:

Die darauf befindliche Konfigurationsseite ist unter IP 192.168.4.1 verfügbar.
Dort kann es mit unserem Router verbunden werden:

Man kann das Modul (seine Pins, ihre Rollen) frei konfigurieren:


Man kann es über MQTT mit Home Assistant verbinden:

Man kann das Modul auch direkt steuern:

Es gibt auch einen automatischen Konfigurator für die von mir getesteten Smart-Geräte:

Vergessen wir auch nicht den Konfigurationsgenerator für Home Assistant, hier:

Mein Batch unterstützt bereits drei Plattformen – BK7231T, BK7231N und XR809. Aber Einzelheiten ein andermal...

PS: Und wenn wir unser Gerät mit OpenBK an unser Wi-Fi anschließen und die ihm per DHCP zugewiesene IP-Adresse wissen möchten, schauen wir am besten auf die Konfigurationsseite unseres Routers und suchen BK anhand des Hostnamens:


Zusammenfassung
Letztendlich gelang es mir jedoch, meine offene Firmware auf diesem Relais basierend auf dem CB2S-Modul (BK7231N) auszuführen. Der Quellcode aus dem SDK musste ein wenig portiert werden, aber zum Glück musste das nur ich tun. Beim Hochladen des Batchs gab es auch ein bisschen Rätselraten, aber ich kann jetzt schon sagen, dass es am Ende auf Folgendes hinausläuft:
1. Wir löten Drähte an RX, TX, CEN und Stromversorgung. RX und TX schließen wir an den UART-USB-Konverter an
2. Wir starten hid_download_py über die Befehlszeile, genauer gesagt python uartprogram W:\GIT\OpenBK7231N\apps\OpenBK7231N_App\output\1.0.0\OpenBK7231N_app_QIO_1.0.0.bin --unprotect -d com10 -w --startaddr 0x0 . Ja, wir laden die QIO-Version hoch
3. Das Programm wartet auf den Reset des Moduls – wir schließen CEN mit Masse kurz (vorzugsweise mit einem Pull up, d. h. einem Widerstand zur Stromversorgung), um das Modul zurückzusetzen
4. Das Programm erkennt den RESET selbst und lädt den Batch hoch
5. Fertig! Den Rest konfigurieren wir über access point Wi-Fi (IP ist 192.168.4.1, wenn sich die Seite nicht öffnet, bedeutet das, dass DHCP nicht gestartet ist – wir können unsere Maschine einfach selbst einstellen, z. B. IP 192.168.4.10 und uns wieder mit dem BK-Netzwerk verbinden)
Die Frage ist, welcher Batch – die neuesten Versionen der Binärdateien sind hier verfügbar:
https://github.com/openshwprojects/OpenBK7231T_App/releases
Weitere Informationen finden Sie in meinen Repositories (README wird aktualisiert):
https://github.com/openshwprojects/OpenBK7231T_App
PS: Von einem der Nutzer weiß ich, dass der Qiachip Smart Switch auch mit WB2S vorkommt – es können also verschiedene Module drin sein. Glücklicherweise wird WB2S auch von meinem Batch unterstützt.


--------------- UPDATE 2023 ---------------
bkWriter 1.60 und hid_download_py wurden durch ein neues Tool mit GUI ersetzt, man kann es von Github herunterladen und die Readme-Datei im Repository lesen. Es wird auf die gleiche Weise verwendet wie die vorherigen Tools, man muss einfach keine Befehle eingeben, sondern nur die Plattform und die Operation auswählen, die man auf der GUI durchführen möchte.
https://github.com/openshwprojects/BK7231GUIFlashTool