uC für 0,20€ CH552 / CH554 von WCH Billig Micro mit USB Funktion, Chip vorstellung

[Harald A. (embedded)]

Ja, das hatte ich schon so verstanden, trotzdem Danke! Da sich die 
Anwendung mal ändern kann hätte ich schon gerne einen Taster gehabt. Ich 
denke ich werde einen sehr kleinen Taster ganz nah am Quarz 
positionieren. Das „Problem“ ist, das der Quarz im Endeffekt zu 99.999% 
der Betriebszeit aktiv ist.
Vlt. braucht es den Quarz ja auch nicht, werde mal ein wenig auf 
Temperatur testen.

[Thomas Z. (usbman)]

Ev kommt für dich auch die Alternative in Frage via 10K von DP+ nach 
V3.3.
Dazu musst du dann den alt. Bootpin in der Konfiguration auswählen.

Das muss beim allerersten Download schon selektiert werden, da nur ein 
leerer Chip den Bootloader automatisch startet. Das darf bei weiteren FW 
updates auch nicht vergessen werden, sonst kommst du auf normalem Wege 
nicht mehr an den Loader.

Genau das ist mir bei den ersten Experimenten mit dem CH559 passiert. 
Der Ausweg war dann via serial ein leeres Programm aufzuspielen

[Harald A. (embedded)]

Thomas, besten Dank! Im Grunde auch alles kein Problem, ich frage mich 
nur, wie es im Hause WCH zu dieser Designentscheidung gekommen ist. Vlt. 
hatten die ein Glücksrad mit 48-3 Pins und genau da ist es 
stehengeblieben.

[Harald A. (embedded)]

Habe mich gerade nochmal mit dem "missglückten" Pin des Bootloaders auf 
dem Crystal-In beschäftigt. In der o.g. Firmware ist es ja so, dass Pin 
4.6 permanent abgefragt wird und im Bedarfsfall in den Bootloader 
gesprungen wird. Ein schönes Feature, dass aber leider nicht mehr 
funktioniert, sobald man den externen Quarz nutzen möchte. Warum? Hat 
man erstmal im Programm auf externen Quarz umgestellt würde man durch 
die Betätigung des Tasters den Quarz "anhalten". Eine Verzweigung in den 
Bootloader würde nicht mehr stattfinden.

[Thomas Z. (usbman)]

Harald,
nein das ist so nicht richtig, der Bootloader startet nicht wenn du im 
laufenden Betrieb den Pin auf 0 legst das würde er übrigen auch nicht 
machen wenn du kein Quarz angeschlossen hättest. Es ist allerdings 
richtig dass der Quarz stoppen wird, wenn du den Taster betätigst.

Der Loader kann auf 2 verschiedene Weisen gestartet werden.
1. Dein Flash ist leer (es werden die ersten beiden Bytes geprüft)
2. Dein Loader Pin ist aktiv

Beides wird nur beim PowerOn Reset geprüft. Ist keine der Bedingungen 
gegeben wird ein SoftReset ausgelöst und die normale FW ab 0x0000 
gestartet.
Das og. ist etwas vereinfacht. Es werden ein paar mehr Bedingungen 
abgefragt. So ist es z.B beim CH559 mit v2.31 Loader auch möglich im 
Loadermode eine beliebige Addresse anzuspringen.

Es gibt noch einen 3.Weg:
Der Loader kann auch mit LJMP 0xF400 manuell aus der App gestartet 
werden. Dann gelten allerdings ein paar Einschränkungen. Es ist dann 
nicht möglich die Config Bits zu ändern.

[Harald (Gast)]

Thomas Z. schrieb:
> Es gibt noch einen 3.Weg:
> Der Loader kann auch mit LJMP 0xF400 manuell aus der App gestartet
> werden.

Genau so wird es in der o.g. Firmware gemacht. Und das würde eben nicht 
mehr funktionieren. Ein Ausschnitt aus dem Main.c:

while(1)
    {
        if(!(P4_IN & (1 << 6)))
            runBootloader();
        processUart();
        s = checkRootHubConnections();
        pollHIDdevice();
    }


Kann man mit leben, aber schon sehr suboptimal. Die Designer des CH559 
haben in der Hitliste der ungeeignetsten Pins den Rang 7 erreicht 
(vorher kommen nur noch GND, VDD33, VIN5, RESET, DM, DP). Aber nun soll 
es auch gut gewesen sein, ich habe die Augen schon genug gerollt. Ich 
weiß, dass nach einem Coldreset der interne Oszillator aktiv ist und 
damit der externe Quarz sozusagen kein Problem ist.

[Thomas Z. (usbman)]

jetzt verstehe ich dich was du meinst. Du willst den gleichen Pin auch 
in der Mainloop zum Starten des Loaders benutzen.
Das geht natürlich nur wenn kein ext. Quarz benutzt wird, da hast du 
recht.

Noch ein Hinweis:
Das manuelle Starten per App funktioniert bei neueren (anderen) 
Controllern sowieso nicht mehr (CH549 ev auch CH557/8) weil WCH den 
Bootloader Sektor im Appmode ausblendet.

Den gleichen USB Core hat WCH übrigens auch im CH32F103 zusätzlich 
eingebaut was den F103 dann mit 2 USB Schnittstellen ausstattet, die 
extra Schnittstelle auch mit Hostmode. Leider sind die meisten WCH Chips 
momentan nicht zu bekommen.

[Harald (Gast)]

Thomas Z. schrieb:
> Du willst den gleichen Pin auch
> in der Mainloop zum Starten des Loaders benutzen.

Ja, das kann ich ausbauen, Update kann man auch mit dem Reset starten, 
kein Problem.

Thomas Z. schrieb:
> Leider sind die meisten WCH Chips
> momentan nicht zu bekommen.

Ja, bei LCSC.COM sah es etwas mau aus, das stimmt.

