Forum: Mikrocontroller und Digitale Elektronik uC für 0,20€ CH552 / CH554 von WCH Billig Micro mit USB Funktion, Chip vorstellung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Thomas (Gast)


Lesenswert?

Thomas T. schrieb:
> Allerdings führt die CPU, sobald DPTR auf 4000h zeigt (und A=0 ist), bei
> einem "MOVC A,@A+DPTR" (Ja, sorry, ich schreibe nur in Assembler...)
> einen Reset durch und startet wieder neu... :-(

Nun sowas ähniches hab ich hier auch schon gesehen.... Hab das bisher 
aber eher auf Programmfehler meinerseits geschoben. Wenn da wirklich ein 
Reset passiert haben die definitiv einen Hack im core.
Aber auch dies wäre ja durchaus wichtig zu wissen.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Thomas schrieb:
> Thomas T. schrieb:
>> Allerdings führt die CPU, sobald DPTR auf 4000h zeigt (und A=0 ist), bei
>> einem "MOVC A,@A+DPTR" (Ja, sorry, ich schreibe nur in Assembler...)
>> einen Reset durch und startet wieder neu... :-(
>
> Nun sowas ähniches hab ich hier auch schon gesehen.... Hab das bisher
> aber eher auf Programmfehler meinerseits geschoben. Wenn da wirklich ein
> Reset passiert haben die definitiv einen Hack im core.
> Aber auch dies wäre ja durchaus wichtig zu wissen.
>
> Thomas



Ich weis leider nicht genau ob das was damit zu tun hat aber wenn ich 
beim verify eine adresse höher als 0x4000 vergleichen wollte gab es auch 
einen Reset.

von Thomas (Gast)


Lesenswert?

Ich bin ein Stück weiter...
1 der Bootloader ist identisch zu dem was wir schon haben.Er entspricht 
dem was Sigint ursprünglich ausgelesen hat.

2. Der Usbcore bleibt stehen sobald ein MOVC mit einem DPTR>=0x4000 
vorkommt.
Keine Ahnung ob es wirklich ein Reset ist da ich keinen Disconnect in 
meinem Reset code habe. Ich halte den Reset aber für wahrscheinlich.

Vermutlich macht es keinen Sinn da weiter zuschauen.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Thomas schrieb:
> 1 der Bootloader ist identisch zu dem was wir schon haben.Er entspricht
> dem was Sigint ursprünglich ausgelesen hat.

Ah mist, hätte man natürlich auch mal so byteweise vergleichen können...

Da beim Flashen ja an den Config Bytes etwas geändert wird, denke ich 
das man sich die mal etwas genauer ansehen muss.

er schreibt vor dem Flashen das als config bytes cmd:

a80e000700ffffffff03000000ff520000

vorher war die ausgelesene config so:
                     Cfg Bytes       Version  SerialNr
a77d1a001f00ffffffffffffffffffd27ff5 00020301 e079b644 fdb755bf

und nach dem schreiben so:
                     Cfg Bytes       Version  SerialNr
a77d1a001f00ffffffff23000000ff527ff5 00020301 e079b644 fdb755bf


hilft so erstmal nicht aber ist ein kleiner überblick

von Thomas T. (knibbel)


Lesenswert?

Aaron C. schrieb:
> Da beim Flashen ja an den Config Bytes etwas geändert wird, denke ich
> das man sich die mal etwas genauer ansehen muss.

Du meinst die Config-Bytes an 3FF8h und 3FF9h? Das ist mir auch 
aufgefallen.

Es könnte aber auch damit zusammenhängen, das die Routinen, welche wir 
als User ins Flash ab 0000h schreiben, einen anderen Status haben als 
der Bootloader selbst.

Ich beziehe mich auf Bit 5 im GLOBAL_CFG-Register (bBOOT_LOAD). Dieses 
Bit ist 1 nach Power-Up und wird bei einem Software-Reset auf 0 gesetzt.

Ich vermute mal, mit diesem Bit wird auch die Möglichkeit freigeschaltet 
ab 3800h bis 3FFFh zu schreiben. Somit kann der Bootloader das 
Config-Byte (3FF8h/3FF9h) schreiben (und auch die anderen Bereiche, die 
aber per Software ausgeklammert werden) und nach einem Software-Reset, 
welcher unsere "User-Software" startet, tappen wir dann im Dunkeln und 
können nicht mehr schreibend auf den Bootloader-Bereich zugreifen...

Das Bit 5 im CLOBAL_CFG-Register ist leider ReadOnly.

So auf Anhieb sehe ich da keine Möglichkeit, das Bit zu setzen...

Gruß
Thomas

von Thomas (Gast)


Lesenswert?

Thomas T. schrieb:
> Das Bit 5 im CLOBAL_CFG-Register ist leider ReadOnly.
>
> So auf Anhieb sehe ich da keine Möglichkeit, das Bit zu setzen...

Ich habe vielleicht eine Lösung für das Problem. Zumindest ist es Wert 
da etwas weiterzuforschen...
Das Bit 5 ist ja zumindest nach einem PowerOn Reset erst mal 1. und wird 
durch den Software Reset gelöscht. Zumindest beim V1 Bootloader gibt 
diesen ICAll. Dieser wird durch eienn Timeout von T0 ausgelöst wenn 
passende Werte im Config Bereich vorhanden sind. Das Bit ist dann immer 
noch 1.
Meine Vermutung ist nun dass ein entsprechendes IAP File in der WCH App 
geladen werden muss dieses IAP File wird dan bei gestztem Bit 5 
ausgeführt.
Diese Möglichkeit gibts beim v2.3 Loader wohl nicht mehr.

Ich werde da mal was programmieren.
Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Gibt es hier jemand mit einem Mac?
Ich habe ein dual CDC Device gebaut was problemlos unter Linux und WIN 
funktioniert. Auf stackoverflow hab ich gelesen dass Macs keine IAD 
Deskriptoren für CDC unterstützen, weshalb ich in der FW einen fix 
eingebaut habe den ich von früher kenne.
Da ich keinen Mac habe bin ich auf eure Hilfe angewiesen...
Meine Fragen:
Seht Ihr auf dem Mac comports? Wenn ja wie viele?
Welche Device ID ist am Mac zu sehen?

Der code sollte auch auf einem ch554 laufen das hab ich aber nicht 
geprüft.
Ein CH551 oder CH553 dürfte nicht gehen da die nur einen UART haben.
Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Mist falsche Datei ausgewählt. Hier die richtige...

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

@Thomas,
 ich habe leider keinen Mac Sry.


Melde mich nun nochmal zum Thema Android App, die habe ich nun 
erfolgreich für Bootloader V2.31 im play store unter diesem link:
https://play.google.com/store/apps/details?id=com.atcnetz.de.ch55xprogrammerV2

insgesamt ist es etwas aufgeräumt und auch erfolgreich für CH551 flashen 
getestet.

Der Fehler weswegen dies nicht funktioniert hatte ist etwas blöd, der 
Flash des CH551 ist wie angenommen auch 16Kb groß ich habe aber beim 
erase befehl immer nur FlashSize/2048 geschrieben also bei angegebenen 
10Kb nur 5 und nicht 8 wie beim CH552. Dadurch hat der Bootloader 
natürich nicht den Flash "Freigegeben"... das musste also nur geändert 
werden und der CH551 lässt sich erfolgreich flashen.



Bitte testet dies doch kurz wer die Möglichkeit hat. auch wegen der 
Bildschirmgröße und dem text innerhalb der Buttons, ob das so mit dem 
Design etwas schöner aussieht.

Und Vielen dank nochmal an Andreas für das Bereitstellen der CH551 Chips 
:)

: Bearbeitet durch User
von Thomas (Gast)


Lesenswert?

Aaron kein Problem. Ich wollte eigentlich nur sicher gehen dass ich 
keinen kompletten Unsinn programmiert habe. Falls sich niemand hier 
meldet werde den code einfach so einstellen.
Ich habe noch ein 2. Beispiel in der Pipeline ein einfaches UsbMidi 
Device. Das ist ein Ableger aus einem alten Projekt.

Thomas

von Andreas B. (andreasb)


Lesenswert?

Thomas schrieb:
> Gibt es hier jemand mit einem Mac?
Habe ich (genau für solche Testzwecke ;-))


> Ich habe ein dual CDC Device gebaut was problemlos unter Linux und WIN
> funktioniert. Auf stackoverflow hab ich gelesen dass Macs keine IAD
> Deskriptoren für CDC unterstützen, weshalb ich in der FW einen fix
> eingebaut habe den ich von früher kenne.
> Da ich keinen Mac habe bin ich auf eure Hilfe angewiesen...
> Meine Fragen:
> Seht Ihr auf dem Mac comports? Wenn ja wie viele?
> Welche Device ID ist am Mac zu sehen?
Werde ich bei Gelegenheit prüfen.

> Der code sollte auch auf einem ch554 laufen das hab ich aber nicht
> geprüft.
> Ein CH551 oder CH553 dürfte nicht gehen da die nur einen UART haben.
> Thomas
CH552? Oder worauf?

Aaron C. schrieb:
> Melde mich nun nochmal zum Thema Android App, die habe ich nun
> erfolgreich für Bootloader V2.31 im play store unter diesem link:
> https://play.google.com/store/apps/details?id=com.atcnetz.de.ch55xprogrammerV2
Werde ich ebenfalls Testen.

> insgesamt ist es etwas aufgeräumt und auch erfolgreich für CH551 flashen
> getestet.
Das ist interessant ;-)


> Und Vielen dank nochmal an Andreas für das Bereitstellen der CH551 Chips
> :)

Gerne.

Ich habe aktuell etwas viel geplant, und blöderweise auch gerade noch 
ein Problem mit dem Handy :-(
Ein neues wartet schon länger, aber jetzt muss ich wohl wechseln, wird 
auch noch etwas ungeplante Zeit kosten...

Also rechnet nicht mit einer schnellen Antwort, aber ich bin auf jeden 
Fall da noch dran...



mfg Andreas

von Thomas (Gast)


Lesenswert?

Andreas B. schrieb:
>> Der code sollte auch auf einem ch554 laufen das hab ich aber nicht
>> geprüft.
>> Ein CH551 oder CH553 dürfte nicht gehen da die nur einen UART haben.
>> Thomas
> CH552? Oder worauf?

Eigentlich sollte der code auf jedem Chip laufen. Es geht mir da in 
erster Linie um die Enum und die Deskriptoren. Ich benutze den CH552.
Der Fix basiert darauf dass man anhand des ersten GetDescriptor(Device) 
erkennen kann ob ein Device unter Win oder am Mac läuft. Zumindest hat 
das früher so funktioniert.

Vielen Dank schon mal.

Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,
hier nun wie versprochen mein Midi example. Wieder als Keil Projekt. Zum 
Ausprobieren einfach das Hex aus dem Out Ordner flashen. Das ganze ist 
für den ch552 gemacht, sollte aber auch auf dem ch554 laufen. Das die 
Ports auf dem 2. Uart liegen geht der ch551 oder ch553 nicht.

Wenn das Ganze auf Aarons Stick läuft werden die LEDs zum Anzeigen des 
Midi Traffic benutzt. Zusätzlich ist auf dem Midi Output active sense 
implementiert.
Getestet unter Win 10, XP und Ubuntu.

Thomas

von Thomas T. (knibbel)


Lesenswert?

Hallo zusammen,

ich habe mich dieses Wochenende mal mit dem Programmieren der CH552 über 
das externe SPI-Interface beschäftigt. Also nicht über die 
USB-Schnittstelle und das WCHISPTool, sondern wie im Datenblatt im 
Kapitel 6.6 "kurz erwähnt" über ein paar Portbits vom Port 1. Während 
der CH552 im Reset verweilt (RST=High) ist das IC wohl wie ein SPI-Slave 
zu betrachten.

Mit einem Arduino als Software-"SPI-Master" habe ich dann versucht dem 
CH552 ein paar Bits zu entlocken. Erfolg hatte ich aber leider keinen, 
nicht einmal einfache Dinge wollten funktionieren...

Folgendes habe ich versucht:

A) Basics
* Erstmal gehe ich davon aus, das im englischen Datenblatt vom CH554 
(das ich für den CH552 nehme) das Signal MOSI fehlt (Im Datenblatt für 
den CH559 ist es drin...). Über diese Leitung werden die Bits vom Master 
(meinem Arduino) zum CH552 gesendet.

* RST ist die ganze Zeit auf High-Pegel, da der Chip im Reset sein 
muss...

* Die SCS-Leitung stellt wohl "Chip Select" dar, aktiv bei Low-Pegel...



B) Das interne SPI-Register
* Wenn man sich über Google Bilder von SPI-Verbindungen anschaut, dann 
findet man schnell interne 8Bit-Schieberegister, welche mittels dem 
SCK-Signal die Daten von MOSI entgegennehmen und über MISO nach 8 Takten 
verzögert wieder ausgeben.

Dieses Verhalten konnte ich leider nicht nachstellen. Egal was ich auch 
machte, das MISO-Signal war konstant auf High-Pegel... :-(

C) Freischalten des Programmier-Modus ???
Ich habe in meiner Verzweiflung mir mal ein Datenblatt vom einem alten 
89S51 angeschaut, welchen man ebenfalls seriell über ein SPI-Interface 
programmieren kann. Dort ist eine Liste "Serial Programming Instruction 
Set" abgebildet, wo auch eine Sequenz zum Freischalten des 
Programmier-Modus aufgeführt wird. Ich habe daraufhin den Arduino so 
programmiert, dass er 65536 mal 4 Bytes zum CH552 sendet: "SCS auf Low", 
HighByte, LowByte, 0x00, 0x00, "SCS auf High". Ich hatte gehofft, dass 
sich dann vielleicht irgendwas auf der MISO-Leitung tut, aber das Signal 
blieb weiterhin auf High-Pegel...




Da das Internet diesbezüglich (nach meiner Suche zu urteilen) absolut 
leer ist, folgende Fragen in die Runde:

1) Hat von Euch jemand selbst was in dieser Richtung unternommen?

2) Hat von Euch jemand irgendwo was bezüglich der externen 
SPI-Programmiermöglichkeit gefunden?

3) Gibt es für den CH552 auch ein "Serial Programming Instruction Set"?

4) Und warum kriege ich nur High-Pegel auf MISO?


Gruß
Thomas

von Thomas (Gast)


Lesenswert?

Thomas T. schrieb:
> 2) Hat von Euch jemand irgendwo was bezüglich der externen
> SPI-Programmiermöglichkeit gefunden?

Nicht viel aber ein Ahnhaltspunkt. Leider ist da keine Software oder 
Firmware dabei.
Der Programmer benutzt einen ch559.

http://www.wch.xx/public/uploads/file/20170315/1489557538760199.rar

xx durch cn ersetzen

Thomas

von Thomas T. (knibbel)


Lesenswert?

Thomas schrieb:
> Thomas T. schrieb:
>> 2) Hat von Euch jemand irgendwo was bezüglich der externen
>> SPI-Programmiermöglichkeit gefunden?
>
> Nicht viel aber ein Ahnhaltspunkt. Leider ist da keine Software oder
> Firmware dabei.
> Der Programmer benutzt einen ch559.
>
> http://www.wch.xx/public/uploads/file/20170315/1489557538760199.rar
>
> xx durch cn ersetzen
>
> Thomas

Danke für den Link.

In dem rar-Archiv sind zwei Dateien, ein PDF und ein File mit der Endung 
DDB.

Ich konnte mir leider nur das PDF anschauen, aber da kann ich nur draus 
entnehmen, dass wenigstens keine "Multi-Level"-Signale verwendet 
werden...

Das DDB-File scheint eine Projektdatei (oder ein Schaltplan) für Protel 
/ Altium Designer zu sein. Aber damit kann ich leider nichts anfangen...

Gruß
Thomas

von Harald (Gast)


Lesenswert?

@Harter Kern:
Darf ich bitte eine vermutlich blöde Frage stellen, ich habe versucht, 
die entscheidende Stelle zu finden aber es erschließt sich mir nicht:
Ganz zu Anfang hat Aaron doch berichtet, dass sich die Controller direkt 
per USB programmieren lassen. Warum wird hier maßgeblich seit vielen 
vielen Beiträgen über den neuen Bootloader gesprochen? Oder ist das nur 
für die Programmierung per Android relevant?
Danke für die Aufklärung und mein Respekt für das Engagement!

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Harald schrieb:
> @Harter Kern:
> Darf ich bitte eine vermutlich blöde Frage stellen, ich habe versucht,
> die entscheidende Stelle zu finden aber es erschließt sich mir nicht:
> Ganz zu Anfang hat Aaron doch berichtet, dass sich die Controller direkt
> per USB programmieren lassen. Warum wird hier maßgeblich seit vielen
> vielen Beiträgen über den neuen Bootloader gesprochen? Oder ist das nur
> für die Programmierung per Android relevant?
> Danke für die Aufklärung und mein Respekt für das Engagement!

