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

[Monk (Gast)]

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 :-)

[Barzotto T. (barzottotec)]

Hello, I'm new here, sorry if I'm doing something wrong.
Recently I bought a Bios programmer from AliExpress that works with 
several NOR chips. It's called XP866+, it uses the CH552G, it works 
really fine, and the software is attached. I'm posting here so everyone 
knows that CH552G can work this way, and we can develop a better 
software or discover different usage for it.

I downloaded the android app "CH55x programmer v2 1.8" and tried to 
dump, but my device always "reset" after I accept the permission. I 
don't know if it's because of a 47 ohm resistor I added to Pin8 of the 
NOR chip (that I'm going to program with it) to reduce the voltage and 
to get exact 3.3v. I haven't done other modifications to the board, so 
if something else is required, please tell me.

The original XP866+ software is not ready to program NAND chips, and I 
don't know exactly how to add new chips to the database, being sure they 
will work well.

[Thomas Z. (usbman)]

Barzotto T. schrieb:
> that I'm going to program with it) to reduce the voltage and
> to get exact 3.3v. I haven't done other modifications to the board, so
> if something else is required, please tell me.

Please post a picture of the pcb. Firmware dumps just work for 
bootloader v1.1 and v2.31. You may check bcdVer field  of der Device 
Descriptor in bootloader mode. if you got 2.4 or 2.5 there is currently 
no way to dump it.

I am working on a HW sollution for dumping all the CH55x and CH54X chips 
but thats still not ready.

[Barzotto T. (barzottotec)]

I'm not familiar with CH552G, but as I mentioned, the device "Run" green 
LED blinks quickly and "reset" every time I accept the permission in my 
smartphone, I can't do anything in the app. If I can check it using 
Windows, tell me how.

There go front and back pictures with NOR pins identified.

[Thomas Z. (usbman)]

well in order to use the android software the WCH Chip has to enter the 
bootloader mode first.
For entering the bootloader you need to add a 4.7k .. 10k from D+ to 
VBus. You may use that 2 free pads for that. The resistor connection is 
tested only on power up and if found bootmode is entered. This also 
means for normal operation you have to remove it.

As mentioned dumping will work only for old chips (old loaders) LEDs are 
dont care here.

Anyway what are you planning to do with the dump? Any modification might 
need a lot of knowledge and you need to sniff the usb traffic of the 
original software. Such a thing is nothing for rookies

[Barzotto T. (barzottotec)]

I was planning to upload the dump here, so anyone with a CH552G flashed 
with my dump and the correct wiring could use it for the same purpose I 
currently use, that is NOR programming, to repair motherboards with 
corrupt bios.

This seems a lot better than CH341A (the most famous cheap NOR 
programmer), supporting newer models.

And maybe it's not required to modify the dump, but if someone wants to 
analyze the software I uploaded, it would be great to modify it to flash 
NANDs with it. There are versions of NeoProgrammer that can flash NAND 
with CH341A, I tested them and they work.

[Sigint 112 (sigint)]

I don't think it's worth the efford. Adding chips is just a matter of 
software because you only need a SPI or a I2C interface. Using the CH341 
is probably the easiest method.

[Thomas Z. (usbman)]

Für ein USB Host Projekt habe ich mir via Amazon ein Paar CH559T 
(SSOP20) beschafft. Beim Testen habe ich erst mal keine Verbindung zum 
Bootloader bekommen, die Teile stellten sich einfach tot.

Das sollte nicht passieren, da der Bootloader bei leerem Flash 
automatisch starten sollte. Das dachte ich zumindest bis heute :-) Nach 
einigen Tests habe ich dann P4.6(XI) auf Masse gelegt und siehe da der 
Loader hat sich gemeldet.

Es stellte sich heraus dass der Loader eine V2.0 Version ist. Der 
unterstützt weder Autostart bei leerem Flash noch das Aktivieren via D+. 
Beim Flashen mit dem WCH Tool kommt immer ein Verify Error im letzten 
Block. Das ist in Bug im ISP Tool und wird laut WCH nicht mehr gefixt da 
die V2.0 nicht mehr unterstützt wird. Man hat mir also uralte Teile 
angedreht. Es gibt also mindestens einen Händler der veraltete Chips 
verkauft.