[Andreas M. (amesser)]

So, gerade ist ein weiteres Projekt auf Basis des CH552 fertig geworden, 
und zwar ein Display/IR Empfänger. (mit USB Schnittstelle, logisch) Für 
das Display habe ich versucht mich an die USB HID Definitionen zu 
halten, so dass es generisch bleibt. Der IR Empfänger wird über CDC/ACM 
angesprochen und versteht das "GIRS" Protokoll und sollte mit lirc und 
seinem "girs" treiber funktionieren.

https://gitlab.com/amesser-group/electronic-devices/usb-hid-display

Bei diesem Projekt bin zum ersten mal darüber gestolpert, das der sdcc 
standardmäßig nicht reentrante Funktionen erzeugt. Das hat mich ein paar 
Haare gekostet :-) Das öffnet dann auch gleich wieder eine Baustelle an 
meinem JTAG Adapter.

[Thomas Z. (usbman)]

Andreas M. schrieb:
> Bei diesem Projekt bin zum ersten mal darüber gestolpert, das der sdcc
> standardmäßig nicht reentrante Funktionen erzeugt

ja das ist aber bei Keil ganz genauso. Das liegt daran das 
Funktionsparameter wegen des begrenzten Stacks üblicherweise nicht über 
einen Stackframe angesprochen werden. Einer der Nachteile der MCS51 
Architektur was C angeht.

[Thomas Z. (usbman)]

ich habe meinen USB Midi Code, den ich hier schon mal gepostet hatte, 
überarbeitet und auch für den SDCC bereit gemacht. Wie erwartet ist der 
SDCC code etwa 20% größer.

Das Projekt ist hier zu finden:
Beitrag "Usb Midi Firmare für die WCH CH55x Controller"

[Reinschson (Gast)]

Können die bezüglich Stromverbrauch / Batteriebetrieb bei STM8Ls 
halbwegs mithalten?

[Thomas Z. (usbman)]

im Datenblat werden typisch 2 mA bei 775kHz und 6 mA bei 16Mhz genannt 
@3,3V
Sleep: max 150µA bzw im besten Fall (alles abgeschaltet) 10µA.

https://github.com/Blinkinlabs/ch554_sdcc/tree/master/documentation

[Andreas M. (amesser)]

Also gefühlt ziehen die schon relativ viel Strom. Gerade mit steigender 
Taktfrequenz. Ob man aus dem Deep Sleep mit alles Aus wieder rauskommt 
ohne den Reset zu ziehen... Dafür sind se halt nicht gemacht, auf meinen 
Boards sind Hauptverbraucher aber Andere, da fällt das nicht so ins 
Gewicht.

[Peter D. (peda)]

Thomas Z. schrieb:
> ja das ist aber bei Keil ganz genauso. Das liegt daran das
> Funktionsparameter wegen des begrenzten Stacks üblicherweise nicht über
> einen Stackframe angesprochen werden. Einer der Nachteile der MCS51
> Architektur was C angeht.

Nö, es wird ein Vorteil des MCS51 ausgenutzt, daß er viele Operationen 
direkt im RAM machen kann. Z.B. einen Schleifenzähler kann man mit "DJNZ 
Adresse" im RAM laufen lassen. RAM wird dadurch nicht gespart, nur eine 
Menge PUSH/POP. Damit wird der Code klein und schnell.
Dazu wird ein Call-Tree erstellt und die benutzten lokalen RAM-Variablen 
der Funktionen überlagert.

Reentrante Funktionen braucht man nur extrem selten, so daß es sich 
lohnt, nur diese mit dem Attribut "reentrant" zu versehen. Diese werden 
dann natürlich pushen und poppen, bis der Arzt kommt.
Bei zeitkritischen Sachen kann es sich daher lohnen, diese Funktion 
einfach zu kopieren.

[Harald A. (embedded)]

Harald schrieb:

> Kann man mit leben, aber schon sehr suboptimal. Die Designer des CH559
> haben in der Hitliste der ungeeignetsten Pins den Rang 7 erreicht
> (vorher kommen nur noch GND, VDD33, VIN5, RESET, DM, DP). Aber nun soll
> es auch gut gewesen sein, ich habe die Augen schon genug gerollt. Ich
> weiß, dass nach einem Coldreset der interne Oszillator aktiv ist und
> damit der externe Quarz sozusagen kein Problem ist.

Wollte nur mal berichten, dass die Umschaltung auf den externen Quarz 
beim CH559 ohne Probleme funktioniert. Ich hatte ja berichtet, dass ich 
beim USB-HOST Betrieb einen „richtigen“ Quarz für erstrebenswert halte. 
Der Boot-Taster hängt halt parallel mit am Quarzeingang XI - hmmmh ja, 
grummel, meinetwegen.

Nebenbei: Beim Einstellen der Baudrate für die UART fühlt man sich 
direkt in die alten 8051-Zeiten zurückversetzt. Wie primitiv (und 
unflexibel) das damals war… man ja ist ja doch schon durch die 32bit 
Welt etwas verwöhnt.

[Thomas Z. (usbman)]

Ich habe vermutlich den ersten Ausfall des Flashs bei einem CH552 mit 
v2.31 Bootloader. Der Baustein hat m.M. die 200 Zyklen nur knapp 
überschritten bringt aber beim Verify bei manchen Hex Files nun einen 
Verify Error.

Es ist so, dass wohl ein Bit in den ersten 0x3D Bytes sich nicht mehr 
auf 1 setzen lässt. Bei Chips mit V1.1 Loader ist mir das nie passiert. 
Das kann natürlich Zufall sein, ich habe aber den Verdacht dass dies 
auch mit der Art und Weise zu tun hat wie das Erase Cmd bei der v2.31 
implementiert ist.