Moin Harald, es wurde versucht den vorhandenen Bootloader durch einen 
eigenen zu ersetzen, dies hat soweit leider nicht funktioniert da wohl 
ein Schreibschutz auf dem bereich ist.

Es hat für die Grundsätzliche Funktion keinen Einfluss und alles 
funktioniert auch mit dem Originalen Bootloader, der Chip kann so ohne 
weitere Hardware Programmiert werden.

Zusätzlich gab es con WCH ein Update des Bootloaders auf den Chips in 
den Letzten Monaten, dafür musste dieser ausgelesen werden um die 
Allgemeine Funktion zu verstehen und auch die App darauf Kompatibel zu 
machen.

von Thomas (Gast)


Lesenswert?

Thomas T. schrieb:
> Das DDB-File scheint eine Projektdatei (oder ein Schaltplan) für Protel
> / Altium Designer zu sein. Aber damit kann ich leider nichts anfangen...

Ist es nicht. Im Header steht JET DB Google meint das ist access97. Ein 
MDB Viewer sagt allerdings dass ein PW vergeben ist. Ich besitze kein 
Access.

Ich habe Mal im Hex Mode reingeschaut das scheint schematics und pcb im 
Pads 4.0 Format zu sein. Zumindest deuten Strings darauf hin.

Thomas

von spess53 (Gast)


Lesenswert?

Hi

>Ist es nicht. Im Header steht JET DB Google meint das ist access97.

Protel benutzt Access-Datenbanken für die Projekt-Files.

MfG Spess

von Stephan (Gast)


Angehängte Dateien:

Lesenswert?

Ist Protel.

von Thomas (Gast)


Lesenswert?

spess53 schrieb:
> Protel benutzt Access-Datenbanken für die Projekt-Files.

OK das wusste ich nicht. Hab mal etwas mit dem Import gespielt....

Der Offline flasher bedient am Programiersockel nur USB und uart nix mit 
SPI.
Das Teil ist also einfach nur eine aufgeblasene Version um den 
Bootloader zu starten. Deswegen gibt's auch keine extra Software.
Wenn ich das richtig interpretiere wird mit dem Programmer einfach ein 
zuvor eingelesenes Programm an den Sockel geschickt. Ist wohl dazu 
gedacht ein fertiges Programm auf viele Bausteine zu flashen bevor diese 
eingelötet sind.
Jedenfalls nicht das was ich vermutet hatte.

Thomas

von Harald (Gast)


Lesenswert?

Aaron C. schrieb:

> es wurde versucht den vorhandenen Bootloader durch einen
> eigenen zu ersetzen, dies hat soweit leider nicht funktioniert da wohl
> ein Schreibschutz auf dem bereich ist.
>


Danke!

von K. L. (Gast)


Lesenswert?

Hab mich hier jetzt duchgewühlt. Gibt es eine Projektseite?

von Thomas (Gast)


Lesenswert?

Ich hab dieses Wochenende Mal etwas weitergeforscht...

Da ich vorwiegend unter Win arbeite hatte ich bisher mit einer 
zusätzlichen Vid Pid und libusb gearbeitet. Das hat den Vorteil daß bei 
Tests nie die WCH ID verwendet wird und ich deshalb jederzeit einen 
Download mit dem ISP Tool anwerfen konnte. Der Nachteil war halt dass 
nie der Original loader angesprochen wurde. Hat mich bisher aber nicht 
so gestört. Jetzt ist mir allerdings aufgefallen dass im Isptool die IAP 
Funktion nicht arbeitet, ob Bug oder Absicht keine Ahnung.
Eine Anfrage bei WCH ergab nur ausweichende Andworten. Ich glaube das 
der Kontakt dort keine Ahnung hat und nur als Übersetzer fungiert.
Zusätzlich habe ich seit letzter Woche den Verdacht dass das Isptool 
nicht alle Funktionen erlaubt die theoretisch möglich wären.

Nun stand ich vor dem Dilemma entweder alles unter Linux mit libusb zu 
machen oder unter win zwischen ch375.sys und libusb umzuschalten.

WCH verwendet eine wrapper dll um ihren Treiber anzusprechen. Da diese 
dll relativ klein ist hab ich die einfach durch den IDA geschickt. Da 
sind etwa 30 Funktionen exportiert um alles Mögliche anzustellen.
Also hab ich mir für meinen Compiler schnell eine passende Import lib 
generiert und
ein paar kurze Tests gemacht. Das sieht gut aus. Ich habe damit 
erfolgreich die beiden Bulkeps des Bootloaders ansprechen können.

Mehr dazu in Kürze.

Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Hier das entsprechende Header File um die ch375dll.dll anzusprechen. Es 
sind allerdings nur 5 Funktionen drin. Diese reichen um den Bootloader 
anzusprechen

Im Moment gibt's noch keinen code. Im Kommentar hab ich beschrieben wie 
man eine entsprechende Import lib generiert allerdings nur für Borland 
/Inprice oder wie auch immer die gerade heißen.

Thomas

von Thomas (Gast)


Lesenswert?

Thomas T. schrieb:
> C) Freischalten des Programmier-Modus ???

Nun vielleicht nicht direkt passend zum SPI Programmiermodus aber es ist 
mir heute gelungen das Bit15 im Config Word zu setzen (Code_Protect) 
ebenso wie Bit13 und Bit12. Diese Bits waren bisher bei mir gelöscht. 
Ans Bootloader Bit hab ich mich nicht rangetraut da dies entgültige 
wäre.
WCH behauptet ja dass Bit 15 und 14 nur per Programmer geändert werden 
kann.
Mehr noch die sagen wenn man Bit14 gelöscht haben will muss man passend 
programierte Chips ab Factory bestellen.

Es ist aber einfach so dass im ISPTOOL da nichts vorgehen ist. Gehen 
würde es sehr wohl.
Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Thomas schrieb:
> Thomas T. schrieb:
>> C) Freischalten des Programmier-Modus ???
>
> Nun vielleicht nicht direkt passend zum SPI Programmiermodus aber es ist
> mir heute gelungen das Bit15 im Config Word zu setzen (Code_Protect)
> ebenso wie Bit13 und Bit12. Diese Bits waren bisher bei mir gelöscht.
> Ans Bootloader Bit hab ich mich nicht rangetraut da dies entgültige
> wäre.
> WCH behauptet ja dass Bit 15 und 14 nur per Programmer geändert werden
> kann.
> Mehr noch die sagen wenn man Bit14 gelöscht haben will muss man passend
> programierte Chips ab Factory bestellen.
>
> Es ist aber einfach so dass im ISPTOOL da nichts vorgehen ist. Gehen
> würde es sehr wohl.
> Thomas


 das hört sich super gut an. Wie hast du es geschafft? Oder bist du da 
noch nicht soweit es zu veröffentlichen?

von Thomas (Gast)


Lesenswert?

Aaron C. schrieb:
> das hört sich super gut an. Wie hast du es geschafft? Oder bist du da
> noch nicht soweit es zu veröffentlichen?

Ein (vorzeigbares) Programm hab ich noch nicht, das kommt vielleicht 
noch.
Das Prinzip ist aber ziemlich einfach.
Wichtig dabei ist das der Bootloader per HW contition gestartet wird 
nicht so wie ich das immer mache mit dem SW1 da sonst bBOOT_LOAD nicht 
gesetzt ist und das Flashen im Bootloader Bereich nicht funktioniert.

Benutzt habe ich die Kommandos 0xB9 zum Lesen und 0xB8 zum Schreiben.
(V1.1) Bootloader. 0xB9 liefert dabei die letzten 8 Bytes. 0xB8 0x02 
0xFF 0xF2
setzt alle 4 Bits auf 1.
Weil das ISP Tool das nicht kann hab ich die DLL mit dem gezeigten 
Header direkt angesprochen. Das Bootloader Bit hab ich erst Mal außen 
vor gelassen weil man bei gelöschten Bit nie mehr per HW contition in 
den loader kommt und per call das Flashen im Loadersegment nicht 
funktioniert.

Du kannst das gleiche auch in deine App einbauen.

Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen hier eine neue Version meines Flash dumpers. Das Auslesen 
dürfte nun deutlich schneller sein als bisher, da die Attack Funktion 
bei häufiger auftretenden Bytes früher zum Ziel kommt.
Gleichzeitig auch das erste Programm was die WCH dll Funktionen benutzt, 
weshalb das Wchisptool installiert sein muss. Es werden nach dem 
Auslesen 2 Files erzeugt. firmware.hex und firmware.bin.

Ich hab das Ding nur mit ch552 getestet. Es sollte aber auf jeden Chip 
laufen solange Bootloader V1.1 installiert ist.
Zum übersetzen reichen die free comandline tools von Borland

Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Ein kleines Update zum Flashdumper. Der sollte nun auch mit v2.31 
umgehen können. Da ich keinen Chip habe der den neuen loader benutzt hab 
ich das ganze nur mit dem Fakeloader überprüft. Es ist keine Überprüfung 
der Chip id drin deshalb sollte es mit allen Chips 551 .. 554 
funktionieren.
Mich würde insbesondere interessieren was bei einem ch551 passiert.
Außerdem interessiert mich besonders ob das Ding korrekt mit v2.31 Chips 
umgeht.
Noch ein Hinweis.
Bei v2.31 Chips gibt es die Einschränkung dass der dumper nur arbeitet 
wenn noch kein Download z.b mit dem ISP Tool gemacht wurde. Das liegt 
daran dass mein Programm auf den original bootkey angewiesen ist.
Also immer neu den Bootloader starten vor dem dumpen. Bei V1.1 gibt's 
diese Einschränkung nicht

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Angehängte Dateien:

Lesenswert?

Habs direkt mal getestet, 1. Screenshot CH551 V2.3 Bootloader, 
2.Screenshot CH552 V2.3 Bootloader, 3.Screenshot CH552 V1.1 Bootloader.


Funktioniert bei allen dreien einwandfrei und der inhalt der HEX/Bin 
datei ist auch plausibel.

Auslesen dauert jeweils ca. 3,5 Minuten, bei ca. 20% inhalt im chip.

Sehr gut :)

***** So nach dem fünften versuch auch die richtigen bilder 
hochgeladen.... *****
Der text der bilder ist richtig, bei manchen der text im bild nicht!!!

: Bearbeitet durch User
von Thomas (Gast)


Lesenswert?

Danke für die Tests, das passt alles. Warum manchmal beim ersten Aufruf 
No device kommt ist mir noch nicht ganz klar. Es hat aber damit zu tun 
wie ich die DLL anwende.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Das erstme mal war noch ohne chip. Also das war korrekt mit no device. 
Soweit funktionierte es immer ohne probleme.

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Das einzige was mir aufgefallen ist während des dumping konnte man nicht 
das WCHsp tool öffnen. Erst nach erfolgreichem Dump wurde es dann 
geöffnet denke es können nicht zwei Programme gleichzeitig auf die DLL 
Datei zugreifen

: Bearbeitet durch User
von Thomas (Gast)


Lesenswert?

Das ist interessant, hab ich nie probiert und dürfte ein Bug im ISP Tool 
sein.
Umgekehrt geht es schon. Erst ISP Tool öffnen und dann den dumper.
Wie gesagt in einigen wenigen Fällen findet der dumper manchmal nicht 
den Chip.
Beim 2. Aufruf ist dann alles okay.
Die DLL selbst kann 10 Instanzen.

Thomas

von Cory (Gast)


Lesenswert?

Hi Thomas,

Thanks a lot for your flash dumper.
I used it to correct a bug in an LCD screen produced by Elecrow where 
the
CH522 would send a corrupted USB descriptor.
I tried contacting the manufacturer but they would not give me a new 
firmware so I had to dump it, correct the binary and flash it back.
More details on this project of mine can be found here (Work In 
Progress) 
https://docs.google.com/document/d/1jmeahpnjeAqMjk7ggY5-rmIeFwNI3Z95cOOK5Kqo6uY/edit?usp=sharing.

I believe there are two bugs in your flash reader and I would like to 
help fixing them.
First, the memory at address 0 is not loaded as the loop will exit 
before reading it. In my case I had to manually replace the 0xFF with a 
0x02 to have the correct jump instruction.
Second, it seems that the crc for the Intel hex format is not correct, I 
believe the crc should be the 2 complement of the sum when written at 
then end.

I would be happy to fix those and send you an updated version but the 
source code that your provided last does not run for me: it stops at 
failed to reset key.
Do you have the source code for the last version? freader-2.zip contains 
only the exe.

Thank you in advance and sorry for writing in English, my German is not 
good.

von Thomas Z. (usbman)


Lesenswert?

Hello Cory

great to hear the dumper ist usefull for you. I Just checked and you are 
right about both bugs. I will soon update the reader. Actually i was 
more concerned in getting that thing working. Should have more carefully 
check the output. Because i used the hexoutput from another project i 
did not evaluate it.

Just for the same of interest
How big was your fw? How long did it take to dump it?

Thomas

: Bearbeitet durch User
von Cory (Gast)


Lesenswert?

Hi Thomas,

Thanks for your answer.
I run a benchmark of the dumper and on my CH552, it takes 7min8s to dump 
the 16361bytes of the memory. It includes also the bootloader area.

I'm able to compile the original code from freader.zip (8.6.2019) with 
the following command:
bcc32c.exe .\freader.c

But then when I run I have the error:
failed to reset key

More precisely, the InitKey function the CH375ReadEndP returns rxlen==0.

When I run the freader.exe that comes with the zip, it works fine.
Are there any options to pass to the compiler?
Here is the version of the compiler I use:
Embarcadero C++ 7.30 for Win32 Copyright (c) 2012-2017 Embarcadero 
Technologies, Inc.

Anyway, this is just because I would like to understand more how the 
dumper works in conjunction with the bootloader.

I was able to find that the data at address 0 was not correctly read by 
doing the following test:
From a working hex file, flash the CH552
Convert the hex file to binary using srecord
read the program memory using freader
compare the two binary.

For fixing the firmware of the touchscreen, I had two options:
1-get access to the firmware, fix the binary with the correct USB 
descriptor and flash it again
2-write the application again reading the touchscreen chip over bitbang 
i2c and emulate a touch screen HID USB device to send the touch events 
to the Host.

Thankfully with your code, I was able to directly proceed with 1.

I look forward to testing the new version.
Cory

von Thomas Z. (usbman)


Lesenswert?

Hello Cory,
i am guessing you allready did some translation on this discussion so i 
right start in the middle. These controllers are all using some 
protectiion so there is simply no read back command. Basically there are 
2 loaders with different command sets. For  verify they use some comand 
to read back known scrambled data.
The verify is working on 16byte chunks which have to be correct inorder 
to get a ok back. We know that at the end of the loader there are some 
bytes unused, and i am using that to find the starting point by looking 
for 16 0xFF.
From there its easy just change the fist byte in a loop from 0 to 255. 
If verify reports ok save the byte , dec address move buffer by one 
byte. Do that until address 0 is reached. Its a simple brute force 
attac.
This is nothing new Aaron and me developed that about 2 months ago. The 
new thing is now i am using the original driver to to that and use a 
statistic table to find the final byte earlier which greately improved 
the speed.
For the new loader v2.31 just the key handling is different the rest 
will be still the same. On the new loader they now use a 8 byte key with 
chipserial and chip id encoded.

There are no special params needed to translate. I need to check why it 
does not work for you. Maybe i did some late changes and include a older 
version of the source?

Hope this hlps
Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)



Lesenswert?

Habe nun die "Flash Dump" Funktion auch in die App eingebaut, hatte es 
bisher ja nur für den Bootloader drin aber da sich dieser ja nicht 
ändert macht es wenig sinn und war nur für das einmalige auslesen 
interessant.

Anstatt am Begin des Dumpens nach FF bytes als startwert zu suchen nehme 
ich nun die ersten 7 Bytes vom Bootloader, diese sind ja bekannt und 
werden sich nach jetzigem stand ja nicht ändern.

Es wird dann vom letzten Byte vor dem Bootloader bis zum ersten Byte Ge 
Bruteforced und danach kann man den Dump Teilen, also per Mail etc. oder 
einfach in die Zwischenablage kopieren, als Datei wird er erstmal nicht 
gespeichert da dafür bei Android Schreibrechte gebraucht werden und ich 
möchte erstmal ohne rechte auskommen.

Hier nochmal nen link zur App: 
https://play.google.com/store/apps/details?id=com.atcnetz.de.ch55xprogrammerV2

Die Erste version ist ja leider nicht mehr Aktualisierbar.

Achso, das Dumpen geht mit Version 1 und 2 Bootloadern einwandfrei.

: Bearbeitet durch User
von Cory C. (corentin_c)


Lesenswert?

Hello,