Ich habe dann den Bootloader disassembliert und einige ungewöhnliche 
Dinge gefunden.
1. Der 2.0 Loader benutzt das V1.1 Kommando Interface.
2. Der Loader benutzt Interrupts (serial, usb, T0)
3. Es gibt tatsächlich keinen Test auf leeres Flash
4. Die Benutzung von D+ als Bootpin ist im Loader nicht vorgesehen

Lustig ist, dass der Loader Interrupts verwenden kann. Ich war bisher 
der Meinung dass nur der Reset Vector beim Power ON gemappt wird. 
Tatsächlich werden wohl auch die Interrupt Vektoren gemappt, sonst 
würden die Interrupts bei 0xF4xx ja nicht funktionieren. Da der Loader 
den ICALL unterstützt kann man ev das Ding auf V2.31 updaten.

[Thomas Z. (usbman)]

Hier ein kleines Projekt für die dunkle Jahreszeit:

Das soll ein usbASP Clone werden da ich immer mal wieder Probleme habe 
das Original an neuen USB Ports stabil ans laufen zu bekommen. 
Zuverlässig funktioniert das nur wenn ich einen Hub benutze. Ich vermute 
stark dass die USB Emulation auf dem Atmel Timming Probleme mit neuen 
USB Ports (USB3.2) hat.

Die Schaltung orientiert sich im wesentlichen am Original von Fischl. 
Die Versorgung kann zwischen 5V und 3.3V umgeschaltet werden.
Für die FW plane ich ich die Nutzung von WCID zur automatischen 
Treiberinstallation und später zusätzlich ein CDC Interface. Da AvrDude 
wohl Probleme mit Compound Devices hat, muss man das wohl umschaltbar 
machen.

Die Quellen lassen sich sowohl mit Keil als auch mit SDCC übersetzen und 
wird auch unter Projekte bereitgestellt werden. Die Sourcen sind 
weitgehend an den CH552 angepasst lediglich lediglich TPI braucht noch 
etwas Arbeit weil ich nicht so sattelfest in AVR Assembler bin. Das ist 
übrigens auch ein Grund für dieses Projekt. Ich will mich intensiver mit 
den AVRs beschäftigen.

Vorstellbar ist eine Nutzung auch als SPI bridge.

[Thomas Z. (usbman)]

Ich kann mich mit AVRDude schon mal auf den Controller verbinden. Lesen 
funktioniert schon. Schreiben hat noch ein paar bugs. Für SDCC muss ich 
noch ein paar defines anpassen.
Das CDC Interface wird erkannt funktioniert aber noch nicht weil der 
Code für die beiden Bulk Eps noch nicht eingebaut ist. Als Codebasis 
habe ich den code
von nerdralph genommen https://github.com/nerdralph/usbasp allerdings 
ohne die function pointer in spi.c weil das in Keil nicht so toll 
funktioniert.
usbdrv.c ist meine eigene Kreation. TPI ist noch abgeschaltet

Falls jemand testen will, ich kann ein paar Sticks verschenken. (quasi 
ein kleines Weihnachtsgeschenk :-) )

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

Travis Goodspeed hat den CH552 Flash dumper in seinem neuesten Buch 
"Microcontroller Exploits" erwähnt

[Thomas Z. (usbman)]

Aaron C. schrieb:
> Travis Goodspeed hat den CH552 Flash dumper in seinem neuesten Buch
> "Microcontroller Exploits" erwähnt

Da sieht man wie sich dank online Übersetzer sowas heute verbreitet. Ich 
glaube übrigens einen Weg gefunden zu haben auch beim V2.4 und v2.5 
Loader die Chips auszulesen. Das ist aber wesentlich aufwendiger. Das 
ist aber noch nicht fertig.

[Jim M. (turboj)]

Max M. schrieb:
> einen USB-Stick "vorgaukeln"

Wird eng mit nur 16KB Flash und 1KB XRAM.

USB Mass Storage basiert auf SCSI, da kommt einiges an Code zusammen bis 
das läuft. Geschwindigkeit ist egal, USB kann sich anpassen.

[Thomas Z. (usbman)]

so mein usbASP Klon funktioniert nun stabil. Lesen und schreiben ist ok.
Ich erreiche damit auf dem Arduino Uno bis zu 6.5kB/s 
Schreibgeschwindigkeit bei einem SPI Clk von 1.5 MHz. Das dürfte noch 
etwas besser werden wenn ich EP0_SIZE von 8 auf 64 ändere.  Keine Ahnung 
wie das auf dem Original war, da mein Fischl usbASP hier nur sehr 
unzuverlässig funktioniert.