Ein Hexfile mit 0x00 auf allen Adressen lässt sich ohne Fehler flashen, 
ein File mit 0xFF bricht mit verify error beim ersten Block ab. 
Zurückgelsen hab ich noch nicht. Im Anhang ein Bild mit dem Verify 
Request der den Fehler meldet.

[TU Student 1. (student0)]

Harald A. schrieb:
> V-USB ist doch diese Software-Emulation eines USBs, richtig? Das hätte
> für mich eh keinerlei Relevanz da meiner Meinung nach völlig obsolet.
> ...

V-USB ist zudem nicht mit USB 3.0 Controllern ohne dazwischen 
geschaltenen USB-Hub, der oftmals toleranter ist, kompatibel, wie ich 
mit einem DigiSpark ATTINY85 verifiziert habe.   Der DigiSpark ATTINY85 
geht mit der Arduino USB-Firmware, die ja auch auf V-USB basiert an 
keinem einzigen USB 3.0 Port bei drei verschiedenen Laptops (darunter 
ein Macbook Pro).

Daher aus meiner Sicht jetzt obsolet - denn immer mehr Laptops/PCs haben 
keinen einzigen USB 2.0 Port mehr.

Interssant wäre es, z.b. USB-ASP auf den CH552 zu portieren, weil es da
1) Billige fertige Devboards gibt
2) Der CH552 einen USB-Bootloader hat
3) Es einen freien C-Compiler (SDCC) gibt

D.h. jemand, der das nachbauen will benötigt nichts anderes als das 
billige CH552G-Devboard.

Ausserdem hätte ein Port von USBASP auch den Vorteil, dass die Chinesen 
wieder mit der Massenproduktion von USBASPs - diesmal USB 3.0 kompatibel 
- loslegen können ;)

Was den CH552 betrifft - laut WCHISPTool habe ich bisher 57x geflashed 
im Laufe des "Shotgun-Debugging", ich habe noch 2 Devboards rumliegen... 
;)

Dass man den nur ca. 200x flashen kann ist auch bemerkenswert - viele 
PICs sind z.b. mit minimum 10k Zyklen spezifiert - d.h. das wird 
garantiert.  Erinnert ein wenig an die sowjetischen Ziegelstein-EPROMs, 
die auch wenig zyklenfest waren ;)

(Das->Dass)

[TU Student 1. (student0)]

Übrigens dürfte auch der CH9329 ("UART to HID keyboard/mouse/customized 
HID IC, supports multiple working modes and serial communication modes") 
ein CH552G oder ein CH551G sein, denn das Pinout ist identisch.

Hier gibt es den in Stick-Form
https://www.aliexpress.com/item/1005003679447698.html

Evtl. auch eine Alternative wenn CH55x nicht auf Lager ist?

[Thomas Z. (usbman)]

TU Student 1. schrieb:
> Interssant wäre es, z.b. USB-ASP auf den CH552 zu portieren,

ich kenne USB-ASP nur vom hören sagen. Ein kurzer Blick in die Sourcen 
zeigt aber, dass das reines c ist. Nur der Usbtreiber selbst ist 
natürlich in ASM.
Diesen mit einem passenden CH552 C code  zu ersetzen dürfte kein allzu 
großes Problem sein. Ich bin allerdings kein AVR Freak kann also nur 
schlecht beurteilen wie das mit den Baudraten funktioniert. MCS51 
Designs haben ja ein paar Limits was die Baudraten angeht.
tpi.s könnte allerdings ein Problem werden.
Wie sehen denn die Deskriptoren eines USB-ASP aus?

[TU Student 1. (student0)]

Ich habe jetzt keinen USBasp(-Clone) hier, aber hier sieht man den 
Descriptor und der passt auch mit dem Sourcecode aus usbconfig.h und der 
Tatsache, dass es kein HID-Device ist zusammen:

https://www.avrfreaks.net/sites/default/files/llllll.JPG

Es dürfte auch alles über den Control-Endpoint 0 laufen, wie es aussieht

Der USBasp verwendet einen libUSB-Treiber um mit diesem 
Custom-USB-Device zu sprechen

Meinst du UART-Baudrate?  Die AVRs werden per SPI geflashed.

Habe mit 8051 selbst eigentlich nie was gemacht, ausser das Tutorial auf 
8052.com damals durchgearbeitet ...

[Thomas Z. (usbman)]

TU Student 1. schrieb:
> Es dürfte auch alles über den Control-Endpoint 0 laufen, wie es aussieht

ok vermutlich geht die Kommunikation dann nur über Setup Vendor Calls 
wenn ich main.c richtig interpretiere. Das ist ziemlich einfach auf dem 
ch552 zu machen. Die restlichen c files sehen auch nicht besonders 
kompliziert aus.

Bauchschmerzen würde mir wie gesagt das asm tpi modul bereiten. Es hat 
sicher einen Grund (Timming?) warum das nicht in C gemacht wurde. Fischl 
hat in seinem Schaltplan den Uart auf die Stiftleiste gelegt, dass ist 
aber ev nur zu debug zwecken.
Ist es wirklich sinnvoll noch einen Programmer für die AVRs zu machen? 
Davon gibt es ja schon mehr als genug und wenn ich das richtig sehe 
jeder mit ganz eigenen Problemen.

Ich hätte sogar einen Stick auf dem man das testweise frickeln könnte.
Beitrag "Re: uC für 0,20€ CH552 / CH554 von WCH Billig Micro mit USB Funktion, Chip vorstellung"

[Thomas Z. (usbman)]

TU Student 1. schrieb:
> Interssant wäre es, z.b. USB-ASP auf den CH552 zu portieren, weil es da
> 1) Billige fertige Devboards gibt
> 2) Der CH552 einen USB-Bootloader hat
> 3) Es einen freien C-Compiler (SDCC) gibt