Thomas, thank you for the explanation! that's a very smart way to read 
the whole memory!
I have created a beta version of the flash dump in Python that runs on 
Linux based on the usb programmer wchprog 
(https://github.com/juliuswwj/wchprog).

You can find a pull request here: 
https://github.com/juliuswwj/wchprog/pull/1

I'm waiting to receive dev boards to run more tests with different 
bootloader version.

Cory

von Thomas T. (knibbel)


Lesenswert?

Thomas schrieb:
>
> Ich habe vielleicht eine Lösung für das Problem. Zumindest ist es Wert
> da etwas weiterzuforschen...
> Das Bit 5 ist ja zumindest nach einem PowerOn Reset erst mal 1. und wird
> durch den Software Reset gelöscht. Zumindest beim V1 Bootloader gibt
> diesen ICAll. Dieser wird durch eienn Timeout von T0 ausgelöst wenn
> passende Werte im Config Bereich vorhanden sind. Das Bit ist dann immer
> noch 1.
> Meine Vermutung ist nun dass ein entsprechendes IAP File in der WCH App
> geladen werden muss dieses IAP File wird dan bei gestztem Bit 5
> ausgeführt.

Ich meine für den V1.0-Bootloader eine Möglichkeit gefunden zu haben, um 
ein Programm ohne "Software-Reset" aufzurufen und somit die 
Flashmöglichkeit in den 3800h-Bereich aufrecht zu halten:

Der Code ab 3CE7h im Bootloader V1.0 wird nach einem 'Timeout von T0'(?) 
aufgerufen. Dann werden bestimmte Werte im Bereich ab 3FF4h geprüft und 
wenn diese dort NICHT stehen, wird ein Software-Reset ausgeführt und das 
User-Programm startet ab Adresse 0000h.

Wenn allerdings ab 3FF4h folgendes steht:

57h, A8h, ADDR-Low, ADDR-High

dann wird ein Programm ab ADDR aufgerufen. Also: 3FF4:57,A8,00,30 ruft 
ein Programm ab der Adresse 3000h auf. Dieses startet dann in einem 
Modus, in dem der Bereich des Bootloaders beschreibbar sein sollte.

Möglichkeit zum Testen:

1) Zwei Programme flashen: Eins ab 0000h (vielleicht ein langsames 
LED-Blinken) und ein weiteres ab 3000h (vielleicht ein schnelles 
LED-Blinken)

2) Danach die vier Bytes ab 3FF4h ändern zu 57h, A8h, 00h, 30h

Dann sollte das schnelle LED-Blinken aufgerufen werden.

Zum Abschalten bräuchte man nur das MagicWord 57A8 abändern und dann 
sollte wieder das Programm ab 0000h mittels Software-Reset gestartet 
werden.


> Diese Möglichkeit gibts beim v2.3 Loader wohl nicht mehr.

Ich habe zwar das BIN-File für den Bootloader v2.3 gefunden, aber gibt 
es davon auch schon ein disassembliertes File? Oder vorher weist du, 
dass es den icall beim V2.3 nicht mehr gibt?

Vielleicht war sich dessen auch WCH bewusst und hat die 
icall-Möglichkeit deshalb entfernt...

Gruß
Thomas

PS: An der "Programmierung über SPI"-Front gibt es zwischenzeitlich 
keinerlei Fortschritte. Der Chip reagiert auf keinerlei Bit-Wackeln von 
außen. Vielleicht fehlt auch hier eine Art Code, der die 
'SPI-Slave'-Funktion freischaltet. Auch stelle ich mir die Frage, wie 
eine Programmierung funktionieren soll, wenn die Reset-Leitung nicht 
mehr nach draußen geführt wird. Fällt dann die SPI-Programmierung auch 
flach? Eine Art "High-Voltage" auf die RST-Leitung (oder eine andere 
Leitung) geht nicht, da dann die internen Dioden gegen VCC die höhere 
Spannung auf VCC ableiten. Das habe ich mal in meiner Verzweiflung 
getestet... :-) @Thomas: Vielleicht könntest du mir die Kontaktadresse 
bei WCH per PN schicken. Würde WCH auf Detailfragen diesbezüglich 
antworten oder lassen die derartige Fragen unbeantwortet?

von Thomas Z. (usbman)


Lesenswert?

Eigendlich ist es ja zu heiss um irgendwas vernünftiges zu machen.....
Ich hab das noch nicht bis zum letzten ausgetestet, aber ja das sollte 
funktionieren.
Vermutlich war dazu der IAP call im wchisptool gedacht. Dieser 
funktioniert neben einigen anderen Sachen aber nicht. Was ich ICall 
genannt habe ist eine lib function des Keil compilers. Diese wird 
erzeugt wenn man sowas macht
Bitte nicht schlagen das geht wirklich
1
#define CALL (addr) (((void*)(void) (char Code *) addr) ())
2
    unit16_t addr = 0x2800;
3
    ....
4
    CALL( addr);

Ich habe entsprechendes nicht im v2 loader gefunden weshalb ich das noch 
nicht weiter untersucht habe. Den V2 loader source findest du z.b. auch 
im im Change bootloader2.zip. Dort gibt's ein a51 fille mit Kommentaren 
soweit ich das verstanden habe.

Zum SPI Mode
Eventuell geht da nur nichts weil das entsprechende Bit15 im Configword 
immer gesetzt ist. Ich hab das bei mir zwar schon rücksetzten können 
bringt aber nicht viel, das jedesmal automatisch wchisptool gesetzt 
wird.

Antworten auf diese speziellen Fragen bekommst du von WCH übrigens 
nicht. Ob da eine Sprachbarriere schuld ist oder die nicht wollen mag 
ich nicht beurteilen.


Thomas

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,
falls jemand mit Keil debuggen will, hier die config Dateien zum ISD51 
Debugger.
Damit kann man über eine ser. Schnittstelle unter uVision debuggen. 
ISD51 kann für beide Ports konfiguriert werden, siehe die entsprechenden 
defines im h File.

Wer mehr zu ISD51 wissen will sollte das entsprechende Helpfile lesen.
Es gibt auch ein simples Testprogramm um das debuggen zu testen. Ich 
habe den 2 Port mit 9600 Baud verwendet.

Thomas

von Peter W. (pe_wi)


Lesenswert?

Hallo

Ist es auf einfache Weise möglich über USB "Text" auszugeben?


Viele Grüße

Peter

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Moin. Ist es, am einfachsten mit einem CDC example.

Das ist das quasi ein simulierter uart zu usb wandler und dort lässt 
sich der text mit jedem Serial terminal anzeigen.

Z.b. 
https://github.com/Blinkinlabs/ch554_sdcc/blob/master/examples/usb_device_cdc_i2c/firmware/main.c

: Bearbeitet durch User
von Peter W. (pe_wi)


Lesenswert?

Hallo

Vor einer Weile hatte ich den Chip seriell programmieren können. Jetzt 
bei einem neuen Versuch, war es einfach nicht mehr möglich. Bei den 
vielen Programmierungen die ich durchgeführt habe, ist vermutlich die 
max. Anzahl (200) überschritten. Nach dem 1. Ausfall funktioniert dann 
auch noch der 2. CH554 nicht mehr. Beide starten noch das darauf 
vorhandene Blinkprogramm. Der Bootloader meldet sich aber nicht mehr - 
schade. Damit ist vermutlich der Ausflug mit dem CH554 beendet!

Viele Grüße

Peter

von Thomas Z. (usbman)


Lesenswert?

Mir ist bis jetzt nur ein Weg bekannt den Loader dauerhaft zu 
deaktivieren. Dazu muss das Bit 14 im Configword geändert werden was 
zwar möglich ist aber nicht einfach so zu realisieren ist.
Ich glaube auch nicht dass die Überschreitung der Prg Zyklen sowas 
bewirken kann. Das würde wohl eher zu einzelnen kaputten Zellen führen. 
Wie programierte du den Chip seriell? Welche Baudrate benutzt du?

Thomas

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Da ich mich schon länger Mal mit dem Config Wizard von Keil beschäftigen 
wollte hab ich mir Mal das ISD51 cfg File vorgenommen um einen Einstieg 
zu wagen.
Der Wizard ist leider nur sehr oberflächlich in der Hilfe beschrieben. 
Es war also Trial and Error angesagt. Wenn man dann Mal kapiert hat wie 
das Teil funktioniert kann man schöne config Menüs generieren.
Im Anhang das Ergebnis für die ISD51 Configuration.
Der Config Editor geht natürlich nur in uVision sonst sind das einfach 
Kommentare.

Thomas

von Peter W. (pe_wi)


Lesenswert?

Hallo

So nachdem beide CH554_Module den Bootloader nicht mehr gestartet haben, 
dachte ich mir, dann kann ich denen auch noch den Rest geben, bevor ich 
sie entsorge... Ich habe dann von meinem selbstgebautem ISP_Tool GND, 
RESET, SCK, MOSI und MISO an das CH554_Modul angeschlossen. Dann mit 
COM1 verbunden............ Und auf einmal meldet sich der Bootlader 
wieder - ich kann es kaum fassen! Haben da irgendwelche Pegel an den 
PIN's den Bootloader wieder auf Linie gebracht? Das 2. Modul ist damit 
auch gerettet.

Die serielle Übertragung geht jetzt auch wieder. Ich habe die 
chinesische Beschreibung des Moduls bemüht und habe festgestellt, daß 
meine Dokumentation falsch war. Die Pins für die serielle Programmierung 
sind:
TXD1 (P1.7) und RXD1 (P1.6).
Das sind gleichzeitig die Anschlüsse für SCK und MISO. Vielleicht ist 
das auch der Grund, daß bei meinen Spielereien mit dem ISP_Tool, der 
Bootloader wieder auf die Reihe gekommen ist.

@ Aaron C
Ich meinte "einfach". Netter Quelltext, aber ich glaube kaum, daß ich 
die 2 Meter Programmcode zum laufen bringe, und vom verstehen bin ich da 
auch weit weg - trotzdem danke.

@ Thomas (Gast)
Ich habe mal "freader-2" laufen lassen. Leider läuft das Programm nicht 
richtig. Irgenwann hängt es, und die files werden nicht erzeugt.
Ich starte natürlich den Bootloader neu, aber der letzte code ist ja 
noch im Speicher.


Viele Grüße

Peter

von Thomas Z. (usbman)


Lesenswert?

Peter W. schrieb:
> @ Thomas (Gast) Ich habe mal "freader-2" laufen lassen. Leider läuft das
> Programm nicht richtig. Irgenwann hängt es, und die files werden nicht
> erzeugt.

mm sollte eigendlich so nicht passieren die Files werden immer erzeugt 
nur halt eventuell mit Unsinn. Welcher Bootloader ist bei dir 
installiert? Was ich mir vorstellen könnte: wenn aus irgendeinem Grund 
der Dptr 0x4000 erreicht bleibt der Usbcore stehen und gibt keine 
Antworten mehr raus.
Was passiert wenn du das dumpen mit ESC irgendwann abbrichst?
Alle Chips mit geraden Nummern verwenden UART 1 Txt1 und Rxt1 für den 
Bootloader, das war schon immer so. Solange du nicht mit der Port cfg 
rumspielst ist das auch der default an den entsprechenden Pins.
Thomas

von Peter W. (pe_wi)


Lesenswert?

Firmware ist 2.31
Mit ESC bricht das Programm ab.
Die Daten werden per USB übertragen?
Wo wird das file abgelegt?

Peter

von Thomas Z. (usbman)


Lesenswert?

Ja die Daten werden per USB übertragen. Die Files werden im gleichen 
Ordner abgelegt wo sich auch freader2 sich befindet. Beachte die beiden 
Bugs zum einen sind die Quersummen im Intel Hex File falsch und das 
1.byte an Addresse 0 ist immer FF. Das sollte im Normalfall 0x02 für 
LJMP sein. Ich hab zwar beides schon gefixt will aber noch warten bis 
ich auch die Einschränkung mit dem Key für v2,.31 gefixt habe.
Das Tool ist allerdings meines Wissens noch nie auf einem ch554 mit 
v2.31 getestet worden.
Solltest du das irgendwie seriell probieren dürfte das nicht 
funktionieren

Thomas

von Cory C. (corentin_c)


Lesenswert?

Hi Peter,

I just pushed a python version of the flash dumper that should support 
the bootloader v2.31.
The program can flash and dump the memory.
Check it out here: https://github.com/sgryco/wchprog/tree/blv2

It is still work in progress and I will continue working on it to merge 
it with v1 support.

Cory

von Peter W. (pe_wi)


Lesenswert?

Thomas Z. schrieb:
> Alle Chips mit geraden Nummern verwenden UART 1 Txt1 und Rxt1 für den
> Bootloader, das war schon immer so. Solange du nicht mit der Port cfg
> rumspielst ist das auch der default an den entsprechenden Pins.

Wie kann ich den Bootloader auf auf UART (TxD/RxD) ändern, und was hat 
es auf sich mit den Pin Bezeichnungen: TxD_/RxD_ und  TxD1_/RxD1_ ?

Peter

von Thomas Z. (usbman)


Lesenswert?

Peter W. schrieb:
> Wie kann ich den Bootloader auf auf UART (TxD/RxD) ändern

Kannst du nicht das ist fest verdrahtet. Vermutlich auch deshalb weil 
bei der 10 Pin Version des ch554 die Portpins für TxT und RxT gar nicht 
rausgeführt sind.
Lediglich Ch551 und ch553 benutzen Uart0 weshalb die auch den V2 loader 
brauchen. Beim V1 loader wird immer Uart1 verwendet.

Die xx_ Bezeichnungen sind für alternative Mappings da, die du über PINF 
einstellen kannst. Kapitel 10 im Datenblatt beschreibt das. Die 
Übersetzung ist aber nicht so dolle.

Thomas

von Thomas Z. (usbman)


Lesenswert?

Peter W. schrieb:
> @ Thomas (Gast) Ich habe mal "freader-2" laufen lassen. Leider läuft das
> Programm nicht richtig. Irgenwann hängt es, und die files werden nicht
> erzeugt.

Ich habe das gestern nachstellen können nachdem ich mit dem Serial Mode 
etwas rumgespielt hatte. Der Reader läuft dann in einen Timeout und 
bricht ab. Ein Neustart des Loaders behebt das dann. Es ist wohl so, 
dass ab dem Zeitpunkt wenn die ersten Bytes seriell Eintreffen der USB 
Mode nicht mehr funktioniert. Den Reader um einen serial Mode zu 
erweitern macht aber nicht so viel Sinn. Bei 57k6 würde das Auslesen 
sehr viel länger dauern.

Da meine 2 Projekte jetzt in der Testphase sind werde ich mich wohl 
nochmal mit den  beiden Loader beschäftigen. Ich will nochmal probieren 
ob ich den V1 loader überschrieben bekomme, wenn ich die Params für den 
ICALL setze.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Angehängte Dateien:

Lesenswert?

@Thomas,

Da ich glücklicherweise einen CH559 ausleihen konnte habe ich dort auch 
mal den Bootloader Ausgelesen.

Vielleicht liest du ja noch mit und kannst reinschauen.

Geflasht wird genauso wie beim CH552 und CH551 aber er ist trotzdem 
anders.

Konnte mit minimalen änderungen auch mit der Android App Flashen und 
Dumpen.

Der CH559 hat 2 USB Anschlüße und Host funktion, das konnte ich 
mittlweile schon erfolgreich austesten bissher aber nur mit Keil und 
nicht SDCC.

Grüße

von Thomas Z. (usbman)


Lesenswert?

Schau ich mir mal an. Ich hab's inzwischen übrigens geschaft in den V1 
Bootloader zu schreiben. Beim V2 loader sehe ich immer noch keinen Weg.
So wie ich die Sache sehe gibt es ohne custom Erweiterung keinen Weg in 
den V2 loader zu schreiben. Ich arbeite im Moment an einem Konzept den 
Loader auszutauschen. Dazu gehört im Endausbau dann auch den Loader zu 
deaktivieren so dass er nicht mehr per HW contition aktiviert werden 
kann. Die Software Aktivierung wird aber weiterhin funktionieren.

Thomas

von Thomas Z. (usbman)


Lesenswert?

Bist du sicher dass das binary vollständig ist? Der Code ergibt Sinn 
wenn man nach 0xF400 disassembliert. Dann entspricht er in der 
Grndstruktur dem v2.31 loader.
Allerdings ist das Ende etwas seltsam. Zusätzlich geht der SerialHandler 
wohl nur auf uart0.

Alles weitere muss sich wohl zeigen

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Das Ging ja fix,

Finde gut das du noch immer dabei bist :D



Der CH559 hat ja 0xFFFF Flash size und der Bootloader geht von

0xF400 bis 0XFFFD also das könnte schon hinkommen, ich hatte mal den 
gesamten bereich ausgelesen da kommt aber nicht mehr. Sollte also 
komplett sein garantieren kann ich es aber nicht.

Soweit ich es verstanden habe ist der serialHandler auf Uart0 und den 
Alternativen Pins P0.2 und P0.3

von Thomas Z. (usbman)


Lesenswert?

Aaron C. schrieb:
> Das Ging ja fix,
> Finde gut das du noch immer dabei bist :D
Mit dem IDA geht es recht schnell einen ersten Disassemblerlauf zu 
machen. Auch weil wir mittlerweile genügend Referenzen haben.