Der Fehler beim Schreiben war simpel. Ich hatte den USB Data Toggle für 
Schreib Operationen nicht richtig programmiert. Es ist das erste Mal, 
dass ich Data out Stages mit mehreren Transfers benutze.

Ich tue mich noch etwas schwer mit dem TPI Modul. Da könnte ich Hilfe 
von einem AVR Programmierer brauchen. Für mich ist die 
Portprogrammierung mit den diversen Betriebsarten der Ports in AVR asm 
etwas undurchsichtig.

[Jochen D. (joe_d1)]

Hallo Thomas,

dein usbasp-Klon funktioniert prima:

Processing -U flash:w:MultiIO.hex:i
Reading 10694 bytes for flash from input file MultiIO.hex
Writing 10694 bytes to flash
Writing | ################################################## | 100% 1.93s
Reading | ################################################## | 100% 1.75s
10694 bytes of flash verified

Processing -U efuse:w:0xFF:m
Reading 1 byte for efuse from input file 0xFF
Writing 1 byte (0xFF) to efuse, 1 byte written, 1 verified

Processing -U hfuse:w:0xD9:m
Reading 1 byte for hfuse from input file 0xD9
Writing 1 byte (0xD9) to hfuse, 1 byte written, 1 verified

Processing -U lfuse:w:0xFF:m
Reading 1 byte for lfuse from input file 0xFF
Writing 1 byte (0xFF) to lfuse, 1 byte written, 1 verified

Avrdude done.  Thank you.

Und vor allem: Der ist total stabil selbst bei der Versorgung des 
Targets. Mein China usbasp-Klon fliegt ständig aus dem USB raus wenn ich 
ein mit dem usbasp-Klon versorgtes Target anstecke. Dein Klon macht da 
keinen Mucks!

[Thomas Z. (usbman)]

Jochen D. schrieb:
> dein usbasp-Klon funktioniert prima:

danke für deine Rückmeldung. Ich hätte noch ein paar Fragen:
- Welche Version von avrdude benutzt du?
- Welche Atmel Controller hast du geflasht?
- Hat es bei dir sofort funktioniert (ohne Treiber Install)

[Jochen D. (joe_d1)]

> - Welche Version von avrdude benutzt du?

avrdude 8.0

> - Welche Atmel Controller hast du geflasht?

Atmega324PB

> - Hat es bei dir sofort funktioniert (ohne Treiber Install)

Jain. Habe meine Software aber auch in einer VirtualBox. Da wurde der 
Programmer zuerst nicht erkannt. Schiebe das aber auf die VirtualBox ;)

Treiber waren vom China-usbAsp-Klon schon vorher installiert.

[Thomas Z. (usbman)]

Thomas Z. schrieb:
> Ich tue mich noch etwas schwer mit dem TPI Modul

So das tpi modul ist nach c umgesetzt. Testen kann ich das im Moment 
nicht, da ich keinen passenden AVR habe. Zumindest das Frame Format 
scheint aber in der Simulation zu passen. Insgesamt komme ich beim Keil 
auf etwas weniger als 4Kb in der höchsten Stufe (9. Common Block 
Subroutines) ca 3.5kB.

Meine Usb Irq Funktion ist ziemlich viel code wegen der ganzen 
Fallunterscheidungen. Der SDCC braucht mehrere sec zum Übersetzender, 
der mag wohl längere Quelltexte nicht. Ich bekomme die USB Funktionen 
nur mit EP0_SIZE=8 mit avrdude ans Laufen. Ob das an meinem usbdrv.c 
liegt oder eine Einschränkung von avrdude ist, kann ich noch nicht 
sagen.

Im Anhang mal tpi.c und usbdrv.c. Nächste Woche gibts das komplette 
Projekt. Die (zusätzlichen) Klammern bei den case xxx sind nur wegen dem 
code folding Editor drin.

[Thomas Z. (usbman)]

ich habe das Projekt mal auf Github eingestellt.

https://github.com/usbman01/CH552_usbASP

[Thomas Z. (usbman)]