Ich hab da mal was gezeichnet :-)
Da der CH552 nicht 5V tolerant ist braucht es Pegel Konverter.
Die FW von Fischl habe ich mal testweise portiert (ohne TPI). Zusätzlich 
habe ich die Deskriptoren erweitert um ein zusätzliches CDC Device 
unterzubringen.
Es gibt wie beim Original einen Speed Jumper so wie die Umschaltung 
5V/3.3V.

Der CH552 enumeriert als Fullspeed Device. Mit eigener Software könnte 
man damit auch einen universellen SPI Flasher realisieren.

[Thomas T. (knibbel)]

Zwei Anmerkungen/Fragen zum Schaltplan:

1) Die Kathode der Doppeldiode D3 hängt fest auf 3,3V (oder 3V?). Die 
würde ich aber eher auf den mittleren Pin (Pin 2 vom 
"Power-Selector"-Jumper) setzen, damit bei Betrieb mit 5V die Kathode 
dann auch auf 5V hängt. Oder liege ich da falsch?

2) Wieso ist der CH552G nicht "5V tolerant", wie du schreibst?
Wäre es nicht einfacher und könnte man nicht den Levelshifter sparen, 
wenn man den ganzen Controller einfach mit der Zielspannung versorgt?

Gruß
Thomas

[Thomas Z. (usbman)]

Thomas T. schrieb:
> Wieso ist der CH552G nicht "5V tolerant"
um ganz ehrlich zu sein, ich weis es nicht genau, meine aber sowas mal 
gelesen zu haben, kann dazu aber nichts finden. Es ist allerdings so 
dass die Port Pins nur auf 3.3V hoch gehen, auch wenn der Chip mit 5V 
versorgt wird. Der Treiber ist vermutlich nicht notwendig, ich hab den 
zur Sicherheit mal vorgesehen.

Den CH552 umzuschalten ist nicht so ganz einfach, da der V5 Pin im 3.3V 
Betrieb mit mit dem V3.3 Pin verbunden werden muss und dann mit 3.3V 
versorgt werden muss. Zusätzlich sind im 3.3V Betrieb nur noch 16MHz 
erlaubt, da könnte es problematisch werden 115k2 Baud zu erreichen. Das 
müsste ich noch mal nachrechnen. Ich habe bisher mit 24MHz geplant.

Die Doppeldiode soll die zwei Eingangssignale fest auf 3.3V klemmen, da 
ich den internen Schutzdioden nicht traue.

[Thomas T. (knibbel)]

Ich bin da auch nicht 100% sattelfest, man möge mich verbessern, falls 
notwendig...

Thomas Z. schrieb:
> Es ist allerdings so
> dass die Port Pins nur auf 3.3V hoch gehen, auch wenn der Chip mit 5V
> versorgt wird.

Das Datenblatt sagt bei VOH5 (High level output voltage (output current 
8mA)): Minimum: VCC-0,4V

Da sollte also etwas zwischen 4,5V und 5,0V zu messen sein...


Thomas Z. schrieb:
> Zusätzlich sind im 3.3V Betrieb nur noch 16MHz
> erlaubt, da könnte es problematisch werden 115k2 Baud zu erreichen. Das
> müsste ich noch mal nachrechnen. Ich habe bisher mit 24MHz geplant.

Oh, bei 3,3V nur 16MHz erlaubt? Dann wird das wohl nichts mit direktem 
Betrieb mit 3,3V. Du brauchst doch die 24MHz, aus denen dann 48MHz für 
die USB-Schnittstelle erzeugt werden...

Im Datenblatt habe ich aber dazu auch nicht wirklich was gefunden...


Gruß
Thomas

[Harald A. (embedded)]

Thomas Z. schrieb:
> Ich habe vermutlich den ersten Ausfall des Flashs bei einem CH552

Ich hatte bei JLCPCB ein paar Platinen mit dem CH559 bestücken lassen. 
Eine Platine davon lässt sich überhaupt nicht ansprechen. Ich habe alles 
mögliche geprüft, es müsste der Controller sein. Leider kann ich ihn 
nicht tauschen, da ich keinen einzelnen CH559 habe.

Die Frage ist jedenfalls, ob sonst schon jemand einen Controller aus 
dieser Familie hatte, der es von vornherein nicht tat.

[Thomas Z. (usbman)]

Thomas T. schrieb:
> Du brauchst doch die 24MHz, aus denen dann 48MHz für
> die USB-Schnittstelle erzeugt werden...

nein der USB Clock ist unabhängig von Fsys. Fullspeed geht ab 3MHz 
Lowspeed ab 1.5MHz. Bei mir hat USB nicht mehr funktioniert wenn ich auf 
32MHz gestellt habe, Das ist aber sowieso nicht spezifiziert.

[Thomas Z. (usbman)]

Harald A. schrieb:
> Die Frage ist jedenfalls, ob sonst schon jemand einen Controller aus
> dieser Familie hatte, der es von vornherein nicht tat.

Prüfe den Reset Pin auf Lötfehler / Kurzschluss. Der hat bei mir wegen 
eines Schaltungsfehlers anfangs einen Start verhindert.

[Thomas Z. (usbman)]

Thomas T. schrieb:
> Das Datenblatt sagt bei VOH5 (High level output voltage (output current
> 8mA)): Minimum: VCC-0,4V

ok gerade noch mal nachgemessen, Es sind so knapp 4V an den Ports (x51 
mode)

[Andreas M. (amesser)]

Thomas Z. schrieb:
> erlaubt, da könnte es problematisch werden 115k2 Baud zu erreichen. Das
> müsste ich noch mal nachrechnen. Ich habe bisher mit 24MHz geplant.

Für 115k2 Baud brauchst du auf jeden Fall 24MHz. Sonst passt der Teiler 
nicht und das UART Timing ist kaputt. Hab ich schon auspropbiert.

[Thomas Z. (usbman)]