Für mich sieht es so aus, dass dieser Loader eine alte Version des v2.31 
Loaders ist. Es gibt beispielsweise noch den I_CALL aus dem V1 loader. 
Es dürfte nicht allzu kompliziert werden den in vernünftiges Format zu 
bringen.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Habs nun auch mal richtig in IDA einladen können, hatte vorher noch 
nicht die Loading Adresse hinbekommen.

Man kanns aufjedenfall erkennen, aber denke da bist du besser drin.
Leider geht mit der Datei ja Kein Pseudocode, das wäre einfacher.

Es scheint soweit auch vieles gleich wie bei den CH552 zu funktionieren,

Also Dataflash Lesen, Key setzen und Flashen etc.

von Thomas Z. (usbman)


Lesenswert?

Ja die Chinesen halt....
Auch wenn sich das Ding als v2.31 meldet ich werde es V2.30 nennen schon 
alleine deshalb weil eine Dispatcher Funktion fehlt. Nicht Mal die API 
ist 100% identisch.
Ich frage mich wie die das mit der Versionskontrolle hinbekommen.
Wahrscheinlich wissen die selbst nicht so genau welcher Chip mit welchem 
Loader ausgeliefert wird.

Thomas

von Thomas Z. (usbman)


Lesenswert?

Ich muss mich korrigieren die API ist identisch. Allerdings ist der 
CH559 deutlich komplexer. Auch ist die SFR Belegung an einigen Stellen 
abweichend. Zusätzlich gibt es einige Register im XData Bereich z.b Led 
und USB.
Aaron kennst du ein englisches Datenblatt zum CH559?

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Thomas Z. schrieb:
> Ich muss mich korrigieren die API ist identisch. Allerdings ist der
> CH559 deutlich komplexer. Auch ist die SFR Belegung an einigen Stellen
> abweichend. Zusätzlich gibt es einige Register im XData Bereich z.b Led
> und USB.
> Aaron kennst du ein englisches Datenblatt zum CH559?
>
> Thomas

Kenne da leider kein englishes Datenblatt zu, nur das chinesische.

werde mich aber für die nächsten 1-2 wochen nicht mit dem Thema 
beschäftigen können da im verdienten Urlaub :D

von S. R. (svenska)


Lesenswert?

Thomas Z. schrieb:
> Ich frage mich wie die das mit der Versionskontrolle hinbekommen.

Nach Bauchgefühl und (ein klein wenig) Erfahrung... kann es durchaus 
sein, dass die schlicht pro Chip einen eigenen Branch von einem eigenen 
Team pflegen lassen. Es stammt also von einer Codebasis ab, neue 
Features werden aber möglicherweise pro Chip neu entwickelt (natürlich 
mit Inspiration vom existierenden Code).

Sowas habe ich bei unseren chinesischen Firmenteilen öfter gesehen.

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Hier die v2.31 loader version vom CH559. Der Code erzeugt ein zum binär 
file von Aaron identisches Image. Bis auf die XSFR Referenzen sind alle 
magic numbers aufgelöst.
Im groben entspricht die Functionalität dem was wir vom v2.31 loadern 
der anderen Chips wissen. Es gibt aber ein paar Unterschiede im Detail.
Interessant ist, dass diese v2.31 Version noch den I_CALL enthält.

Thomas

: Bearbeitet durch User
von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

um die Sache mit den Bootloadern abzuschliesen hier noch mal die 
bearbeiteten Loader. bootloaderV1.a51 ist der V1.1 loader aus meinen 
CH552. bootloaderV2.a51 ist ein V2.31 loader und stammt von sigint aus 
einem CH554. Der Vollständigkeit hab ich auch nochmal das h File dazu 
gepackt, das hat sich aber nicht geändert.

Beide Loader verfügen über identische Optionen zum Einschalten 
verschiedener Features. Solange die Optionen auf 0 stehen und 
Startaddress auf 0x3800 steht wird der Code identisch zu den Originalen 
sein. Bis auf die Serial Option bleibt die Funktionalität mit dem 
Original identisch. Die Optionen lassen sich auch bequem mit dem Config 
Editor von µVision ändern.

Als Bespiel für eine neue Funktion hab ich ein neues cmd 0xAC definiert 
was so ähnlich wie der I_CALL aus V1.1 arbeitet. Die Call addresse wird 
dabei einfach auf den Stack gelegt und mit ret gestartet. Dies dient nur 
als Demo um z.b ein C Programm zu starten.

Die Optionen beeinflussen sich gegenseitig nicht, man kann die je nach 
Bedarf nutzen.

Thomas

von Sigint 1. (sigint)


Lesenswert?

Moin zusammen,
   ich melde mich nach langer Pause zurück. Ich habe leider schon seit 
einiger Zeit nicht mehr verstanden, was ihr so macht. ;-) Das ist weit 
über meinem Wissensniveau. Ich habe allerdings mal etwas mit dem Python 
Flash-dumper rumgespielt und ihn auf Seriell umgebastelt.
https://github.com/SIGINT112/wchprog
By the way: Ich hab den V2.31 Bootloader aus einem CH552G nicht dem 
CH554... sollte aber keinen großen Unterschied machen. Ich möchte auch 
noch meine Hochachtung vor allen Leuten aussprechen, die am 
Entschlüsseln des Chips beteiligt sind. Ihr hat echt unglaubliche 
Skills... ich wünschte, ich könnte ansatzweise verstehen, was ihr macht.

Gruß,
  SIGINT

von Thomas Z. (usbman)


Lesenswert?

Hallo Sigint,
wie lange dauert es bei dir den chip seriel zu dumpen? Im Gegensatz zu 
dir komme ich mit Phyton nicht gut recht. Ich überlege mir dass 
vieleicht doch in meinen Dumper einzubauen.
Du brauchst dein Licht nicht unter den Scheffel zu stellen, immerhin war 
es deine Loaderversion die für mich der Einstieg war.

Thomas

von Sigint 1. (sigint)


Lesenswert?

Hallo Thomas,
  die Zeit ist ein Problem. Der Dump liest leider Byte für Byte. Ich 
muss da immer auf das Timeout von der seriellen Schnittstelle warten. 
Das addiert sich. Das kann man definitiv noch verbessern, wenn man die 
Datenlänge beim lesen kennt. Das werd ich vielleicht am Wochenende mal 
einbauen. Flashen geht deutlich schneller.
Mit Python bin ich erst durch den dumper in Kontakt gekommen... ich kenn 
mich da auch nicht aus. ;-) Mein Ziel ist es für den Dumper eine schöne 
GUI zu basteln... entweder direkt in Python, oder ich portiere das auf 
Java.

Gruß,
  SIGINT

P.S.: Ich musste überigens ein paar Bootloader Kommandos anpassen, damit 
der Dumper mit der seriellen Schnittstelle funktioniert. Ich hab aber 
nicht die geringste Ahnung, was die bewirken... ich muss mir den 
Bootloader mal genauer anschauen. Im Moment fehlt mir leider die Zeit, 
da ich Spätschicht habe. :-|

: Bearbeitet durch User
von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Ich habe am WE eine App gebastelt die für V1.1 den Bootloader tauschen 
kann. Der zu flaschende Bootloader befindet sich in Image.c. Image.c 
wird aus dem Hex des bootloaders gebaut. Hier die V1.1 mit allen 
Optionen außer serial  ein. in \out gibt es auch noch 
test_with_loaders.hex. Das ist ein Dummy Prog mit v2.3 loader ab 0x2800 
und v1.1 ab 0x3000. Der Dummy kann natürlich später mit irgendwas 
überschrieben werden.
In\tools befinden sich exe Files u.A. eine bereinigte Version des 
freaders sowie ein Tool um den IAP Mode einzuschalten.

Die App ist relativ einfach gestrickt und auf Aarons Stick optimiert 
(LEDs,Taster)
Eine kurze Beschreibung findet sich in den Kommentaren.
Das ganze als Keil uVision Projekt. Wie gesagt V1.1 only

Thomas

: Bearbeitet durch User
von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Thomas Z. schrieb:
> Ich habe am WE eine App gebastelt die für V1.1 den Bootloader tauschen
> kann

WOW das ist super cool, werde es heute abend mal austesten und 
rumspielen.

bin gespannt!


Habe nun auch rausgefunden wie WCH selber es gemeint hat mit eigenem 
bootloader brennen, im WCHispTool kann man eine iap datei auswählen und 
die position derer bestimmen, das wäre dann in diesem falle der 
bootloader, in dem eigenen programm springt man dann einfach dort hin um 
den bootloader zu starten.
Es wird aber nicht der pin deaktiviert und man kommt immernoch in den 
echten bootloader, also die verify lücke bleibt immernoch.

Hatte da ein beispiel von WCH gefunden wo auch gezeigt wird was man wie 
in keil einstellen muss um es zum laufen zu bekommen.


Aaron.

von Thomas Z. (usbman)


Lesenswert?

Aaron C. schrieb:
> Hatte da ein beispiel von WCH gefunden wo auch gezeigt wird was man wie
> in keil einstellen muss um es zum laufen zu bekommen.

Ja das Beispiel kenn ich auch, das ist ursprünglich für den CH559 
geschrieben worden. Ich hab das aber nie mit dem WCHIsptool auf dem 
CH552 zum Laufen gebracht. Das WCHIsptool steckt voller Bugs. Es ist 
beispielsweise auch nicht möglich ein Hex zu flaschen was nicht bei 
0x0000 startet.

Hier noch ein paar Infos zum IAP Konzept:
IAP muss eingeschaltet werden und danach das Run Bit gesetzt werden.

0xBA, 0x04, 0x57 0xA8 0x00 0x00 schaltet die IAP Funktion ein.
0xA5, 0x02, 0x01, 0x00 setzt das Run Bit.

Danach startet das Programm  automatisch ab Addresse 0x0000. Das 
Programm lauft dann mit gesetztem bBootLoad und erlaubt so das Schreiben 
im Loaderbereich. Das funktioniert so nur mit V1.1 da bei V2.31 der 
I_CALL in main fehlt. Das ist im wesentlichen das was Thomas T und ich 
weiter oben diskutiert hatten.

Die Quellen des V1.1 loaders hab ich noch mal etwas modifiziert Im 
wesentlichen ist jetzt am Ende ein Macro drinn was bis 0x7F0 den rest 
mit 0xFF auffüllt. Das dient hauptsächlich zum binär Vergleich. 
Funktionell hat sich nichts mehr geändert.

Thomas

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Thomas Z. schrieb:
> sowie ein Tool um den IAP Mode einzuschalten

Beim Testen ist mir gestern aufgefallen dass ich den Bootloader zwar mit 
CALL starten kann, dieser aber sofort wieder beendet wird weil die IAP 
Kennung noch im Flash steht. Der Start per HW contition funktioniert 
jedoch problemlos. Man muss also in einem 2. Schritt die IAP Kennung 
wieder löschen. Schade ich hatte gehofft dass es ohne geht. Da werde ich 
ev den Bootloader noch anpassen, da ich diesen 2.Schritt einsparen 
möchte.

Thomas

von Thomas Z. (usbman)


Lesenswert?

Thomas Z. schrieb:
> Schade ich hatte gehofft dass es ohne geht. Da werde ich ev den
> Bootloader noch anpassen, da ich diesen 2.Schritt einsparen möchte.

um mir selbst zu antworten:
Das war natürlich vollkommen um die Ecke gedacht....
Es reicht schon wenn man nach dem Verify einfach die IAP Kennung mit 
0xffff,0xxffff überschreibt.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Thomas Z. schrieb:
> Thomas Z. schrieb:
>> Schade ich hatte gehofft dass es ohne geht. Da werde ich ev den
>> Bootloader noch anpassen, da ich diesen 2.Schritt einsparen möchte.
>
> um mir selbst zu antworten:
> Das war natürlich vollkommen um die Ecke gedacht....
> Es reicht schon wenn man nach dem Verify einfach die IAP Kennung mit
> 0xffff,0xxffff überschreibt.
>
> Thomas

Klingt gut den Programmer hat man ja eh gerade dran ohne geht's ja 
nicht.

Was ich mich noch immer Frage ist ob man den USB Host Mode auch beim 
ch55 2 aktivieren kann müsste mal ch 554 Chips bestellen und sehen was 
für Config Bytes geschrieben werden oder hat jemand vielleicht einen ch 
554?.

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

ich hab das Programm nochmal etwas umgestellt und lösche jetzt die IAP 
Kennung sofort nachdem das Programm ein gesetztes bBootLoad erkannt hat.
Jetzt funktioniert alles wie ich mir das vorstelle. Im Anhang das 
geänderte file.

@Aaron
Die Bits zum aktivieren des HOST modes gibts beim CH552 nicht. Es wird 
also nicht funktionieren.

Thomas

von Thomas Z. (usbman)


Lesenswert?

ich hab gestern Nacht mit den beiden Bootloadern rumgespielt. 
Insbesondere wollte ich meine Loader Extension testen, die hatte ich 
bisher nur simuliert aber noch nie auf dem Controller getestet. 
Funktioniert einwandfrei. Bei v2.31 kann man das als Ersatz für den 
fehlenden I_CALL benutzen. Ich habe mehrmals abwechselnd die Loader auf 
meinen CH552 geflashed. So weit so gut....

Dann bin ich auf die Idee gekommen das NOP an offset 0x3803 dazu zu 
verwenden die gesetztn Optionen zu codieren. Die Idee war einen 
einfachen Weg zu schaffen, die gesetzten Optionen per Softare auslesen 
zu können. Hat auch funktioniert ....

Ich habe jetzt allerdings einen Controller mit deaktiviertem HW 
Bootloader. Per Software komm ich immer noch rein. Das NOP darf also 
nicht gelöscht oder verändert werden. Ich habe damit einen zusätzlichen 
Weg gefunden die HW Aktivierung des Loaders zu deaktivieren.

Ich hätte mir das eigendlich denken können, da der Keil von sich aus 
keinen NOP an der Stelle plazieren würde. Der wurde absichtlich von WCH 
in den Startup Code plaziert.

Thomas

von Chris (Gast)


Lesenswert?

Dies klingt stark nach debugging peripherial wobei der debuggingvector
als bootloader genutzt wird. Würde bei otp Sinn ergeben da dann ein 
patching einfach möglichlççggx wäre. Dies ist bei otp besonders 
hilfreich.

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Einen kleinen Hinweis hab ich noch zum V2.31 Loader. Dort wird ja in 
main der Bootkey mit etwas seltsamen Werten initialisiert. Es ist 
einfach so, dass dazu die Keil rand () Funktionen genutzt wird.
1
char Bootkey[8];
2
...
3
for (i=0;l<8;i++) Bootkey[i] = rand ();

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Moin

diese Werte sind dann jedesmal gleich? Weil alles an der gleichen Stelle 
ist?


 hast du vielleicht den Source Code für dein changer_iap programm für 
alle ? Hatte das letztens mal ausprobiert aber nicht hundertprozentig 
verstanden was dort passiert


Habe auch ein mehr oder weniger nützliches Projekt mit dem Chip gemacht. 
Eine Propeller clock die über USB programmierbar ist ist aber eher ein 
joke project.

https://youtu.be/38hobZsm4nM minute 26:00



 viele Grüße Aaron

von Thomas Z. (usbman)


Lesenswert?

Aaron C. schrieb:
> diese Werte sind dann jedesmal gleich?

ja rand() erzeugt bei jedem Start die gleiche Folge von Zufallszahlen. 
Das machen eigentlich alle C Compiler so. Das ist auch der Grund warum 
man das einfach durch eine fixe Folge ersetzen kann.

Aaron C. schrieb:
> hast du vielleicht den Source Code für dein changer_iap programm

welchen source meinst du? Im zip sollte alles drinn sein. Lediglich 
compare.c solltest du im Projekt aktualisieren. Oder meinst du was ganz 
anderes?

Thomas

: Bearbeitet durch User
von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Achso, sorry meite die v1_tools.exe aus dem zip file.


Übrigends hatte ich auch noch die idee fals der complete flash 
beschrieben sein sollte das man dann ja theoretisch nicht die dump 
variante nutzen kann. dadurch das man aber den dataflash nach belieben 
schreiben kann kann man auch vorher einen bekanten werd reinschreiben 
und von da dumpen, auch wenn man es eigentlich eh nicht braucht weil man 
ja auch den bootloader kennt.

: Bearbeitet durch User
von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Und noch eine kleine story, es gibt den chip CH9350L von WCH der genutzt 
wird um usb geräte über eine serielle verbindung miteinander zuverbinden 
oder seriell zugänglich zu machen. 
https://lcsc.com/product-detail/USB_CH9350L_C109472.html


Dieser kahm mir verdächtig gleich dem CH559, habe vom CH9350L welche 
bestellt und konnte diesen erfolgreich in Bootlaoder modus setzen und 
mit der App auslesen, die daraus entstandene HEX datei konnte 
erfolgreich auf einen CH559 geflasht werden.

Auch konnte ich den CH9350L einfach umflashen ^^