Ich habe heute den SDCC support vervollständigt (Build per Batch Datei) 
Mit make komme ich leider immer noch nicht klar :-(.

Wie erwartet ist der code ca 25% gößer als bei Keil 4000 bytes versus 
5000 bytes. Im schlechtesten Fall sind es sogar fast 40%. (OT9, CDC aus 
WCID und TPI ein).

[Tom A. (toma)]

Hallo Thomas.

Ich arbeite gerade an einer Entwicklungsumgebung für MCS51 unter Linux 
(Bild is51b.png). Darin werden Einzeldateien direkt übersetzt 
(compiliert/assembliert), Projekte aus mehreren Dateien und das 
aufräumen mit "Clean" übernimmt ein Makefile. Dieses ist im Anhang 
"is51.mak zu finden.

Aufruf zum übersetzen:
   "make -f is51.mak FNM=Dateipfad ohne Extend"

Aufruf zum aufräumen:
   "make clean -f is51.mak FNM=Dateipfad ohne Extend"

Vielleicht hilft Dir das Beispiel etwas weiter bei Makefiles.

Gruss Tom

[Tom A. (toma)]

Habe noch ein Beispiel vergessen:

    make -f is51.mak FNM=/home/SDCCprogs/Test

Übersetzt die Datei/das Projekt "Test" im Pfad "/home/SDCCprogs/".
Das kann Test.c oder auch Test.asd (asd = Assembler für SDcc) sein.

[Thomas Z. (usbman)]

Tom A. schrieb:
> Habe noch ein Beispiel vergessen

danke für das make file und die Beispiele. Das passt bei mir so nicht 
weil ich überall relative pfade habe, und die Ausgabe gerne in 
getrennten Ordner ablege. Soweit ich das verstanden habe hat make mit 
einer solchen Struktur Probleme. Ich müsste mir also mein Strings 
zusammenbasteln. Es ist nicht so, dass ich gar keine Ahnung von make 
habe...
Ich bab das bisher immer auf die lange Bank geschoben und halt passende 
Batch Files geschrieben. Normale makes gehen ja davon aus dass alles in 
einem Ordner liegt.

[Tom A. (toma)]

Man könnte auch nur den Dateinamen übergeben und die Pfade innerhalb des 
Makefiles zuordnen. Damit habe ich mich aber noch nicht beschäftigt, da 
ich meine Projekte jeweils in eigenen Verzeichnissen verwalte.

Wie auch immer, Hauptsache am Ende kommt das Gewünschte dabei raus.

Gruss. Tom

[Christian E. (ceck)]

Guten Tag,

seit kurzem habe ich mir CH559L chips geholt.
Beim flashen über USB tritt bei mir allerdings das Problem auf, dass die 
Programmierung meistens fehlschlägt - sowohl beim WCHISPTOOL, als auch 
beim chflasher.
Beim debuggen mit dem chflasher ergibt sich, dass die Übertragung nach 
verschieden vielen Transfers beim flashen oder verifizieren einen 
timeout error aufwirft. Ab und zu ist er schon vornherein nicht 
erreichbar, obwohl er hier ( 
https://www.uwe-sieber.de/usbtreeview_e.html#download ) aufgelistet 
wird. Danach ist der chip, bis man ihn resetted, nicht mehr erreichbar.
Mit dem WCHISPTOOL wird Ähnliches erkennbar.

Irgendwann bin ich dann auf diesen Thread gestoßen und hoffe, dass ihr 
mir weiterhelfen könnt? Habt ihr ähnliche Probleme?

Noch ein paar Gedanken/Informationen:
- Bootloader-Version: 2.40
- ~ Bootloader kann mit Fehlern bei der USB-Übertragung nicht umgehen
- ~ höhere Fehlerquote durch langes Kabel?
- ~ Flash-Speicher ausgenutzt, sodass das Schreiben fehlschlägt
  (die chips sind neu, aber ich weiß nicht, ob sie vorher schon benutzt 
wurden(https://de.aliexpress.com/item/1005004508033849.html))

[Thomas Z. (usbman)]

Christian E. schrieb:
> - Bootloader-Version: 2.40

die V2.4 dürfte das Problem sein. Ab Version 2.4 stellt sich der Chip 
nach dem ersten fehlgeschlagenen Verify tot. Das haben die eingebaut 
damit unser Dumper  nicht mehr funktioniert.
Ich kenne den CH Flasher nicht im Detail, aber da ist vermutlich noch 
ein Bug drin was das Verify angeht. Ich weis definitiv dass das 
WCHIspTool manchmal beim letzten zu flashenden Block einen Verify Error 
wirft.
-> Beitrag "Re: uC für 0,20€ CH552 / CH554 von WCH Billig Micro mit USB Funktion, Chip vorstellung"

Konvertiere dein hex mal nach bin und probier nochmal das WCH ISP Tool. 
Je nachdem wie dein Hex aussieht könnte das die Ursache sein.

[Christian E. (ceck)]

Thomas Z. schrieb:
> die V2.4 dürfte das Problem sein. Ab Version 2.4 stellt sich der Chip
> nach dem ersten fehlgeschlagenen Verify tot. Das haben die eingebaut
> damit unser Dumper  nicht mehr funktioniert.

das macht sinn, aber wieso stellt der chip sich schon beim programmieren 
tot?
und wieso wieso wird er beim chflasher und WCHISPTOOL manchmal 
garnicht erst aufgelistet, obwohl er bei Windows 
(https://www.uwe-sieber.de/usbtreeview_e.html#download) immer 
aufgelistet wird? - werden die USB descriptor neu angefragt?

Thomas Z. schrieb:
> Konvertiere dein hex mal nach bin und probier nochmal das WCH ISP Tool.
> Je nachdem wie dein Hex aussieht könnte das die Ursache sein.

Das schließe ich aus. Ich habe mehrere Programme ausprobiert, die 
jeweils oft fehlgeschlagen sind, aber dann irgendwann erfolgreich 
geflasht wurden.
Jedoch schlägt das flashen immer öfter fehl.

wie ist das eigentlich mit dem Bootloader - ist er mit *P4.6(XI)* 
standartmäßig immer erreichbar, oder muss man immer im Programmcode den 
Bootloader aufrufen (LJMP BOOT_LOAD_ADDR / LCALL BOOT_LOAD_ADDR)?
- Ich will mich nicht softlocken.

[Thomas Z. (usbman)]

Christian E. schrieb:
> wie ist das eigentlich mit dem Bootloader - ist er mit *P4.6(XI)*
> standartmäßig immer erreichbar, oder muss man immer im Programmcode den
> Bootloader aufrufen (LJMP BOOT_LOAD_ADDR / LCALL BOOT_LOAD_ADDR)?
> - Ich will mich nicht softlocken.

Der Bootloader kann immer mit P4.6 bzw P5.1 gestartet werden. Allerdings 
werden diese Pins nur beim Powerup abgefragt, nicht beim Reset. Das ist 
übrigens auch der einzige offizielle Weg. Der LCALL 0xF400 funktioniert 
inoffiziell auch du solltest aber darauf achten vor dem JMP T0/T1 zu 
sperren und IE = 0 setzen.

Das ist nicht das gleiche wie der Start per POR Event!

Beim Start per LCALL /LJMP 0xF400 kannst du die Config Bits (Download 
Config im ISP Tool) nicht verändern.

Ob das alles wirklich so stimmt kann ich nicht sagen weil ich noch nie 
die v2.4 für den CH559 hier hatte und deshalb auch nicht disassembliert 
habe.

Übrigens bei neueren Controllern (CH548/9) funktioniert der LCALL in den 
Bootloader sowieso nicht, da geht nur noch der Weg über POR.

Der Bootloader ist schreibgeschützt denn kannst du nicht kaputt machen

[Christian E. (ceck)]

Thomas Z. schrieb:
> ..., weil ich noch nie
> die v2.4 für den CH559 hier hatte und deshalb auch nicht disassembliert
> habe.

Ich habe mal meinen CH559L (Bootloader V2.40) gedumpt und
hier angehongen, wenn das jemand braucht.
Nur meinen Code habe ich gelöscht, der Bootloader startet ja bei 
0xF400.


@Thomas Z., danke übrigends für deine schnellen Antworten, das hat mir 
weitergeholfen.

[Thomas Z. (usbman)]

Christian E. schrieb:
> Ich habe mal meinen CH559L (Bootloader V2.40) gedumpt und
> hier angehongen, wenn das jemand braucht.

ich hab mir das mal angeschaut. Der Code entspricht im wesentlichen dem 
2.31 mit den Erweiterungen für das VerifyErr bit. Es wurde die 
Überprüfung auf IAP(ICall) aus der Main Schleife rausgenommen. Der Rest 
ist ziemlich unverändert. Der TimeOut über T0 wird abgeschaltet sobald 
die Software das ID Cmd schickt.
Reihenfolge der Variablen ist identisch. Bei den Bit Vars gibts Dreher.

[Thomas Z. (usbman)]

ich hab mal das zurückübersetzte main() der v2.4 angehängt