Andreas M. schrieb:
> Für 115k2 Baud brauchst du auf jeden Fall 24MHz. Sonst passt der Teiler
> nicht und das UART Timing ist kaputt. Hab ich schon ausprobiert.

Danke, so ist auch mein Wissensstand. Ich hab nur noch nie ausgerechnet 
ob 115k2 auch bei 16MHz zu erreichen sind, Bei 24 MHz ist der Fehler ja 
schon bei 3%.
Ich hab mal eine Platine zu dem Schaltplan gemacht. Die Doppeldiode ist 
noch drin kann man aber problemlos weglassen.

[Max M. (Gast)]

Aaron C. schrieb:
> CH552 oder CH554.

Ganz spannende Teile nur anscheinden sind die auch schon schwer 
verfügbar.
Also wenn schon die Teile kaum noch zu besorgen sind geht die Welt 
wirklich unter 😂
Oder ich habe falsch geschaut 🙄

[Thomas Z. (usbman)]

Max M. schrieb:
> Oder ich habe falsch geschaut 🙄

hast du nicht LCSC listet fast alle mit 0 Bestand (bei 3fachem Preis). 
Das ist jetzt schon ein Jahr so.
Man kann die Teile wohl momentan nur bei WCH direkt bekommen. Ich habe 
keine Ahnung was für Stückzahlen da verfügbar sind.

[Max M. (Gast)]

Ich seh mich schon Nachts in der Wertstoffhof einbrechen, um die 
E-Schrott Kisten zu plündern, wenn das so weitergeht :-/

[Thomas Z. (usbman)]

Max M. schrieb:
> Ich seh mich schon Nachts in der Wertstoffhof einbrechen, um die
> E-Schrott Kisten zu plündern, wenn das so weitergeht :-/

Für meine Basteleien reicht mein Vorrat. Ich benutze den Lagerbestand 
bei LCSC als Indikator. Wenn die Teile wieder in Stückzahlen verfügbar 
sind ist vermutlich die Chipkrise vorbei. :-)

[TU Student 1. (student0)]

Weitere WCH Module, die man zweckentfremden kann (z.b. hier mit dem 
CH549):

WAVGAT Wchlink Mini HC594F Daplink supports a full range of ARM core 
chips/Qinheng RISC-V chips 3.3V /5V
https://www.aliexpress.com/item/1005003615324166.html?
1 Stk. um 4,83 EUR inkl. Versand

Kleines Board das aussieht wie ein ISP-Dongle.

WCH link download debugger risc-v framework MCU online debugging SWD 
interface chip programming
https://www.aliexpress.com/item/1005003482789318.html
3 Stk. um 14,59 EUR (= pro Stk. 4,86 EUR)

Billigstes Board mit Gehäuse und USB-C
WCH-Link emulator download the debugger rISC-V ARM online SWD TTL serial 
port TYPE-C
https://www.aliexpress.com/item/1005002795462484.html
1 Stk. um 3,64 EUR inkl. Versand
3 Stk. um 7,40 EUR inkl. Versand (= pro Stk. 2,46 EUR)

Diese Module hat möglicherweise alles drauf um einen ISP/ICSP/... zu 
realisieren und basieren auf dem CH549, der mehr Features hat (Host 
Mode, mehr Flash, Temperatursensor (!), ...)

Den CH548 (kleineres Modell) gibt es sogar im SOIC8 (SOP8). Wow!

[sepp (Gast)]

den CH552T ( TSSOP-20 package ) gibt es noch hier:
https://www.shotech.de/de/ch552t-e8051-core-mcu.html