Der Dump hat ca. 35Minuten gedauert bei einer dateigröße von ca.45Kb

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Aaron C. schrieb:
> Übrigends hatte ich auch noch die idee fals der complete flash
> beschrieben sein sollte das man dann ja theoretisch nicht die dump
> variante nutzen kann.

nun ich kann dir versichern, das es mit Versionen die ich kommerziell 
benutzen werde nichts mehr wird mit dem dumpen. Zum einen benutze ich 
eine spezielle Version des Verify cmds das im Bootloader Bereich nur 
noch Error meldet, zusätzlich ist der unbenutzte Bereich im Flash mit 
Zufallszahlen gefüllt. Der einzige Nachteil ist dass ich zwingend auf 
Chips angewiesen bin die Initial den den V1.1 loader drauf haben. Es sei 
denn ich finde doch noch einen Weg in den Original v2.31 loader zu 
schreiben.

Mir ist nicht klar wie du das mit dem Dataflash umgehen willst.

Den source der v1_tools lade ich später hoch.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Ja das war auch eher auf den originalen Bootloader bezogen, wenn man 
diesen zb. nicht mehr ändern könnte ab v2.31 währe dieser wahrscheinlich 
auch auf Chips in freier Laufbahn.


Bei einem eigenen Bootloader hat man natürlich mehr Möglichkeiten zum 
Schutz, man könnte bei einem fehlgeschlagenen verify den Chip bis zu 
einem Reboot z.b. sperren oder ähnlich.


Vielen dank aber aufjedenfall!

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Anbei die v1_tools. Da sind nicht so viele Komentare drin, das Prinzip 
sollte aber klar werden.
Zusätzlich nochmal compare.c Da hab ich die Entscheidung ob tatsächlich 
geflashed werden muss in die Flash Routine verlegt und prüfe ab ob es 
sich um einen CH551 .. CH554 handelt.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Cool vielen dank!


Habs nun auch endlich verstanden, du hattest es ja eigentlich schon 
etwas weiter oben erwähnt aber ich habe es einfach nicht gecheckt :D

von Jose S. (Firma: None) (ebclr)


Lesenswert?

Es wurde ein Test für einen Mikroe-Pascal-Compiler durchgeführt, und bei 
LED-Blinken und Serien-Comination wird bereits gearbeitet

von Thomas Z. (usbman)


Lesenswert?

Aaron C. schrieb:
> Dieser kahm mir verdächtig gleich dem CH559, habe vom CH9350L welche
> bestellt und konnte diesen erfolgreich in Bootlaoder modus setzen und
> mit der App auslesen, die daraus entstandene HEX datei konnte
> erfolgreich auf einen CH559 geflasht werden.

Ja solche Applikationsprozessoren sind üblich, allerdings wird sowas 
normalerweise besser geschützt. Ich wette mal, dass der CH340 in 
Wirklichkeit auch nur ein CH55x ist. Kannst du den Code aus dem CH9350 
hier einstellen?

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Angehängte Dateien:

Lesenswert?

@Thomas,

Ja kann mir das beim CH340 auch vorstellen, habe da auch mal in die 
richtung versucht was zu finden aber die beschreibung des EEPROM im 
CH340, das benötigte Hühnerfutter und das Pinout spricht nicht für einen 
Bekannten chip.

Lade die Binary vom CH9350 hier mal hoch auch wenn ich nicht weiß wie 
das rechtlich aussieht!



Auf Hackaday war heute ein Projekt gepostet: 
https://hackaday.com/2019/10/10/the-next-generation-arduino-nano/ dort 
wird der CH551 als ISP Programmer mit Serial converter genutzt, bin da 
auf den Code gespannt, habe den ersteller mal angeschrieben.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Danke ich wollte eigentlich nur mal ausprobieren wie gut das Erkennen 
von Keil Libs in IDA funktioniert... Funktioniert gut IDA hat auf Anhieb 
15 lib Funktionen (small) gefunden. Mal schauen ob's mehr werden wenn 
ich large wähle.
Dieses Flirt ist schon eine feine Sache.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Hatte das BIN natürlich auch mal in IDA geworfen aber nicht viel 
gemacht, da ich das was anderes schon in arbeit habe was sehr gut 
funktioniert.

kannst ja gerne, falls du das Programm etwas entschlüsselt hast, hier 
was zu posten, bin daran trotzdem sehr interessiert.

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Hier ein Bildschirmfoto was Flirt auf Anhieb gefunden hat. Zumindest 
Teile der App sind im large Mode übersetzt.

Thomas

von Max M. (max_und_moritz)


Lesenswert?

Ist es möglich den USB Suspend Status an einen der Pins auszugeben?
Z.B. über eine LED?

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

@Max, bei welcher application meinst du das?

Wenn du ein eigenes programm schreibst ist es möglich ja.

von Max M. (max_und_moritz)


Lesenswert?

@Aaron:

Der Chip wäre an einer USB Port angeschlossen der immer Strom hat. Der 
Chip würde dann dazu dienen um zu sehen wann das angeschl. Gerät 
(Notebook) an und wann aus ist (Suspend mode).
.

LG!

von Thomas Z. (usbman)


Lesenswert?

Max M. schrieb:
> Der Chip wäre an einer USB Port angeschlossen der immer Strom hat. Der
> Chip würde dann dazu dienen um zu sehen wann das angeschl. Gerät
> (Notebook) an und wann aus ist (Suspend mode).

Ja so ein Device kann man relativ einfach bauen. Es würde aber die USB 
Spec verletzen da ein USB Device was einen Suspend Befehl bekommt so gut 
wie keinen Strom mehr aufnehmen darf. Wenn ich mich richtig errinnere 
ist der zulässige Strom bei Suspend 500uA, zuwenig für eine LED.

Thomas

von Thomas Z. (usbman)


Lesenswert?

Aaron C. schrieb:
> kannst ja gerne, falls du das Programm etwas entschlüsselt hast, hier
> was zu posten, bin daran trotzdem sehr interessiert.

Ich hab mal etwas in den Code geschaut. Leider haben die Jungs bei WCH 
das Teil im large Mode übersetzt was die Sache ziemlich unübersichtlich 
macht.
Man kann aber gut die Lücke erkennen, die durch einen Bug im WCH Isptool 
verursacht wird. Speicher der im Hex undefined ist wird vom Tool mit 
0x00 initialisiert. Besser wäre 0xFF damit keine Flashzyklen 
verschwendet werden
Ab 0x8C00 beginnt das IAP Device. Man muss den Code also aufteilen in 
Normaldevice und IAP device

Die Descriptoren werden ins xram kopiert und dort je nach Mode 
gepatched.
So richtig interessant ist der Chip für mich nicht. Der tunnelt einfach 
HID Tastatur und Maus über eine serielle Schnittstelle. Auf dem Debug 
Pin werden seriell mit printf ein paar Status Daten ausgegeben

Thomas

von Thomas Z. (usbman)


Lesenswert?

Der CH559 ist leider etwas sperrig, nicht so übersichtlich wie ein 
CH552. Das liegt vermutlich daran dass das Teil auch  Hub und Host kann.
Im Ergebnis ist es so dass die gleichen SFRs unterschiedliche Namen und 
Bedeutungen bekommen wenn der Host Mode aktiviert wird. Das kann man 
auch schön im h File erkennen.

Ein Beispiel:
Im Device Mode gibt es UEP3_CTRL (sfr 0xD3) das gleiche Register heißt 
im Host Mode UH_TX_CTRL natürlich auch mit anderen bits. Ziemlich 
hässlich...
Ich habe damit begonnen mir den Code ab 0x8c00 anzusehen (IAP im Host 
Mode) weil mich der Host Mode prinzipiell interessiert. Dabei sind mir 
ein paar böse Fallen aufgefallen. Im h.file werden die DMA Buffer 
Addresse explizit nach unint16_t gecastet was bei Keil in Big Endian 
funktioniert. Wenn ich mich richtig errinnere, ist der SDCC little 
endian, dort geht das schief. Das h File braucht in jedem Fall einige 
Anpassungen für den SDC.

Zusätzlich hat WCH sehr oft long und int verwendet auch wenn das gar 
nicht notwendig ist. Der code ist dadurch ziemlich aufgeblasen.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Cool danke fürs genauer hinschauen.

Habe mir eine platine für den CH3950 angefertigt und nutze darauf einen 
CH559 mit dem code und ein Funk Uart module, dadurch hat man quasi funk 
usb wenn auch nur HID devices also etwas lächerlich. Aber genau das 
sollte es auch werden, nen video darüber folgt noch.

Ich habe den CH559 unter SDCC am laufen, werde dazu auch noch was 
veröffentlichen, aber erst später.

von Thomas Z. (usbman)


Lesenswert?

Du hast also eine Funk Tastatur/Maus gebaut... Hihi

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Korrekt. Soll eigentlich nur nen joke fürs video sein... also das war 
beabsichtigt^^


Muss aber sagen, das ganze läuft ohne lags und einwandfrei von anfang 
an.

von Thomas Z. (usbman)


Lesenswert?

Ich werde wohl am Wochenende etwas Code posten. Muss mir erst Mal noch 
ein paar Makros schreiben damit der Umgang mit den longs übersichtlicher 
wird. Das ist im Moment eine einzige mov Orgie. Da kann man nichts 
erkennen.

Thomas

von Thomas Z. (usbman)


Lesenswert?

Ein kleines Update zu diesem IAP Mode des CH559:
Der IAP Mode enumeriert als Host ein abgeschlossenes USB Device (am 
Port0).
Ich habe Hinweise gefunden dass es dabei um ein Diskdevice handeln muss.
Class=0x08 Bei WCH heißt das wohl UDISK. Allerdings finde ich dafür 
keine Descriptoren, es ist also möglich dass diese dynamisch erzeugt 
werden.
Teile des Codes entsprechen im wesentlichen dem was WCH unter usbhost.c 
in diversen Beispielen zeigt.
Wenn ich das richtig interpretiere benutzt der PC folgenden Request um 
ein Byte an den IAP Host zu senden:
0xA1 0xFE 0x00 0x00 0x00 0x00 0x01 0x00
Das ist ein Class Request mit bRequest 0xFE und einem Byte Daten. Ev ist 
das ein Verschlüsselungskey da der Request 10 mal ausgeführt wird.
Diese Daten werden jedenfalls kräftig durchgeführt. Was danach passiert 
ist mir noch nicht entgültig klar. Es sind 2 ziemlich lange Funktionen 
im Code die permanent longs schieben, addieren vergleiche, 
subtrahieren....
Zusätzlich ist mir aufgefallen dass UH_TX_CTRL bzw UH_RX_CTRL mit Werten 
beschrieben werden die nicht definierte Bits enthalten. Das halte ich 
für Fehler die aber wohl keine Rolle spielen.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Moin,

Muss zugeben das ich dir da leider nicht ganz folgen kann.

Welchen IAP mode meinst du genau?


Als info falls du es noch nicht weißt der CH559 kann ja auch UDISK im 
Host mode ansprechen, also daten vom usb stick lesen und schreiben.
Das aber nur mit einer precompilierten Library, denke aber das du das 
schon gesehen hast.


Grüße

von Thomas Z. (usbman)


Lesenswert?

Aaron C. schrieb:
> Welchen IAP mode meinst du genau?
Der Code den du aus dem CH3950 gepostet hast besteht aus 3 Teilen
HID Host Mode, HID Device Mode und eben dem IAP Mode.
Ich habe mich auf den IAP Mode konzentriert ab 0x8C00.
Der Code ist wohl dazu gedacht die FW zu aktualisieren.

Das mit precompiled Libs  ist kein Problem die kann ich konvertieren und 
dann in IDA mit Flirt laden. Dann habe ich die Funktionsnamen und auch 
Variablen drinn.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Ahhh nun wird es mir klar!.

Ich hatte den Code ja über den ganz normalen Bootloader ausgelesen.

Bis du dem IAP teil hatte ich mich nicht vorgewühlt.

Komisch das die es dann nicht einfach mit dem Normalen Bootloader 
nutzen, wo es insgesammt ja nicht so auf security gebaut ist.

von Thomas Z. (usbman)


Lesenswert?

Naja dass der Bootloader derart einfach zu hacken ist, war den Jungs bei 
WCH sicher nicht klar sonst hätten sie kaum den Aufwand mit den Bootkeys 
getrieben. Ich habe ein PDF gefunden was von IAP Security Keys spricht 
und es gibt auch spezielle Update Tools.

Thomas

von Thomas Z. (usbman)


Lesenswert?

Aaron C. schrieb:
> Das aber nur mit einer precompilierten Library,

Example 12 deckt sich weitgehend mit dem IAP Code und ist im Source 
verfügbar.
Da kann man auch gut erkennen dass die Jungs den Large Mode verwenden.

Thomas

von Thomas Z. (usbman)


Lesenswert?

Ich hab mich jetzt durch den IAP Code gewühlt und denke dass ich das 
auch soweit verstanden habe... Der Beispielcode von WCH war da eine 
große Hilfe.
Das Ding funktioniert so dass der Chip im Host Mode initialisiert wird 
und dann einfach gewartet wird bis ein MemoryStick angesteckt wird. 
Dieser wird dann enumeriert und im Rootverzeichnis nach einer Datei 
CH9350_LE.IN oder CH9350L_KM gesucht. Diese wird gelesen und geflashed 
anschließend macht das Ding einen Softreset.
Der Stick muss FAT32 formatiert sein. Die Auswertung des MBR ist 
ziemlich ineffizient gelöst die Konvertierung Von LSB zu MSB First viel 
zu umständlich. Gut die Hälfte des Codes macht nichts anderes als ein 
paar longs aus einem Diskpuffer zu lesen etwas rumzurechnen und die 
Ergebnisse zu speichern.

Ich werde heute Abend zwei Funktionen in Assembler einstellen die Long 
oder Word Variablen mit Offset aus einem Buffer lesen und die Daten dann 
MSB First zurück liefern. Damit sollte das Auswerten von MBR und FAT 
wesentlich einfacher gehen.
Benutzer des SDCC brauchen das nicht da der auch LSB first macht.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

@thomas
Schade dass die nicht dann gleich uDisk über Seriel mit einprogrammiert 
haben, aber ich denke das ist deutlich aufwendiger.

Habe heute morgen gemerkt( anhand des Schaltplanes) das bei meinem 
USB-Stick scheinbar USB Plus und USB Minus vertauscht sind. Habe bisher 
keine Probleme damit gehabt aber musst mal ausprobieren wie es sich 
verhält wenn man sie vertauscht bzw richtig polt.

Wenn ich in meinem autoladeadapter den USB-Stick eingesteckt habe und 
das Auto starte ist dieser immer in den Bootloader Modus gegangen 
vielleicht liegt es ja an der Verpolung.
Werde es heute Abend mal ausprobieren.

: Bearbeitet durch User
von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Ok, da muss ich mich selber korrigieren :D

Es ist ein fehler in dem Schaltplan, aber nicht auf dem Fertigen PCB.

Also Auf dem "USB-Stick" ist nicht plus und minus vertauscht, aber auf 
dem EasyEda Schaltplan ist wohl das Bauteil nicht ganz richtig. weiß 
nicht genau was dort schief, bzw, richtig gelaufen ist :D, scheinbar 
habe ich den USB Connector gespiegelt

https://easyeda.com/lolerino/ch552g

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Wenn du wirklich USB+ und USB- vertauscht hättest, wäre der Stick nie 
gelaufen.
Vermutlich das übliche Stecker Buchse Problem.
Das der Stick im Auto in den Loader Mode geht, liegt vermutlich daran, 
dass im Ladegerät Widerstände verbaut sind um ein Ladegerät zu melden.

Ich habe übrigens angefangen UDisk zu überarbeiten. Ich bin überzeugt 
dass man das wesentlich kürzer hinbekommt. Das Original belegt immerhin 
ohne Debug 6KByte Rom und sehr viel XRam.

Warum der Bootloader bei 0xF400 startet und nicht bei 0xF800 hab 
inzwischen auch verstanden. Das liegt ganz einfach daran, dass der CH559 
gelöscht werden muss (1k Blöcke) und da die ans Ende Config Infos 
schreiben, mussder letzte Block vorher gelöscht werden.
Es stehen für den Loader also praktisch auch nur 4k zur Verfügung die 
restlichen 2k kann man nicht nutzen.

Thomas

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

hier erst mal ein Assembler modul für Keil, was in der Lage ist longs / 
und Words in LSB first auzulesen und in MSB first zurück zu liefern.
WCH macht das folgendermasen:
1
  ...
2
  CH559vSecMBR = ((uint32_t)UDiskTmp[offset+11]<<24)
3
                |((uint32_t)UDiskTmp[offset+10]<<16)
4
                |((uint16_t)UDiskTmp[offset+9]<<8)
5
                |           UDiskTmp[offset+8];    
6
   ...
mit dem Asm Modul wird das wesentlich efektiver. Beim SDCC geht das 
ganze natürlich direkt.
1
   ...
2
   CH559vSecMBR = SwapReadLong(UDiskTmp,offset+8);