der CH552G ( SOP-16 package ) ist da leider auch ausverkauft :(

[Thomas Z. (usbman)]

es gibt wohl einen neuen Bootloader v2.5. Zumindest gibt es bei WCH dazu 
einen Thread. Wenn ich die Übersetzung richtig verstanden habe, ist der 
kaputt. oder das ISP Tool macht bei der Version murks.

THIS YEAR'S NEWLY ACQUIRED CH552G CHIP WCHISP READ OUT ALL THE SAME ID, 
RESULTING IN THE FAILURE OF THE ORIGINAL FIRMWARE FUNCTION

read it all out and that's it
17:47:15:052>> 0#ISP DEV:94-12-00-00-00-00-00-00
17:47:15:055>> UID:94-12-00-00-00-00-00-00,BTVER:02.50

cause the original firmware to be abnormal replaced by the old chip 
everything is normal, what is the situation?

[ds_user (Gast)]

Thomas Z. schrieb:
> there seems to be a new bootloader v2.5. At least there is at WCH
> to do so
> a thread. If I understood the translation correctly, it is
> broken. or the ISP tool messes up the version.
>
> THIS YEAR'S NEWLY ACQUIRED CH552G CHIP WCHISP READ OUT ALL THE SAME ID,
> RESULTING IN THE FAILURE OF THE ORIGINAL FIRMWARE FUNCTION
>
> read it all out and that's it
> 17:47:15:052>> 0#ISP DEV:94-12-00-00-00-00-00-00
> 17:47:15:055>> UID:94-12-00-00-00-00-00-00,BTVER:02.50
>
> cause the original firmware to be abnormally replaced by the old chip
> everything is normal, what is the situation?

Are you the usbman in the wch official forum? I got a few extra 2.5.0 
ch552 boards. If you want some, my contact can be found on my GitHub 
profile (author of ch55xduino). Send me an email with your address and I 
can mail you 2 boards from US.

[Thomas Z. (usbman)]

ich hab mal wieder mit dem CH552 rumgespielt. Dabei hab ich mich 
insbesondere mit den Clocks und Powermodes beschäftigt.

Folgendes ist mir aufgefallen:

1. man kann den Core mit 32MHz takten USB geht dann allerdings nicht. 
Damit ist SPI mit 16MHZ möglich
2. Alle diese CH55x chips besitzen kein IDL bit in PCON. Schade, denn 
dieses Bit ist schon immer im x51 drin gewesen
3. Bootloader via Reset Pin. Man kann den Reset Pin CLOCK_CFG abfragen 
auch wenn der ext Reset nich aktiviert ist. Ich benutze das momentan um 
auch über den Reset Button beim PwrOn in den Loader zu springen.
4.ds_user hat mir vor einiger Zeit 2 ch552 mit V2.5 loader zur Verfügung 
gestellt. Soweit ich sehen kann springt der Loader nun nach einem 
Timeout automatisch nach 0x000. Das Disassembly kommt demnächst

[Thomas Z. (usbman)]

Wie versprochen erst mal die V2.5 als Intel Hex. Ich hab auch schon ins 
Disassembly geschaut: Es entspricht weitgehend der V2.4 die ich schon 
mal gepostet hatte. Dazugekommen ist lediglich eine Timeout Abfrage um 
automatisch den SoftReset auszulösen. Dadurch ist die main etwas 
umfangreicher. WCH hat übrigens gemerkt, dass die rand() Funktion 
vollkommen sinnlos war, die ist nun weg. Vermutlich haben die einfach 
den Speicherplatz gebraucht. Zusätzlich ist die Position von main() im 
Addressraum verschoben.

Source folgt sobald die ASM Datei ordentlich formatiert ist.

Ausgelesen hab ich den Loader mit meinem (modifizierten) freader und 
einem V1.1 fakeloader ab 0x3000 da ja das Auslesen seit 2.4 nicht mehr 
funktioniert. Dabei habe ich auch den Grund enddeckt warum der freader 
bei manchen Leuten nicht funktioniert:
Es liegt ganz einfach an der ch375dll.dll die ja beim Installieren des 
WCHIspTools im Win Verzeichnis abgelegt wird. Davon gibt es 
unterschiedliche Versionen. Fixen lässt sich das wenn meine DLL im 
gleichen Verzeichnis wie der freader liegt.

[Thomas T. (knibbel)]

Thomas Z. schrieb:
> Source folgt sobald die ASM Datei ordentlich formatiert ist.

Ja, bitte. Der Source interessiert mich insofern, da ich inzwischen der 
Überzeugung bin, dass die in der Firmware enthaltene "c runtime 
memcpy"-Routine fehlerhaft ist...

Und zwar wird in dieser Routine nach rund 7-8 Befehlen ein 16Bit-Pointer 
inkrementiert (im boot_v2.asm steht dort "RAME/F++"). Allerdings wird 
das High-Byte dort erst geladen und dann wird verglichen, ob das 
Low-Byte nach dem Inkrementieren 00h ist, also ein Übertrag stattfand. 
Wenn dies der Fall sein sollte, wird zwar das High-Byte ebenfalls 
inkrementiert, jedoch nicht mehr geladen.

Als Ergebnis enthält der (geladene) Pointer dann beispielsweise folgende 
Werte:

03FDh, 03FEh, 03FFh, 0300h(!), 0401h, 0402h, 0403h

Auswirkungen hat das aber wohl keine, weil die Routine zur Zeit wohl 
nicht über Page-Grenzen kopieren muss...

Gruß
Thomas

EDIT: Habe mir den Hexdump mal auf die Schnelle angeschaut: Sieht so 
aus, als wenn sich nur der Pointer von "RAME/F" nach "RAMD/E" verschoben 
hat, aber sonst die Befehle gleich sind. Der Fehler ist da wohl immer 
noch drin...

[Thomas Z. (usbman)]

Thomas T. schrieb:
> Überzeugung bin, dass die in der Firmware enthaltene "c runtime
> memcpy"-Routine fehlerhaft ist...

dazu muss ich sagen runtime stimmt nicht.. Keils memcpy Funktion ist 
deutlich umfangreicher. Die genannte Funktion ist handgeschrieben.

Es sind nur noch 2 Keil Runtime Funktionen drin (Original Namen 
?C?CLDPTR und ?C?CSTPTR)
Das main Programm ist etwas komisch bei der Auswertung der HW 
contitions. Die werten das 2 mal aus. Das hab ich noch nicht verstanden. 
Ich bin aber der Meinung dass der Sprung nach Boot beim PowerOn nicht 
mehr so zuverlässig funktioniert. Zusätzlich überschreiben Sie an einer 
Stelle den Timer0 mode der  zuvor auf Mode 1 gestellt wurde mit Mode 0 
-> mov   TMOD, #0x20.
Timer 0 wird für den Timeout benutzt. Das hat wohl auch keine 
Auswirkungen.

Viele Änderungen gibts im Serial Dispatcher. Da bin ich noch nicht durch
Ich kann zwar schon fehlerfrei übersetzen allerdings noch nicht 
binärgleich da ich die Änderungen in meine Sourcen reinpflege.
Weil der BootStart unzuverlässig auf der weact hw funktioniert starte 
ich den Loader momentan per Abfrage des Reset Pins.

[Thomas Z. (usbman)]

Thomas T. schrieb:
> Allerdings wird
> das High-Byte dort erst geladen und dann wird verglichen, ob das
> Low-Byte nach dem Inkrementieren 00h ist, also ein Übertrag stattfand.

das ist schon richtig so der Keil Compiler ist big Endian sprich Hi Byte 
kommt vor Low Byte.

[Audiomann (Gast)]

Aaron C. schrieb:
> Heißt also der CH551 kann als Slave USB Gerät irgendwo angeschlossen
> werden wie Maus, Tastatur oder USB Stick an einen PC o.ä.

Könnte man auch MIDI-Controller anschließen?

[Thomas Z. (usbman)]

Audiomann schrieb:
> Könnte man auch MIDI-Controller anschließen?

nur bei Chips die auch den Hostmode unterstützen, aslo ab CH554. CHhh1 
und CH552 unterstützen nur USB Device mode

[Thomas Z. (usbman)]

Thomas Z. schrieb:
> dazu muss ich sagen runtime stimmt nicht.. Keils memcpy Funktion ist
> deutlich umfangreicher. Die genannte Funktion ist handgeschrieben.

In c würde die memcopy Funktion etwa so aussehen, da WCH generische ptr 
verwendet:

void mem_cpy (uint8_t *dest,uint8_t *src,uint8_t len)
{
   while(len--) *dest++ = *src++;
}

Beim Keil wird der erste param wird via R1..R3 übergeben, die anderen 
Params über Speicherstellen.

Effektiver wäre folgende Variante:

void mem_cpy (uint8_t xdata *dest,uint8_t code *src,uint8_t len)
{
   while(len--) *dest++ = *src++;
}

dann würden alle params per Register übergeben und der Compiler würde 
dann die beiden ptr funktionen weglassen. Bei dieser Variante könnte man 
auch sehr gut den extra op code verwenden.

Der Unterschied zum memcpy aus der lib ist, dass len nur 8 bit breit 
ist.

https://github.com/usbman01/Replacement-WCHs-debug.c/blob/main/ch544/src/misc/fastccopy.a51

zeigt die Implementierung als Keil ASM Modul. für SDCC hab ich das bis 
jetzt noch nicht geschafft da ich noch nicht verstanden habe wie die 
Parameter Übergabe funktioniert.

[Thomas T. (knibbel)]

Thomas T. schrieb:
> Ja, bitte. Der Source interessiert mich insofern, da ich inzwischen der
> Überzeugung bin, dass die in der Firmware enthaltene "c runtime
> memcpy"-Routine fehlerhaft ist...
>
> Und zwar wird in dieser Routine nach rund 7-8 Befehlen ein 16Bit-Pointer
> inkrementiert (im boot_v2.asm steht dort "RAME/F++"). Allerdings wird
> das High-Byte dort erst geladen und dann wird verglichen, ob das
> Low-Byte nach dem Inkrementieren 00h ist, also ein Übertrag stattfand.
> Wenn dies der Fall sein sollte, wird zwar das High-Byte ebenfalls
> inkrementiert, jedoch nicht mehr geladen.

Ich glaube, da muss ich mich selbst korrigieren. Ich habe mir die 
Routine jetzt nochmal ganz ganz genau angesehen und Befehl für Befehl 
nachverfolgt.

Die Routine inkrementiert zwar den Pointer, in R1 und R2 soll aber der 
alte Wert (also der nicht inkrementierte Wert) stehen. Und das macht die 
Routine auch so.

Ich lag da also falsch und bitte um Ignorieren meines vorherigen 
Beitrags...

Gruß
Thomas

[Thomas Z. (usbman)]

hier nun der Source Code des V2.5 loaders. Das ganze sollte sich auch 
mit der Demo Version des Keils übersetzen lassen, da es ein absolutes 
File ist und nicht aus mehreren Modulen besteht.
Ich habe den Overlay Speicher etwas umbenannt. Das übersetzte File ist 
binärgleich zum ausgelesenen Original.

Ach ja:
viele Adresslabel entsprechen nicht (mehr) der Realität weil ich das 
Ding aus den v2.31 Sourcen abgeleitet habe. Ich war da einfach zu faul 
die alle zu korrigieren. Das ist aber kein wirkliches Problem.

[ds_user (Gast)]

Thomas Z. schrieb:
> here is the source code of the V2.5 loader. The whole should also
> with the demo version of the wedge, since it is an absolute
> File is and does not consist of several modules.
> I renamed the overlay memory a bit. The translated file is
> binary equal to the read original.
>
> Oh yes:
> many address labels do not (any longer) correspond to reality because I
> Thing derived from the v2.31 sources. I was just too lazy
> to correct all of them. But that's not a real problem.

    mov   __addr, A                ;    if (????) cmdbuffer[3]--;
    anl   A, #3
    orl   A, __addr+1
    jnz   code_39C3

This should means if ((addr & 0x3FF) == 0) cmdbuffer[3]--;

[ds_user (Gast)]

Thomas Z. schrieb:
> here is the source code of the V2.5 loader. The whole should also
> with the demo version of the wedge, since it is an absolute
> File is and does not consist of several modules.
> I renamed the overlay memory a bit. The translated file is
> binary equal to the read original.
>
> Oh yes:
> many address labels do not (any longer) correspond to reality because I
> thing derived from the v2.31 sources. I was just too lazy
> to correct all of them. But that's not a real problem.

Also

JumpFunction3:                     ;  delete rom page
    mov   A, cmdbuffer+3           ; if (cmdbuffer[3] > 8) break
    clr   C
    subb  A, #8
    jnc   code_399A
    Xjmp  FuncBreak

This should be
if (cmdbuffer[3] < 8) break

I tried to set cmdbuffer[3] to different values in vnproch551. Any value 
less than 8 will case a "Packet 0 doesn't match." error.

[Thomas Z. (usbman)]

ds_user schrieb:
> I tried to set cmdbuffer[3] to different values in vnproch551. Any value
> less than 8 will case a "Packet 0 doesn't match." error.

if i remember correctly funcion3(DeleteTomPage) before did just delete 1 
or 2 pages in v2.31 now they delete 8 pages starting from v2.4.
Basically using the verify cmd does not work any longer as before. After 
the first mismatch a error flag is set which just get reset with the 
delete cmd

[Steve van de Grens (roehrmond)]

TU Student 1. schrieb:
> Der DigiSpark ATTINY85
> geht mit der Arduino USB-Firmware, die ja auch auf V-USB basiert an
> keinem einzigen USB 3.0 Port bei drei verschiedenen Laptops (darunter
> ein Macbook Pro).

An meinem Linux Laptop mit USB-3.0 Anschlüssen läuft der DigiSpark 
einfach so, ohne Tricks.

[Thomas Z. (usbman)]

Es gibt von WCH nun auch offiziell englische DBs. Da findet wohl gerade 
ein Umdenken statt.

http://www.wch-ic.com/downloads/CH554DS1_PDF.html
http://www.wch-ic.com/downloads/CH559DS1_PDF.html

[Aaron C. (Firma: atcnetz.de) (atc1441)]

Patrick ist da auch hinterher und lässt mit sich reden :) :
https://twitter.com/Patrick_RISCV?t=oGbuaci48ZEGl8nVCGqeGg