3
   ...

Thomas

von Thomas Z. (usbman)


Lesenswert?

Da mir der UDisk Code von WCH dann doch etwas zu undurchsichtig war habe 
ich die relevanten Funktionen für den PC portiert und damit einen 
MemoryStick angesprochen. Funktioniert soweit ganz gut lediglich an den 
MBR komme ich nicht ran, da ich Fehlermeldungen erhalte wenn ich den 
Stick als PhysicalDrive öffnen will.
Auf drive no Ebene kann ich Sektor für Sektor lesen und finde auch das 
File bezogen auf den Partition Start.
Soweit so gut nun zu den Problemen.
Die Flashfunktion IAP_PROM() ist m.M. nach Buggy. Die schreibt jeden 
Sektor des Fileinhalts an die gleiche Addresse. Prog_Word() ermittelt 
die Startadresse von Prog_Word() und justiert den Flashbefehl so dass 
dieser immer an einer ungeraden Adresse steht. Welchen Sinn das genau 
hat habe ich noch nicht rausgefunden.

Mehr dazu wenn ich den Code vollständig habe.

Thomas

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Hier nun der Code für den PC um lowlevel auf einen Memory stick 
zuzugreifen. Der source ist ausführlich kommentiert, die Funktion sollte 
also klar sein.
Der Code besteht aus 2 Teilen: Teil 1 dient der Simulation und emuliert 
einige Funktionen. Teil 2 enthält den Code der auch auf dem CH559 zum 
Einsatz kommt. Diser Teil enthält einige Optimierungen für 8 Bit 
Compiler. Einige dieser Stellen sind durch Kommentare gekennzeichnet. 
Auf einem PC würde man einiges wohl anders lösen.
Alle globalen Variablen enthalten keil spezifische Modifier die auf 
einem PC Compiler in nichts umdefiniert werden.
Die FAT32 spezifischen Buffer Offsets sind in fat32.h definiert

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Das ist ziemlich cool !

Finde ich gut :)

Habe es mir gerade mal grob angesehen, versucht mit mingw zu kompilieren 
aber das funktioniert nicht so richtig, werde es nochmal mit Borland 
probieren.

von Thomas Z. (usbman)


Lesenswert?

Du hast gesehen dass fat32.h in einem \inc directory liegen muss? Das 
ist Teil meiner Keil Folder Struktur.
Was für Fehler bekommst du unter mingw? Der Code sollte sich übersetzen 
lassen solange eine windows.h existiert. Das ist notwendig damit 
Createfile() und SetFilePointer() funktionieren.

Thomas

von Thomas Z. (usbman)


Lesenswert?

Noch ein Nachtrag:
Wenn man den Stick an Libusb oder WinUsb bindet kann man sehr 
wahrscheinlich alle Funktionen Low Level abbilden. Der Stick wird sich 
dann aber vermutlich nicht mehr als Memory Device am PC anmelden lassen. 
Auf diese Art der Emulation habe ich bisher bewusst verzichtet. Das 
schien mir dann doch etwas zu aufwendig zumal dann auch das 
Installationsproblem hinzukommt.

Thomas

von Audiomann (Gast)


Lesenswert?

Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller 
(Musikinstrument) anzuschließen und auszuwerten?

von Clemens L. (c_l)


Lesenswert?

Audiomann schrieb:
> Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller
> (Musikinstrument) anzuschließen und auszuwerten?

Ja, wenn du den Code dazu selbst schreibst. :)

Aber USB-MIDI ist ein sehr einfaches Protokoll: es gibt einen 
Bulk-Endpoint, über den die MIDI-Nachrichten gesendet werden, verpackt 
in 32-Bit "USB-MIDI Event Packets" (siehe Kapitel 4 der 
USB-MIDI-Spezifikation).

von Götz (Gast)


Lesenswert?

Audiomann schrieb:

> Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller
> (Musikinstrument) anzuschließen und auszuwerten?

Sich mit diesem Chips zu beschäftigen ist rausgeworfene Zeit. Hast du 
Zeit zu verplempern?

von Thomas Z. (usbman)


Lesenswert?

Audiomann schrieb:
> Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller
> (Musikinstrument) anzuschließen und auszuwerten?

Das hängt davon ab ob du ein UsbMidiDevice oder einen UsbMidiHost bauen 
willst.
Device geht auf jedem der CH5xx Controller. Host theoretisch auf dem 
CH554 der aber vermutlich zuwenig RAM und Flash hat. Da ist der CH559 
besser geeignet.
Ein Beispiel für ein UsbMidiDevice habe ich weiter oben gezeigt.

von Der Gespensterreiter (Gast)


Lesenswert?

Ehrlich gesagt kann ich nicht ganz nachvollziehen warum man sich die 
Informationsschwierigkeiten mit einem ganz fern hergestellten Produkt 
antun will. Da hat man es mit Produkten westlicher Hersteller wesentlich 
besser.
Bei uns gibt es Datenblätter, App. Notes und Debug/Programmier Tools in 
Hülle und Fülle. Auch besteht oft eine nützliche große User Community. 
Hat das wirklich sinn, oder ist das ähnlich wie "Ich habe Mt. Everest 
erstmal bestiegen" wo halt der Weg das eigentliche Ziel und Spass an der 
Freude die Hauptmotivation ist? Irgendwie will mir der Sinn des Ganzen 
nicht ganz in den Kopf.

von Harald (Gast)


Lesenswert?

Der Gespensterreiter schrieb:
> Irgendwie will mir der Sinn des Ganzen
> nicht ganz in den Kopf.

Das wurde ganz oben im Thread schon ausgiebig diskutiert. Im Grunde hast 
Du Dir die Antwort aber schon selber gegeben.

von Thomas Z. (usbman)


Lesenswert?

Ein kleines Update zu UDisk Emulation:
Ich habe heute einen alten 1GB Stick, den ich sowieso nicht mehr 
benutze, genommen und mal probehalber mit zadig an libusb gebunden. Wie 
erwartet taucht der Stick dann nicht mehr als Laufwerk auf und ich 
konnte LL die ersten Kommandos absetzen. Auf diese Weise kann man den 
kompletten Host Mode abbilden und die Firmware auf dem PC emulieren. Mal 
schauen was daraus wird.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

@thomas.

Ja die .h datei habe ich im code geändert aber trotzdem wollte es nicht.

Eine richtige fehlermeldung gibt es leider nicht.

GCC gibt 2 minuten lang den inhalt diverser dateien aus. Weiß noch nicht 
richtig was da schief läuft

von Thomas Z. (usbman)


Lesenswert?

Aaron C. schrieb:
> GCC gibt 2 minuten lang den inhalt diverser dateien aus. Weiß noch nicht
> richtig was da schief läuft

Das kann eigendlich nur eine Ursache haben:
CreateFile() oder SetFilePointer() macht bei dir was falsch.  Bau ans 
Ende von UDisk_ReadOneSector() mal ein Exit() ein. Und gibt ein paar 
zusätzliche Statusmeldungen aus. Den Code hab ich StackOverflow geklaut.
Dann sollte schnell Klarwerden was da nicht so richtig will.
Alternativ kannst du die Ausgaben auch in ein Log umleiten und dann die 
ersten Zeilen genauer betrachten.

Thomas

: Bearbeitet durch User
von Audiomann (Gast)


Lesenswert?

Götz schrieb:
> Sich mit diesem Chips zu beschäftigen ist rausgeworfene Zeit. Hast du
> Zeit zu verplempern?
Ganz sicher nicht, daher hatte ich ja die USB-Fachmänner kurz befragt, 
ob sich ein Befassen mit diesem Chip lohnen könnte.

Thomas Z. schrieb:
> Audiomann schrieb:
>> Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller
>> (Musikinstrument) anzuschließen und auszuwerten?
> Das hängt davon ab ob du ein UsbMidiDevice oder einen UsbMidiHost bauen
> willst.
Wenn schon, dann host! Der Chip muss den Musik-Controller ja erkennen 
und bedienen, also anfragen, Daten holen und zwischenspeichern und gfs 
auch welche senden. Einige haben LEDs, welche Zustände zeigen.

Der Gespensterreiter schrieb:
> Da hat man es mit Produkten westlicher Hersteller wesentlich
> besser.
Beispiel?

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

@thomas

Hatte auch an die ersten zeilen geschaut aber selbst da war keine 
fehlermeldung.

Nun wollte ich davon ein screenshot erstellen und siehe da, es 
compilliert ohne probleme. und auch das programm läuft, nun muss ich mir 
auch einen usb stick raussuchen.
Witziger weise habe ich nähmlich genau vor einer woche damit angefangen 
auf dem pc gcc zu testen und dann kommst du :D


@Audiomann

Ein Midi Host ist machbar mit dem CH559 (wohl auch CH554, wie thomas 
aber schon sagte etwas wenig ram und der Preisunterschied ist nicht 
groß)

Und der Einwand von Götz ist komisch, man hat wenn man bei einem Bare 
Chip anfängt die gleiche arbeit vor sich ob nun dieser oder ein anderer 
USB host Chip, wenn man eine Komplett Lösung kauft ist es natürlich was 
anderes.

von Thomas Z. (usbman)


Lesenswert?

@Aaron freut mich dass es jetzt bei dir tut.
Ich bekomme mittlerweile meinen Stick mit libusb genauso enumeriert wie 
das UDisk macht. Die MaxLun Geschichte geht auch schon, ich verstehe 
allerdings nicht warum WCH das Kommando 10 mal absetzt. Heute habe  ich 
das BulkOnly Cmdset implementiert das hat aber noch Fehler.

@audioman
Lad mal diese zip von WCH da ist auch was für Midi dabei.
http://wch.**/download/CH559EVT_ZIP.html  und
http://www.wch.**/public/uploads/file/20180207/1517992523119473.rar

**durch cn ersetzen

Thomas

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Eine neue Version der UDisk Emulation dieses mal für libusb

Thomas

von Thomas Z. (usbman)


Lesenswert?

Ich habe jetzt die IAP Firmware von WCH basierend auf den 
Simulationsergebnissen in 5 Files aufgeteilt. Dies vor allem vor dem 
Hintergrund dass ich daraus auch eine Lib bauen will und Host Code vom 
UDisk Code trennen will. Damit sollte es dann möglich werden mit wenigen 
Änderungen auch etwas andere als einen Stick zu enumerieren. Speziell 
wenn man eine Lib bauen will ist es sinnvoll Funktionen in seperaten 
Files zu legen, damit später der Linker nicht unbenutzte Funktionen zum 
Programm linkt.
Jede einzelne Funktion in ein separates File zu legen ist dann aber 
etwas zuviel des guten.
Das klappt schon ganz gut der Code belegt im Moment um die 4Kbyte. 
Variablen passen gerade so ins data Segment. Das idata Segment ist noch 
komplett frei. Im xdata sind 2x64 Byte für USB und 512 Byte für den 
Sectorbuffer belegt.

Wenn es bei den 4k bleibt kann also das zu flashende File max 56kbyte 
haben.

Es würde sich folgende Memory Map ergeben:
0x0000 .. 0xDFFF Anwender Code
0xE000 .. 0xF3FF UDisk/IAP
0xF400 .. 0xFFFF  Bootloader

Thomas

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

folgender Code (Keil C51)
1
uint8_t IAP_ProgWord(uint16_t Addr,uint16_t Data)  
2
{                                                  
3
   ROM_ADDR = Addr;                                
4
   ROM_DATA = Data;                                
5
   if (ROM_STATUS & bROM_ADDR_OK)                  
6
   {                                               
7
      if ((uint8_t) &IAP_ProgWord & 0x01)          
8
      {                                            
9
         ROM_CTRL = ROM_CMD_PROG;                  
10
         _nop_();                                  
11
      }                                            
12
      else                                         
13
      {                                            
14
         _nop_();                                  
15
         ROM_CTRL = ROM_CMD_PROG;                  
16
      }                                            
17
      return((ROM_STATUS ^ bROM_ADDR_OK) & 0x7F);  
18
   }                                               
19
   else return(bROM_ADDR_OK);                      
20
}

was der Code macht ist soweit klar. Er sorgt dafür, dass
ROM_CTRL = ROM_CMD_PROG; immer an einer ungeraden Addresse steht auch 
wenn die Funktion durch den Linker auf eine ungerade Addresse plaziert 
wird. Das kann man sehr gut im lst file sehen. Im Original von WCH gibts 
an der Stelle natürlich auch keinen Kommentar(auch keinen chinesischen).

Meine Frage ist jetzt eher: Wie kommt man auf die Idee sowas zu 
programmieren? Kann sich jemand einen Grund vorstellen warum das Komando 
an einer ungeraden Addresse stehen muss?
Bei allem was ich über den Chip weiss, könnte ich mir eher vorstellen 
dass es eine gerade Addresse sein muss. Dann wäre die Logik aber genau 
falsch rum.
Ich habe natürlich bei WCH auch angefragt aber keine sinnvolle Antwort 
erhalten.
Meiner Meinung nach ist es kompletter Mist sowas zu programmieren. Ohne 
Blick ins Assembler File kann man nicht sagen wie das übersetzt wird und 
bei der kleinsten Anderung der Funktion muss man wieder neu nachschauen.
Ich habe keine Option gefunden dem Linker mitzuteilen eine Funktion an 
eine gerade Addresse zu linken.

Kann sich jemand einen Reim daruf machen?

Thomas

von Frank Gießner (Gast)


Lesenswert?

An  Aaron C.,

bin sptiz drauf die Teile auch mal zu testen.
Jetzt meine Frage: musstest du um die dinger anzuholen zum Zoll?

Hätte keine wirklcihe lust da meinen Tag zu verschwenden.
Es dauert immer ewig und ist echt nervtötend.
Man wartet ne halbe ewigkeit und dann nervt der Zoll wegen irgendetwas 
rum.

Grüße
Frank

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Frank Gießner schrieb:
> Jetzt meine Frage: musstest du um die dinger anzuholen zum Zoll?



Moin, ich habe sie bei lcsc per express bestellt, vor nem jahr oder so 
gab es mal eine änderung bei DHL das die dass für dich verzollen, wenn 
rechnungsbetrag größer 22€.

Dieser servie kostet 12€ + mwst.

Mit LCSC hatte ich noch keinerlei problem mit zoll und vorgeladen 
werden.



Wenn du nur ein paar bestellt bist du ja eh unter der zollgrenze und 
raus.

Wenn du aber willst kann ich dir für einen obulus welche per brief 
senden, habe noch ca. 370 Stück der CH552G Bootloader Version 1.1



@Thomas, bist du eigentlich auch mal Thomas(Gast) gewesen? oder irre ich 
mich da? etwas verwirrent :D


Es wurde die Tage das M5Stack II und der M5StickC mit CH552T als USB to 
Seriall converter ausgemacht.

https://m5stack.com/products/stick-c

auf beiden Läuft dieser code: https://github.com/diodep/ch55x_esp

von Thomas Z. (usbman)


Lesenswert?

Nö du irrst dich nicht, ich war lange Zeit auf mc net nur als Gast 
unterwegs. Es gibt zwar auch noch andere Thomas Gäste aber in diesem 
Thread ist das nur von mir.

Seit etwa einem halben Jahr poste ich fast nur noch von meinem Tablet 
und deshalb auch angemeldet.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Ok danke, wollte nur komische Situationen vermeiden :D

von Frank Gießner (Gast)


Lesenswert?

Aaron C. schrieb:
> Wenn du nur ein paar bestellt bist du ja eh unter der zollgrenze und
> raus.
>
> Wenn du aber willst kann ich dir für einen obulus welche per brief
> senden, habe noch ca. 370 Stück der CH552G Bootloader Version 1.1

Hallo,

danke für die schnelle Antwort!
Wollte aber noch etwas anderen krimms kramms von der Seite kaufen.
Also besten dank für das Angebot!
Ich denke ich versuchs einmal mit ner Bestellung dort.

Hab die erfahrung gemacht das zumindest hier in Bayern alles was als 
Päckchen aus dem Ausland ankommt - das man dann zum Zoll muss.

Musste schon mal wegen einem 5 Euro (5,99 Versand) Teil zum Zoll nur 
weil es als Paket verschickt wurde mit "echter" Seundungsnummer.

Haßt du auch erfahrung mit anderen MCs von der Seite?

Grüße
Frank

von Thomas Z. (usbman)


Lesenswert?

Hab ich gerade gefunden. Da übersetzt wohl jemand das Datenblatt zum 
CH559. Die Qualität scheint gut zu sein, es sind aber erst die ersten 7 
Kapitel online.
https://github.com/kprasadvnsi/CH559_Doc_English

Thomas

von Frank Gießner (Gast)


Lesenswert?

Hallo Thomas,

cool, aber ich Frag mich sowieso wieso die Datenblätter nur auf 
Chinesisch und nicht auf Englisch erhältlich sind.
So als ob die Chinesen die diesen Chip entwickelten kein Englisch 
können.
Was ich ja überhaupst nicht glaube.

Grüße
Frank

von Andreas R. (daybyter)