[Pavel (pvo317)]

Helfen Sie mir, Antworten auf Fragen wie diese über CH552 zu finden:

 - Wo kann ich die Bibliothek für PROTEUS finden?

 - Welche Speichergröße benötige ich für das HID KBD-Programm?

Ich möchte einen USB-Stick erstellen:
Es gibt zwei Tasten als Berührungssensor und zwei LEDs.
Taste 1 sendet eine Zeichenfolge von 10 Zeichen und schaltet die LED 1 
ein.
Taste 2 sendet eine Zeichenfolge von 16 Zeichen und schaltet die LED 2 
ein.

Ich plane, ein KEIL 51 zu verwenden.
Wenn ich Erfolg habe, werde ich versuchen, ein EEPROM + i2c-Display 
hinzuzufügen.

[Andreas R. (daybyter)]

RiscV Mikrocontroller von WCH für 10ct:

https://www.youtube.com/watch?v=L9Wrv7nW-S8

[Andreas M. (amesser)]

Zur Info: Mir ist grad aufgefallen, das WCH jetzt selbst ein Englisches 
Datenblatt für den CH552 anbietet: 
http://www.wch-ic.com/downloads/CH552DS1_PDF.html

[Andreas M. (amesser)]

Heute habe ich mal ein bisschen mit der PWM gespielt. In der 
Dokumentation wird das PWM_CK_SE ja leider nicht detailliert 
beschrieben. Meine Experimente haben ergeben, das man mit PWM_CK_SE ein 
Taktteiler von 1 bis 256 für die PWM konfigurieren kann.
- PWM_CK_SE := 0 -> PWM_CK = FSYS/256
- PWM_CK_SE := 1 -> PWM_CK = FSYS/1
- PWM_CK_SE := 2 -> PWM_CK = FSYS/2
- ....

Bei 12MHz FSYS und PWM_CK_SE := 1 ergibt sich somit eine Grundfrequenz 
von 46.9kHz am PWM Ausgang (1/Periode)

Hintergrund ist, das ich gerade an einem UPDI Programmer mit HV Support 
arbeite und die beiden PWMs als Ladepumpe für die HV benutzen möchte. Im 
Leerlauf komme ich jetzt so auf knapp 18V. Reichlich übers Ziel hinaus 
:-)

[Sigint 112 (sigint)]

Moin zusammen,
  hab mal mit dem Keyboard-Beispiel von CH55xDUINO rumgespielt. Dabei 
ist ein einfaches IO-Interface rausgekommen, welches das K8055 Protokoll 
nachahmt. Darüber hinaus habe ich noch mit WebHID rumgespielt, um das 
K8055 in P5.js nutzen zu können. Leider funktioniert das nur mit Chrome 
und Edge, da Firefox WebHID nicht unterstützen möchte.

Gruß,
  SIGINT

[Andreas M. (amesser)]

Ich habe heute relativ viel Zeit mit Fehlersuche bei meiner CDC 
Implementierung verbracht. Ich benutze den EP3 mit Double-Buffer 
Mechanismus. Dabei ist mir ein Problem aufgefallen: Wenn ich den Puffer 
bis zum Maximum von 64 Byte befülle und die Transmission freigebe, dann 
kommt auf der PC Seite nichts an und es geht nicht mehr weiter, der 
Transfer wird anscheinend nicht durchgeführt. Wenn ich nur bis 63 Byte 
befülle dann funktioniert alles wie erwartet. In der Empfangsrichtung 
geht es problemlos bis 64 Byte. Ich habe verschiedene Dinge ausprobiert 
um Fehler in meiner Implementierung auszuschließen. Falls jemand drüber 
schauen möchte, hier ist der Code, sobald man aus der 63 eine 64 macht 
gehts schief:

https://gitlab.com/amesser-group/electronic-devices/usb-updi-hv/-/blob/master/firmware/usb_cdc.c#L267

Ich bin da mit meinem Latein am Ende, hake das jetzt erstmal als 
Hardware-Fehler ab.

[Thomas Z. (usbman)]

Andreas M. schrieb:
> ch bin da mit meinem Latein am Ende, hake das jetzt erstmal als
> Hardware-Fehler ab.

das ist kein HW bug wenn du genau 64 Bytes sendest und hinterher nichts 
mehr kommt gibt es einen timeout. Bulk ist dazu gedacht fortwährend 64 
Byte Pakete zu übertragen.

In USB Terms
< 64 bytes sind Shorttransfer (automatisch terminiert)
= 64 Bytes braucht ein ZLP um das Ende zu erkennen
> 64 Bytes ist ein 64 Byte Transfer + Rest

Das war auch beim Code von W.S. lange ein Problem.

[Andreas M. (amesser)]

Thomas Z. schrieb:
> In USB Terms
> < 64 bytes sind Shorttransfer (automatisch terminiert)
> = 64 Bytes braucht ein ZLP um das Ende zu erkennen

Danke für die Rückmeldung. Wieder was gelernt - wobei ich ne schwache 
Ahnung im Kopf habe das schon mal gewusst zu haben. Mal sehen obs 
diesmal länger hängen bleibt. :-)

[Sigint 112 (sigint)]

https://hackaday.io/project/190886-diskmaster64

Hab was interesanntes gefunden :-)