Lesenswert?

Du bist halt nicht die Zielgruppe. Das sind asiatische Firmen, die so 
Sachen für 2$ entwickeln wollen.

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Hier nun meine Interpretation der UDisk sourcen von WCH. Das ganze ist 
noch nicht perfekt und für Keil only.
Im zip befinden sich insgesamt 3 Projekte:

- disk_iap was die Integration der Lib zeigt und nach 0xE000 linkt.
- disk_test was alle Module include und nach 0x0000 linkt
- udisklib zum compilieren der Lib.

Im udisk_test ist ein globales define TESTCODE gesetzt was an alle 
Module weiter geleitet wird. Damit wird printf gesteuert und in IAP das 
flashen gesperrt.
disk_Iap benutzt modifizierten startupcode und der Linker platziert den 
Code ab 0xE000 Es sind noch etwa 400 Bytes unbelegt.

Thomas

: Bearbeitet durch User
von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Mein Testboard ist angekommen und ich hab gleich mal bestückt. 0.5mm 
Pitch ist nichts mehr für meine Augen.
Einen Fehler hab ich auch gleich gefunden:
Entgegen dem Datenblatt ist Der RST Anschluss high (ohne Pulldown) 
zumindest solange keine FW auf dem Chip ist ist also P5.7 kein frei 
benutzbarer Portpin sondern mit RST belegt. Der fehlende Pulldown 
verhindert zuverlässig das Anlaufen des Bootloaders. Abhilfe 10k gegen 
Gnd.  Leider hab ich auch S2 an dem Port Pin hängen den kann man also 
nicht benutzen.

Wenn das Ding getestet ist werde ich Eagle Files einstellen

Thomas

von Thomas Z. (usbman)


Lesenswert?

ich hab mich mal etwas mit der Seriennummer des CH559 beschäftigt. Der 
Zugriff auf diese Nummer ist etwas seltsam. Man muss E_DIS = 1 setzen 
und dann 8 bytes mit MOVC ab 0x020 lesen. Das ist zumindest der von WCH 
dokumentierte Weg. Tatsachlich ist aber so, dass die SN über den 
gesammten Flashrombreich gelesen werden kann. Sie wiederholt sich alle 
256 Bytes. Es sind zusätzlich auch noch ein paar undokumentierte  Bytes 
definiert.
1
c:0000 FF FF FF FF 0A FA 93 FF FF FF FF FF FF FF FF FF
2
c:0010 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF
3
c:0020 05 5A A3 54 00 00 A8 AE FF FF FF FF FF FF FF FF
4
c:0030 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF
5
c:0040 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF
6
...
7
c:0100 FF FF FF FF 0A FA 93 FF FF FF FF FF FF FF FF FF
8
c:0110 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF
9
c:0120 05 5A A3 54 00 00 A8 AE FF FF FF FF FF FF FF FF
10
c:0130 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF
11
c:0140 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF
12
...
13
...

Man kann z.B auch sehen das zumindest bei mir nur 32Bit der SN definiert 
sind und nicht 48 Bit wie im Datenblatt beschrieben. Das ist vermutlich 
auch der Grund warum WCH schreibt man soll nur die ersten 32bit 
benutzen.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Mit Bitluni von Bitlunislab ist nun das folgende projekt rausgekommen.

Mittels des CH559 ist ein uart interface entstanden an dem diverse 
andere controller angeschlossen werden können, im beuspiel ein esp32 und 
Arduino.

Auch ist eine verarbeitung auf dem CH559 möglich dazu kann man den 
source code nach seinen bedürfnissen ändern.

https://youtu.be/Th88RiSmj2w

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Ich hab den Bootloader des CH559 jetzt an die anderen Loader 
angeglichen. Wieder lassen sich verschiedene Optionen ein und 
ausschalten.
Der Code ist ausführlich kommentiert. Ohne Optionen entspricht der Code 
dem Original sofern die Startaddresse auf 0xF400 steht.
Dieser Loader ist geeignet für CH558/CH559.
Es gibt in main eine Abfrage auf ID 0x57 keine Ahnung was für ein CHip 
das ist. Ich hab bei WCH jedenfalls keinen CH557 gefunden.

Das Header File ist gleich geblieben und weiter oben zu finden.

Thomas

von Max M. (maxmicr)


Lesenswert?

Ich find das ganz spannend was ihr hier macht.
Bin nach dem heutigen Video von bitluni auf diesen Thread gestoßen.

Ich hab ehrlich gesagt nur die Hälfte alle Beiträge gelesen da es 
inzwischen echt viele sind. Trotzdem würde ich gerne 3 Fragen stellen:

1. Welchen Vorteil hat euer eigene Bootloader? Benötigt er weniger 
Flash-Speicher? Funktioniert er ohne das WCHISP-Tool?

2. Kann man sich den USB-Bootloader sparen und so den freigewordenen 
Flash nutzen indem man die CH55x stattdessen mit einem "echten 
Programmiergerät" programmiert? Gibt es Informationen dazu, wie das 
funktioniert? Hat es schon jemand getestet?

3. Was ist der Unterschied zwischen XRAM und iRAM?

Grüße

von Thomas Z. (usbman)


Lesenswert?

Ich antworte mal:

Der Bootloader hat mmer noch die Original Funktionalität. Er wurde nur 
optimiert um Platz für zusätzliche (andere) Funktionen zu schaffen. Das 
WCHIsptool war schon immer nur eine von mehreren Möglichkeiten. So hat 
Aaron zB. einen Flasher für Android geschrieben. Da die API unverändert 
ist, kann man auch Erweiterungen realisieren. So habe ich zB ein Tool 
geschrieben was auch ab einer Startadresse<>0 flashen kann.

Ja man könnte den Controller extern per SPI flashen. Das geht aber nur 
in der Theorie. WCH hat das SPI Verfahren nicht offengelegt. Praktisch 
existiert diese Möglichkeit also nicht.

XMEM und IMEM sind Begriffe aus der x51 Welt. Etwas vereinfacht: IMEM 
ist der interne Controller  Speicher (max 256 Bytes).XMEM ist externer 
Speicher. Beide Speicher existieren parallel, da sie unterschiedlich 
angesprochen werden.

Thomas

: Bearbeitet durch User
von Max M. (maxmicr)


Lesenswert?

Vielen Dank für deine Antwort Thomas!

Thomas Z. schrieb:
> XMEM und IMEM sind Begriffe aus der x51 Welt. Etwas vereinfacht: IMEM
> ist der interne Controller  Speicher (max 256 Bytes).XMEM ist externer
> Speicher. Beide Speicher existieren parallel, da sie unterschiedlich
> angesprochen werden.

Macht das einen Unterschied für den C-Entwickler? Oder handelt das der 
Compiler und man hat dann insgesamt 1.25kByte?

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Max M. schrieb:
> Vielen Dank für deine Antwort Thomas!
>
> Thomas Z. schrieb:
>> XMEM und IMEM sind Begriffe aus der x51 Welt. Etwas vereinfacht: IMEM
>> ist der interne Controller  Speicher (max 256 Bytes).XMEM ist externer
>> Speicher. Beide Speicher existieren parallel, da sie unterschiedlich
>> angesprochen werden.
>
> Macht das einen Unterschied für den C-Entwickler? Oder handelt das der
> Compiler und man hat dann insgesamt 1.25kByte?

Man muss schon beim Programmieren angeben welche Daten man in welchen 
RAM haben möchte.

Man hat am Ende aber trotzdem 1,25kByte.

Soweit ich das verstanden habe wird alles was nicht extra benannt wird 
in den internen RAM gespeichert und dort wo man __xdata mit angebt wird 
es im externen RAM gespeichert. So ist es zumindest bei SDCC

von Thomas Z. (usbman)


Lesenswert?

Max M. schrieb:
> Macht das einen Unterschied für den C-Entwickler? Oder handelt das der
> Compiler und man hat dann insgesamt 1.25kByte?

Der C Compiler kennt erst mal nur den internen Speicher. Dieser ist noch 
weiter aufesplittet. Es gibt da noch mehr Segmente. In diesem Speicher 
liegt der Stack und die Variablen. Wenn man im Large Mode übersetzt 
platziert der Linker die Variablen im XMEM. Das ist aber wesentlich 
langsamer. Zusätzlich kann jeder Var per modifierer auch die Platzierung 
mitgegeben werden. Das funktioniert unabhängig vom Memory Model. Bedenke 
der core stammt aus den 80er Jahren. Damals hat man sich noch nicht so 
viele Gedanken um C gemacht.
Wenn du also keine Erfahrung mit einem 8051 hast würde ich dir nicht 
empfehlen jetzt noch damit anzufangen. Die cores sind zwar immer noch 
weit verbreitet, heutzutage gibt es aber wesentlich bessere Designs.
Eine der Stärken würde ich beim x51 im boolean Prozessor sehen. Es gibt 
Befehle um direkt mit bits zu arbeiten. Das bietet in dieser Form m. 
Wissens keine andere MCU.

Thomas

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Anbei die Eagle Files meines CH559 Breakout Boards. Das Design ist 
generell auf .2mm Abstand geroutet. Es gibt aber einige Engstellen wo 
der DRC nur mit .15mm durchläuft. USB Buchse und Taster gibt's bei 
Reichelt. Die Platine hab ich bei Aisler machen lassen. Das 
funktionierte in 2 Tagen völlig problemlos. Das nächste Mal würde ich 
allerdings ENIC wählen und lieber 7 Tage warten.

Die gezeigte Version hat schon die korrigierte Resetbeschaltung beim 
Flashen muss man darauf achten, dass D+ als Bootpin eingestellt ist weil 
ich an P4.6 keinen Taster dran habe. Falls man das nicht umstellt muss 
man hinterher seriell flashen

Thomas

von Gerne auch (Gast)


Lesenswert?

Aaron C. schrieb:
> Mit Bitluni von Bitlunislab ist nun das folgende projekt rausgekommen.
> ...
> Youtube-Video "Usb mouse and keyboard on Arduino, CH559 cheap usb host
> chip"
Danke für das Video. Woher und zu welchem Preis hast du die Controller 
im Tray bezogen? Ich kann nur einen einzigen Anbieter bei Ali finden, 
nirgendwo sonst.

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?


von Gerne auch (Gast)


Lesenswert?

Prima, vielen Dank!

von Gerne auch (Gast)


Lesenswert?

Das Ganze erinnert mich übrigens an die Hacks der digitalen Bilderrahmen 
mit dem "AppoTech AX206" mit ähnlicher Ausstattung.
http://openschemes.com/wp-content/uploads/2011/08/X206spec.pdf
Es sind auch schon einige Threads hier im Forum. Vielleicht kann man 
auch was von den Codes in den diversen Repos wiederverwenden oder wenn 
es auch nur die Idee eines externen Displays für irgendeine headless 
black box ist.

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Habe mich die tage nochmal hingesetzt und ein flashing script in Python 
für die CH55x Familie geschrieben.

https://youtu.be/uhSHcyjUaic

Dieses kann Bootlaoder version 1.11 und 2.31


Da beim entwickeln immer zwischen VirsualStudio und dem WCHISPTOOL 
gewechselt werden musste ist es mit dem tool nun eine ein click lösung, 
also compile.bat aus dem ch559 code ausführen der code wird compiliert 
und gleich auf den CH micros geflasht.

von Max M. (maxmicr)


Lesenswert?

Sehr cool!

Eine Frage von mir:

Lustigerweise kostet der CH552 genauso viel wie der CH340G, der oft als 
USB/UART-Bridge verwendet wird.

Kann man den CH552 so programmieren, dass er auch als USB/UART-Bridge 
fungiert und damit z.B. einen ESP8266 flashen? Dan hat man quasi immer 
einen kleinen uC mit an Board, USB<->UART braucht man beim ESP ja 
sowieso.

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Max M. schrieb:
> Kann man den CH552 so programmieren, dass er auch als USB/UART-Bridge
> fungiert und damit z.B. einen ESP8266 flashen? Dan hat man quasi immer
> einen kleinen uC mit an Board, USB<->UART braucht man beim ESP ja
> sowieso.


Moin, ja das funktioniert genau so.

es wird auch schon bei dem M5Stack in massenproduktion eingesetzt.

Eine opensource firmware gibt es hier:

https://github.com/diodep/ch55x_esp

: Bearbeitet durch User
von Max M. (maxmicr)


Lesenswert?

Vielen Dank für die schnelle Antwort!

Sehr schön, dass es da schon was fertiges gibt.

So ganz verständlich ist der Code allerdings meiner Meinung nach nicht 
(vor allem die Funktion "Device-Interrupt"). Ist auch mehr Code als ich 
ursprünglich dachte. Scheint also doch mehr Arbeit gewesen zu sein, das 
zu reverse engineeren.

: Bearbeitet durch User
von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Ja es ist wirklich schwer leserlich, der code ist aber auch sehr 
unordentlich und vom original WCH example nur verändert.

Ich habe mich da langsam rangetastet und stückchenweise den code 
angepasst, also nicht diesesn speziellen code sonder grundsätzlich.


Was ich gerade für die ESPs interessant finde ist die "integrierte" 
Reset und GPIO0(bootloader) funktion die ein paar teile einsparen kann 
wenn man das implementiert.

Auch gibt es dieses projekt:
https://hackaday.io/project/167339-a-new-nano

Dort wurde eine ISP Programmer für AVR micros auf dem CH552 Gebastelt, 
inklusive USB zu Seriell Converter, der Code vom dem Projekt ist 
deutlich aufgeräumter da von null selber geschrieben.

von Max M. (maxmicr)


Lesenswert?

Aaron C. schrieb:
> Ich habe mich da langsam rangetastet und stückchenweise den code
> angepasst, also nicht diesesn speziellen code sonder grundsätzlich.

Ich denke, dass ist die beste Vorgehensweise. Bringt ja nix, wenn ich 
meine Features einbauen möchte, aber den restlichen Code nicht verstehe.
Macht Sinn, den IC von Grund auf verstehen zu wollen.

Aaron C. schrieb:
> Was ich gerade für die ESPs interessant finde ist die "integrierte"
> Reset und GPIO0(bootloader) funktion die ein paar teile einsparen kann
> wenn man das implementiert.

Das stimmt, soweit ich weiß wurde das auf den Wemos D1 Mini mit zwei 
Transistoren gelöst. Findet man via Google "Wemos Reset Circuit".

Edit: Etwas Off-Topic, aber vielleicht interessant für die 
USB-Begeisterten:
Von Nordic Semi gibt es einen IC, der einen 8051 uC (16MHz, 16kByte 
Flash 2kByte SRAM) mit einem USB-Device Controller und einem 2.4GHz RF 
Transceiver Modul (weder WLAN noch Bluetooth) vereint: 
https://www.rcscomponents.kiev.ua/datasheets/nrf24lu1-f16q32-t.pdf

Programmiert werden kann der laut Datenblatt auch über einen 
vorprogrammierten USB-Bootloader (der ist futsch sobald das User-Program 
in den Bootloader-Adressbereich hineinwächst). Ansonsten wird ein 
PROGEN-Pin high gezogen und über ein Slave-SPI der interne Flash 
programmiert.

Damit kann man z.B. sowas lustiges machen: 
https://www.bartslinger.com/electronics/nrf24lu1-usb-dongle/

Die Keil µVision IDE kennt den Chip bereits und bietet dafür eine 
Header-Datei an. Kostet auf Taobao 0.50€ / Stück. Gibts leider nur im 
QFN32-Package mit maximal 6 nutzbaren GPIOs.

: Bearbeitet durch User
von Richard K. (richi123)


Lesenswert?

Aaron C. (atc1441) hat mir ein paar CH55x zukommen lassen und ich habe 
mal einen Blick auf die Dies des CH551 und des CH552 geworfen:

https://richis-lab.de/CH55x.htm

Es scheint sich um die gleichen Dies zu handeln. Wahrscheinlich werden 
beim CH551 schlicht gewisse Funktionen deaktiviert.

Mal sehen was in den anderen Varianten noch steckt.

Grüße,

Richard

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Vielen vielen dank!!!

von Richard K. (richi123)


Lesenswert?

Aaron C. schrieb:
> Vielen vielen dank!!!

Gerne! :)

von Andreas B. (andreasb)


Lesenswert?

Danke!

Richard K. schrieb:
> Es scheint sich um die gleichen Dies zu handeln. Wahrscheinlich werden
> beim CH551 schlicht gewisse Funktionen deaktiviert.

Jetzt stellt sich die Frage: Sind diese Funktionen deaktiviert, und 
können theoretisch aktiviert werden, oder sind da Teile der Chips 
Produktionsbedingt bereits kaputt, und werden deaktiviert?

Ich meine die Preise sind extrem tief, da könnte es doch auch sein, dass 
da die Fertigungsqualität schlechter ist. Da wird getestet, und wenn 
etwas nicht geht, wird alles deaktiviert, und als CH551 verkauft?

von Richard K. (richi123)


Lesenswert?

Andreas B. schrieb:
> Danke!
>
> Richard K. schrieb:
>> Es scheint sich um die gleichen Dies zu handeln. Wahrscheinlich werden
>> beim CH551 schlicht gewisse Funktionen deaktiviert.
>
> Jetzt stellt sich die Frage: Sind diese Funktionen deaktiviert, und
> können theoretisch aktiviert werden, oder sind da Teile der Chips
> Produktionsbedingt bereits kaputt, und werden deaktiviert?
>
> Ich meine die Preise sind extrem tief, da könnte es doch auch sein, dass
> da die Fertigungsqualität schlechter ist. Da wird getestet, und wenn
> etwas nicht geht, wird alles deaktiviert, und als CH551 verkauft?

Das ist die Frage...

Ich vermute, dass die Prozesse mittlerweile so gut sind, dass bei so 
relativ kleinen Controllern der Ausschuss sehr gering ist und 
entsprechend schlicht verworfen wird. Hat man Ausschuss, so müsste man 
da ja erst mal testen was genau kaputt ist und ob sich das Die noch als 
CH551 eignet. Das wird sich nicht rentieren.

Dann bleibt noch die Frage ob die Funktionen über HW oder SW deaktiviert 
wurden. Bei gröberen Strukturen hat man oftmals Fusible Links verwendet. 
Bei einem Mikrocontroller würde ich eher vermuten, dass es SW-Fuses, 
also Speicherzellen sind, die konfiguriert werden. Ob man an diese 
Speicherzellen noch einmal ran kommt und wie man da hin kommt müssen die 
SW-Cracks herausfinden... :) ...hilfreich wäre es wahrscheinlich die 
Metalllagen zu entfernen und das ganze Die zu analysieren. Das 
übersteigt aber meine Fähigkeiten...

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Ich denke es währe vor allem die frage ob der CH554 auch das gleiche DIE 
hat, die funktionen von CH551 und CH552 unterscheiden sich ja nur 
minimal, beim CH554 kommt ja noch USB Host hinzu.


Ich denke nur dann lohnt es sich dahinter zu schauen.



P.s. Richard, du hast ein paar mal im text auf deiner website die 
Zahlen vertauscht wollte es nur einmal erwähnt haben

von Richard K. (richi123)


Lesenswert?

Der CH554 ist schon durch den Ofen gegangen. Fotos muss ich noch machen. 
:)

Danke für den Hinweis zu den Schreibfehlern. Zweimal "511", richtig? 
Habe ich korrigiert.

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Ich hab mal wieder etwas programmiert... rausgekommen ist ein kleines 
Konverter Tool um Intel Hex Dateien zu konvertieren. Das besondere ist, 
dass der Speicher mit Zufallsdaten initialisiert werden kann. Das Tool 
kennt alle WCH CPUs und erzeugt per Default ein Abbild des kompletten 
Userflashs. Das ist insbesondere dann hilfreich wenn ein modifizierter 
Bootloader mit abgeschaltetem Verify im Loaderbereich verwendet wird.

Damit ist ein zurücklesen der Daten unmöglich
Vorbereitet aber noch nicht implementiert ist das encrypting des 
Files(speziel für uDisk) sowie das automatische flashen.

Die Größe der Ausgabedateien kann optional auch limitiert werden.

Beispiel:
wch_tools -iBlablub.hex -f+ -c0x52 -l0x2000
erzeugt firmware.hex und firmware.bin mit limitiert auf 8kB.
Wenn euch noch was ein oder auffällt schreibt einfach.

Thomas

von Richard K. (richi123)


Lesenswert?

Guten Morgen!

Jetzt habe ich auch den CH554 und den CH559 online:

https://www.richis-lab.de/CH55x.htm

Der CH554 mit seiner USB-Host-Funktionalität nutzt tatsächlich das 
gleiche Die wie der CH551 und der CH552. Das bedeutet, dass 
höchstwahrscheinlich auch die USB-Host-Funktion bei allen Varianten 
grundsätzlich vorhanden ist.

Der CH559 ist gänzlich anders aufgebaut.

Grüße,

Richard

von Thomas Z. (usbman)


Lesenswert?

Richard K. schrieb:
> Jetzt habe ich auch den CH554 und den CH559 online:

Die Bilder sind echt cool danke dafür.
Bezüglich der Konfiguration:
Es gibt ein Byte im Config Bereich was nicht dokumentiert ist, es ist 
das Byte an der Addresse 0x3FFA. Das ist bei mir (CH552) immer 0x65 und 
gehört nicht zur Seriennummer. Lt Doku kann der Bereich nur per SPI 
programmer beschrieben werden was ich persönlich nicht glaube. Es wäre 
interessant was dort bei einem CH551 oder beim CH554 steht.

Thomas

von Richard K. (richi123)


Lesenswert?

Thomas Z. schrieb:
> Richard K. schrieb:
>> Jetzt habe ich auch den CH554 und den CH559 online:
>
> Die Bilder sind echt cool danke dafür.

Gerne!
Wenn ihr noch was in die Richtung braucht, dann sagt Bescheid!
Von den Software-Themen halte ich lieber Abstand... :)

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

@Richi

Vielen dank nochmals, finde deinen röhren ofen übrigends sehr 
interessant.

von Richard K. (richi123)


Lesenswert?

Aaron C. schrieb:
> @Richi
>
> Vielen dank nochmals, finde deinen röhren ofen übrigends sehr
> interessant.

Der Ofen ist sehr hilfreich. Zwar sind die Dies überraschend robust 
gegenüber Hitze, aber mit einem Gasbrenner kann man sie dann doch 
beschädigen. Gleichzeitig brauchen aber vor allem große Packages eine 
ordentliche Wärmemenge und alle gängigen Produkte wie zum Beispiel 
Pizza- oder Reflowöfen sind zu kalt. Ein richtiger Muffelofen war mir zu 
teuer. So kam ich auf den Eigenbau.
Damit ist der Vorgang jetzt auch einigermaßen reproduzierbar. 400°C (am 
Sensor), 1min und die kleinen SMD-Packages sind durch. :)
Und bei problematischen Fällen (anhaftende Reste) einfach das Die noch 
einmal ein bisschen braten, evtl. 50°C mehr und es gibt meist immernoch 
keine Schäden. (Ausnahmen bestätigen die Regel...)

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Ein kleines Update:
zusätzlich zu einigen Bugfixes ist jetzt die Verschlüsselung mit TEA 
oder XTEA möglich. Beide Funktionen sind einfach genug um auch auf einem 
x51 annehmbare Resultate zu liefern. Bei der Verschlüsselung hat man die 
Wahl zwischen strong und fast. Strong braucht aber auch die 8 fache Zeit 
was auf einem x51 schon eine Rolle spielt. Man kann aber auch gut 
erkennen, dass die fast Option viel schlechter verschlüsselt, speziell 
wenn viele gleiche Bytes kommen.

Außerdem können nun bis zu 4 Intel Hex Files, durch Komma getrennt, 
geladen werden (merge) und die Extension kann auch weggelassen werden.
Im Archiv ist jetzt auch der Sourcecode enthalten.

Thomas

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Ich habe gestern mal Versuche zur Entschlüsselung gemacht. Mit XTEA 
strong komme ich auf ca 500 ms pro 512 Byte Block. Den Core Clock 
schalte ich zum dekotieren auf 48 MHz. Das ist ok für mich. Zusätzlich 
habe ich in UDisk-Mini eine Erkennung eingebaut ob die Firmware 
verschlüsselt ist.
Mein Ziel UDisk im Bereich 0xE000-0xEFFF unterzubringen werde ich 
vermutlich nicht erreichen. Ob ich den EEProm Bereich als Code benutzen 
kann muss ich noch testen, das Datenblatt ist nicht ganz eindeutig.
Falls das funktioniert kann die zu flashende Firmware auf dem Stick max 
56kB sein.
Den Stick habe ich einfach mit einem simplen OTG Adapter angeschlossen.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

@Thomas

Das klingt ja ziemlich vielversprechend auch von der Geschwindigkeit her 
geht das ja,  bin gespannt.

von Thomas Z. (usbman)


Lesenswert?

naja noch ist das alles im Test. Ich arbeite im Moment mit einer debug 
Version die alles mögliche auf einem kleinen TFT mit einem umgeleiteten 
printf ausgibt. Später werde ich wieder auf die serial Debug Ausgabe 
umschalten.

Der oben gezeigte UDisk Code hatte auch noch ein paar kleine Bugs. 
Außerdem bin ich wieder über einige seltsame Konstrukte im WCH Code 
gestolpert die ich mir nicht erklären kann. Hab's halt einfach mal 
übernommen. Die entgültige Version wird dann allerdings keine Ausgaben 
enthalten sondern sollte einfach funktionieren. Noch bin ich mir auch 
nicht sicher ob mein ENum Code nicht zu strikt ist, da muss ich mal mit 
modernen Sticks das Verhalten prüfen. Meine alten Gurken gehen alle.

Hast du schon mal einen der CH54x in den Fingern gehabt?

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Mit den CH54X hatte ich noch nichts zutun und auch nicht wirklich 
angeschaut, sieht aber ja sehr ähnlich aus von den Features.


Das wirklich spannende für mich war ja der Preis de CH551 und CH552 dann 
kahmen die USB und Host funktionen des CH559 dazu.

von S. R. (svenska)


Lesenswert?

Thomas Z. schrieb:
> dekotieren

;-)

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Auch wenns es noch alles andere als fertig und perfekt ist möchte ich 
dennoch meinen heutigen erfolg kurz vorstellen.

https://youtu.be/EMDJe7JQ76g

Ich konnte erfolgreich den SDCC in der Arduino ide zum laufen bringen 
und das python flasher tool mit als programmer nutzen um nun aus der 
Arduino ide herraus zu programmieren und es auch neuligen deutlich 
einfacher zu gestallten. Vielen dank hierbei and Sduino( 
Beitrag "SDuino: Beinahe-Arduino für STM8S" 
) ohne das währe es nicht so einfach geworden.

von Thomas Z. (usbman)


Lesenswert?

coole Sache den c51 mit dem Arduino zu verheiraten, ich verstehe 
allerdings nicht so recht, wie du das c++ da reinfrickelst.

Mein UDisk nimmt so langsam Formen an. Nach einigen Aufräumarbeiten 
bekomme ich das nun in 4kb unter. Von der strong crypt Funktion hab ich 
mich allerdings verabschiedet.
Da ich den Code diesesmal auch zu SDCC kompatibel machen will überlege 
ich mir auch die MSB Option zu streichen. Ich denke bis Ende der Woche 
steht das.
Der UDisk Code kommt mit allen mir zur Verfügung stehenden Sticks klar.

Thomas

von Thomas Z. (usbman)


Lesenswert?

Ein kleines update...
Ich habe UDisk jetzt soweit fertig und auch für SDCC umgebaut. Wie 
erwartet ist der Code mit SDCC größer passt also nicht mehr nach 0xE000, 
statt 4kb sind es etwas mehr als 5kb. Ob der SDCC Code auch funktioniert 
muss ich noch testen.
Wie schon angekündigt ist sowohl die fast Option als auch die MSB Option 
beim Konverter weggefallen. Die notwendigen Konvertierungen macht UDisk 
direkt.
Die korrigierte Version werde ich morgen zusammen mit dem Projekt 
zeigen.

Thomas

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Hier nun UDisk. Es hat etwas gedauert bis mein Code auch für SDCC 
fehlerfrei  compiliert. Im Doc Ordner gibt's ein ausführliches readme.
Der debug target flashed einen Hexdumper ab 0x8000 welcher einfach per 
movc den Codespeicher auf TxT0 schickt. Interessant dabei ist das movc 
im Bootloader Bereich nur 0xFF liefert. Das unterscheidet den CH559 
wesentlich vom CH552.

Zum ausprobieren reicht es eines der test_udisk.hex Files auf den 
Controller zu flashen und FIRMWARE.BIN aus dem dumper Ordner auf den 
Stick zu ziehen. Dann einfach die der. Schnittstelle mit 57k6 8N1 
beobachten.

Der Keil Release target braucht 4032 Byte, mit LX51 und LinkerCode 
Packing lässt sich das auf 3800 Bytes drücken. SDCC braucht deutlich 
mehr, da hab ich mich aber nicht so intensiv mit dem Optimizer 
beschäftigt.

Im Tools Ordner befindet sich der modifizierte Konverter. Achtung das 
Format der Kommandozeile ist etwas anders und es gibt eine neue Option 
für den Key.

Thomas

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Habe deinen code einmal überflogen, das ist ja ein ganz schöner aufwand 
der dort drinsteckt!

Zu der CH55x Arduino C++ geschichte, es werden vor dem compilieren 
einfach alle cpp dateien in c umbenannt und als nur c kompiliert.

von Thomas Z. (usbman)


Lesenswert?

Der wirkliche Aufwand steckt darin, den Code sowohl für Keil als auch 
SDCC übersetzbar zu machen. Die Compiler unterscheiden sich doch etwas, 
viele meiner Makros die ich seit Urzeiten bei Keil verwende, musste ich 
erst mal anpassen. Der Hintergrund ist dass der Preprozessor im SDCC im 
Gegensatz zu Keil strikt std konform ist.

Einige Makros hab ich immer noch nicht korrekt hinbekommen. Leider 
machen die ganzen Fallunterscheidungen den Code nicht übersichtlicher. 
Du kannst das ganze ja mal mit der ersten Version vergleichen die weiter 
oben gezeigte ist.

Alles in allem war es mir das aber wert um etwas tiefer beim SDCC 
einzusteigen. SDCC ist wesentlich strikter was Warnungen angeht. Wenn 
jetzt noch die Code Größe vergleichbar wäre, gäbe es für Keil eigendlich 
keinen Grund mehr.

Thomas

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Ich habe gerade gemerkt dass im Keil Projekt noch meine TFT lib drin 
ist. uVision wird sich also beim Start über die fehlende Lib beschweren. 
Die kann gefahrlos entfernt werden da nicht mehr referenziert. Das ist 
noch ein Rest als ich printf auf ein TFT umgelenkt hatte.

Thomas

von selevo (Gast)


Lesenswert?

Gut gemacht!
Vielen Dank

von Thomas Z. (usbman)


Lesenswert?

Ich hatte eigentlich vor den UDisk Code auch für den Wickenhäuser 
Compiler und den MicroE Compiler vorzubereiten. Das wird leider nichts.
Der Wickenhäuser beherrscht kein #elif und ich will da nichts mehr 
umstellen.
Beim MicroE ist es so das MCUs nicht so ohne weiteres dazugebaut werden 
können. Es werden nur MCUs unterstützt die in der Liste auftauchen. Ich 
hätte mich also drum rum frickeln müssen, was wegen der mangelhaften Doc 
ziemlich aufwändig wäre. Eigentlich unbrauchbar in meinen Augen und 
keines wegs das Geld wert was Sie verlangen. Zusätzlich hat sich wohl 
seit 2013 nichts mehr getan.

von Thomas Z. (usbman)


Lesenswert?

Aaron C. schrieb:
> Zu der CH55x Arduino C++ geschichte, es werden vor dem compilieren
> einfach alle cpp dateien in c umbenannt und als nur c kompiliert.

Es gibt noch eine Arduino Implementierung

https://embdev.net/topic/498403#new

von Aaron C. (Firma: atcnetz.de) (atc1441)


Angehängte Dateien:

Lesenswert?

Danke für den Hinweis,

Deqing hatte bereits Kontakt mit mir über YouTube Kommentare...

Bin etwas verwirrt das die Kommentare gelöscht sind deshalb diese einmal 
als Anhang hier.

Nicht cool soweit, weiß aber auch nicht ob ich da was falsch verstehe, 
hatte ihm darum gebeten wenn er was aus meinem Code nutzt dieses in der 
BoardManager.json Datei mit meinem Namen zu erwähnen, was mehr als fair 
ist.

von Thomas Z. (usbman)


Lesenswert?

Ich würde dem nicht so viel Bedeutung beimessen. YouTube ist in China 
nicht so ohne weiteres verfügbar wie ich aus eigener Erfahrung weiss. 
Das geht nur über Anonymisierungsdienste. Vielleicht hat dir die große 
Firewall einen Streich gespielt.

von Aaron C. (Firma: atcnetz.de) (atc1441)


Lesenswert?

Scheinbar ist es tatsächlich geblockt, komisches YouTube.

von Max M. (maxmicr)


Lesenswert?

Eine Frage:

Kann man mit einem WCH-Controller der nur als Device fungieren kann 
(z.B. CH552) beim Einstecken einen USB-Stick "vorgaukeln" und sobald ein 
Benutzer eine Datei dahinkopiert, diese über den CH552 auf einen 
externen SPI-Flash schreiben?

Kann man als CH552 die Geschwindigkeit auch limitieren in der Windows / 
Linux die Datei überträgt? Ich vermute, die SPI-Schnittstelle läuft 
nicht schneller als vllt. halber CPU Takt? Das reicht nicht um mit USB 
2.0 mithalten zu können und der interne RAM wäre dafür zu klein.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.