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

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

Max M. schrieb:
> 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?

Moin, ja das geht und gibt es auch schon als fertiges beispiel.

habe es auch einmal ausgetestet mit einem spi flash und es funktionierte 
wie du beschreibst.

versuche das zu finden

[Thomas Z. (usbman)]

Max M. schrieb:
> 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?

Nein das geht nicht es sei denn du findest eine Möglichkeit irgendwie 
den Hostmode zu aktivieren indem du aus dem CH552 einen CH554 machst. 
Wie Richie ja gezeigt hat benutzen beide das gleiche Die.
Ansonsten brauchst du zwingend einen CH554. Dann ist es kein Problem. 
Irgendwann werde ich meinen UDisk Code auf den CH554 portieren.

Max M. schrieb:
> 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.

versteh ich nicht. Wenn der CH55x MSD Host spielt hast du doch gar keine 
Verbindung zu Windows. Der Host bestimmt die Geschwindigkeit.

Thomas

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

@Thomas Z. ich denke er meint den CH552 als slave zu einem PC als USB 
Stick

[Max M. (maxmicr)]

Danke euch!

Aaron C. schrieb:
> ich denke er meint den CH552 als slave zu einem PC als USB
> Stick

Ja genau, so meinte ich das. Sorry, war anscheinend etwas unverständlich 
ausgedrückt.

[Thomas Z. (usbman)]

Ja das hab ich wohl falsch verstanden. Ein MSD Device geht problemlos. 
Dazu muss auf dem SPI Flash ein MBR drauf sein und eine Partition. Dann 
kann man darauf schreiben und der Speicher sollte auch als Memory Stick 
erkannt werden. Es braucht dann zumindest ein rudimentäres Filesystem 
mit Support für del, write und dir Support.

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

Anbei das Beispiel.

Schaltplan ist quasi mit dabei.

[Thomas Z. (usbman)]

Empfehlenswert ist ev ein Fat16 system ev sogar FAT12. Die Frage ist für 
was? Der CH552 hat nur 14k Code Speicher. Mehr als ein digitaler 
Bilderrahmen der Bilder aus dem SPI Flash auf ein Display bringt wird 
wohl nicht drin sein.
Der offline programmer von WCH benutzt glaube ich sowas um das zu 
flashende File in einem SPI Flash bereitzustellen.

[Max M. (maxmicr)]

Thomas Z. schrieb:
> Mehr als ein digitaler
> Bilderrahmen der Bilder aus dem SPI Flash auf ein Display bringt wird
> wohl nicht drin sein.

Muss ja auch nicht.

Ich habe vor ein Programmiergerät für einen anderen Microcontroller zu 
bauen. Man kann dann einfach die kompilierte .hex-Datei von Windows / 
Linux aus in den "USB-Stick" kopieren. Der CH551 streamt das dann in den 
SPI-Flash und programmiert hinterher den anderen Microcontroller. Das 
ermöglicht sogar eine Standalone-Funktionalität da der SPI-Flash 
natürlich nicht flüchtig ist.

Soweit der Plan.

[Thomas Z. (usbman)]

OK dafür reicht auch schon ein CH551. Ich hab für den  umgekehrten Fall 
CH559 als Host für einen Memory Stick im besten Fall 4kB gebraucht. 
(UDisk) Dein MSD Code sollte dicke in 8KByte passen dann hast du immer 
noch 4kB für den Programmer.

Zu deiner Eingangsfrage wegen der Geschwindigkeit:
Das ist kein Problem du bekommst von Win via BulkOnly Protokoll immer 
einen 512B Sektor. Da der Chip nur USB1.1 kann sind das dann 8 Bulk 
Transfers a 64 Bytes die du auf das SPI Flash schiebst. Wenn die Daten 
gespeichert sind, nimmst du einfach den NAK weg und der nächste 
Bulktransfer wird von Win initiiert. Wenn du den CPU Takt auf 24 MHz 
stellst kannst du einen SPI Takt bis 12 MHz verwenden.
Es ist vermutlich sinnvoll das SPI Flash mit dem Image z.B einer leeren 
Diskette einmalig zu initialisieren. Nicht vorhandene Sektoren werden in 
der FAT einfach als defekt markiert
Nachteil ist dann dass du dich mit FAT12 beschäftigen musst, aber da 
gibt's ja genügend Beispiele. Der FAT Code ist halt etwas hässlicher. 
LFN brauchst du vermutlich nicht 8.3 Filenamen werden reichen.

[Thomas Z. (usbman)]

Die Suppe versalzen kann dir natürlich die Blockgröße des SPI Flashs. Je 
die Blockgröße ist desto komplizierter wird es. Ein rudimentären 
Flashfile System wirst du brauchen. Ich hab das vor Jahren mal mit einem 
29F40 gemacht der eine 360k Diskette emulierte.

[Thomas Z. (usbman)]

Ich habe mich mit der Portierung meines UDisk Codes nach IAR 
beschäftigt. Das funktioniert soweit ich kann's bloss nicht abschließend 
testen da ich nur die Demo habe. Die einzelnen Dateien kann ich aber 
kompilieren.

Dann hab ich mir nochmal den MicroC Pro Compiler angeschaut. Das Ding 
ist der Hammer die übersetzen doch tatsächlich unsigned short in einen 
8Bit Typ also gleich wie unsigned char. So einen Mist hab ich noch nie 
gesehen. Ich hab das dann mal auch für deren AVR Compiler nachgeschaut 
dort ist es genauso.

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

Habe nun auch etwas beizutragen.

Habe gestern eine Arduino USB HID interface Library fertiggestellt.

https://github.com/atc1441/CH_HID_Arduino

Damit ist es möglich den CH554, CH552 oder CH551 als USB Maus und 
Tastatur zu verwenden und über einen beliebigen Arduino / Seriellen 
Micro zu steuern.

Der CH55x code ist komplett in der Arduino IDE entwickelt und liegt bei 
/ wird darüber geflasht.

[Thomas Z. (usbman)]

Aaron C. schrieb:
> Der CH55x code ist komplett in der Arduino IDE entwickelt und liegt bei
> / wird darüber geflasht.

feine Sache das Ganze. Mich stört etwas die libusb Geschichte. Damit 
verliert man die Möglichkeit das WCH isptool zu benutzen.
Wenn ich dich richtig verstanden habe wird das ja nur für den Bootloader 
benutzt. Wäre da nicht sinnvoller die WCH dll zu benutzen und einen 
Wrapper für die Loader Funktionen zu schreiben? Die DLL Export 
Funktionen sind ja mittlerweile bei WCH öffentlich verfügbar.

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

Das stört mich selber leider auch etwas und ist wirklich nur für den 
Bootloader, habe viele andere variationen über direkten windows USB 
zugriff usw. Leider ginz nichts ohne extra treiber.

Es ging dabei darum es komplett ohne closed source auszukommen.

Auch wenn es etwas aufwand ist kann man den treiber wieder 
deinstallieren und WCHispTool nutzen.

[Thomas Z. (usbman)]

Das stimmt schon insbesondere wenn das Teil auch mal unter Linux 
verfügbar sein wird. USB bedeutet dass immer ein Treiber im System sein 
muss.
Dieser kommt ja automatisch mit wenn man das WCHIsptool installiert wird 
und wird mit der DLL in den Usermode gewrappt. Ist natürlich kein Open 
Source da WCH keine Lizenzen in den Sourcen hat.
Erinnert mich an meine Experimente mit den Loadern. Ich hatte ja anfangs 
auch mit custom Loadern und libusb gearbeitet damit die WCH vid/pid 
unangetastet bleibt. Man verliert halt dabei nochmal 2kb Flash Speicher

[Thomas Z. (usbman)]

Wie ihr vermutlich gesehen habt, habe ich mich mit der Portierung von 
udisc nach IAR beschäftigt. Das passt soweit und ich konnte diese Woche 
den code mit einem lizensierten Compiler testweise übersetzen. Mehr dazu 
wenn ich die binaries auch getestet habe.

Mir ist durch die Portierungen die Idee gekommen die CPU Headerfiles zu 
vereinheitlichen, so dass der Compiler keine Rolle mehr spielt.

Ein unvollständiger und ungetestetes Beispiel im Anhang. Was denkt ihr? 
Sinnvoll  oder eher weniger sinnvoll?

Dieses File würde ich dann für alle MCUs anlegen. Noch habe ich keine 
sinnvolle Idee wie man IAR da unterbringen kann. Die Header würden dann 
einfach ein compiler.h includieren welches die Compiler spez. marcos 
baut.

Thomas

[Thomas Z. (usbman)]

Ich hab jetzt den IAR Support für UDisk fertig gestellt. Das Header File 
ist jetzt wie oben angedeutet umgestellt.
Am Source waren nur minimale Änderungen notwendig. In der Hauptsache war 
das idata Variablen in Funktionen (Auto Variablen) IAR kann das nicht.

Da es dann zu Speichermangel auch bei SDCC kommt muss der Debug Target 
dort dann mit --stack-auto übersetzt werden.
Des weiteren ist in Main eine Dummy Initialisierung der xdata Puffer 
notwendig. Ohne diese wurden die Puffer immer rausgenommen und der 
linker hat sie nicht mehr gefunden.

Keil und IAR sind im wesentlichen gleichwertig was die Code Größe 
angeht. IAR in diesem Fall etwas schlechter, was vermutlich auf das 
Lowlevel ASM Modul in Keil zurückzuführen ist.
Die Projekt Dateien sind extra gezipt um das Wurzelverzeichnis 
übersichtlich zu halten. Die anderen in compiler.h aufgeführten 
Übersetzer sind nicht geprüft.

[Thomas R. (r3tr0)]

Aaron C. schrieb:
> Habe nun auch etwas beizutragen.
>
> Habe gestern eine Arduino USB HID interface Library fertiggestellt.
>
> https://github.com/atc1441/CH_HID_Arduino
>
> Damit ist es möglich den CH554, CH552 oder CH551 als USB Maus und
> Tastatur zu verwenden und über einen beliebigen Arduino / Seriellen
> Micro zu steuern.
>
> Der CH55x code ist komplett in der Arduino IDE entwickelt und liegt bei
> / wird darüber geflasht.

Das sieht ja schon einmal genial aus! Jetzt bin ich auch mal am 
überlegen, ob ich mir ne kleine Platine bastel um als HID-Device den PC 
zu steuern.

Nur bräuchte ich evtl kurz deine Hilfe. Wie werden denn in diesem Fall 
die HID-Befehle zusammen gestellt?
In deiner CH_HID_Arduino.h hast du z.B. KEY_ESC als 0xB1 definiert.
Ich würde mir das Ganze noch einmal ein bisschen erweitern, damit ich 
Volume Up und Volume Down damit versenden könnte. Hier habe ich jetzt 
eine Tabelle gefunden mit den Scanncodes, jedoch stimmen diese nicht 
wirklich mit deinen überein. Könntest du mir helfen, wo ich die 
richtigen Codes dafür finde, damit ich mir das Ganze ein bisschen 
erweitern könnte? :)

Grüße

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

Moin,

die definition der Keys setzt sich aus dem HID Keyboard descriptor 
zusammen, dieser ist im falle vom dem CH552 hier: 
https://github.com/atc1441/CH_HID_Arduino/blob/master/examples/CH552_Interface/usb.c#L39

Man kann den descriptor hier parsen um ihn zu lesen: 
https://eleccelerator.com/usbdescreqparser/

Dort wirst du sehen dass keine medien keys definiert sind.


Um medien key zu unterstützen benötigt man einen anderen descriptor, 
auch must du den USB CFG descriptor dementsprechend anpassen. siehe 
hier: 
https://www.stefanjones.ca/blog/arduino-leonardo-remote-multimedia-keys/

Die Arduino seite von dieser library ist stark and die Leonardo library 
angelehnt deswegen wirst du viel wiederfinden.

[HID Hilfe (Gast)]

Hi,
ich habe gerade einen CH552 mit dem Blink Beispiel zum laufen gebracht.
Vielen Dank für die Arduino Integration!

Leider klappt das HID Beispiel aus der Library nicht, vielleicht hat 
jemand einen Tipp für mich?

C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/bin/sdcc -c -V -mmcs51 --model-large --xram-size 0x0400 --xram-loc 0x0100 --code-size 0x3800 -DMCUch552 -DFREQ_SYS=24000000L -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\cores\ch55x -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\variants\standard -IC:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/include C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\CH_HID_Arduino.cpp -o C:\Users\Benutzer\AppData\Local\Temp\arduino_build_824754\preproc\ctags_target_for_gcc_minus_e.cpp
cpp gefunden
C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/bin/sdcc -c -V -mmcs51 --model-large --xram-size 0x0400 --xram-loc 0x0100 --code-size 0x3800 -DMCUch552 -DFREQ_SYS=24000000L -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\cores\ch55x -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\variants\standard -IC:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/include C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\CH_HID_Arduino.c
+ C:\Users\Benutzer\DOWNLO~1\ARDUIN~3.5_S\portable\packages\CH55XD~1\hardware\ch55x/0170E4~1.0/sdcc/bin\sdcpp.exe -nostdinc -Wall -std=c11 -D"MCUch552" -D"FREQ_SYS=24000000L" -I"C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\cores\ch55x" -I"C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\variants\standard" -I"C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src" -I"C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/include" -obj-ext=.rel -D__SDCC_CHAR_UNSIGNED -D__SDCC_MODEL_LARGE -D__SDCC_FLOAT_REENT -D__SDCC=4_0_2 -D__SDCC_VERSION_MAJOR=4 -D__SDCC_VERSION_MINOR=0 -D__SDCC_VERSION_PATCH=2 -DSDCC=402 -D__SDCC_REVISION=11616 -D__SDCC_mcs51 -D__STDC_NO_COMPLEX__=1 -D__STDC_NO_THREADS__=1 -D__STDC_NO_ATOMICS__=1 -D__STDC_NO_VLA__=1 -D__STDC_ISO_10646__=201409L -D__STDC_UTF_16__=1 -D__STDC_UTF_32__=1 -isystem "C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/bin\..\include\mcs51" -isystem "C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/bin\..\include"  "C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\CH_HID_Arduino.c" 

sdcpp.exe: fatal error: when writing output to : Invalid argument

C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\/CH_HID_Arduino.h:32: error 1: Syntax error, declaration ignored at 'class'

C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\/CH_HID_Arduino.h:32: syntax error: token -> 'CH_HID_' ; column 13

C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\/CH_HID_Arduino.h:36: error 1: Syntax error, declaration ignored at 'Stream'

C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\/CH_HID_Arduino.h:37: error 1: Syntax error, declaration ignored at 'public'

C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\/CH_HID_Arduino.h:43: syntax error: token -> '}' ; column 1

cp:: No such file or directory
Bibliothek CH_HID_Arduino in Version 1.0.0 im Ordner: C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino  wird verwendet
exit status 1
Fehler beim Kompilieren für das Board CH552.

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

Moin, das Example selber ist für den echten Arduino angedacht,

der code für den CH552 ist das Interface beispiel.

hoffe das ist verständlich

[HID Hilfe (Gast)]

Danke für die Info, das konnte ich flashen :). Was genau macht 
sendAckMSG? Einen Buchstaben per HID Keyboard senden?
Aktuell passiert nichts wenn ich auf die Touch Tasten drücke.
Danke

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

sendAckMSG sendet eine nachricht per Uart an den angeschlossenen Arduino

[HID Hilfe (Gast)]

ok, besteht dann auch die Möglichkeit als Tastatur zu agieren oder ist 
das aktuell nicht möglich ?

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

Dafür wird in dem code der Arduino genutzt. Der CH552 ist als Maus und 
Keyboard interface gedacht.

[HID Hilfe (Gast)]

Also der Arduino sendet per UART die Buchstaben, die der CH552 dann per 
USB "Tippen" soll?

[HID Hilfe (Gast)]

Habe mal etwas mit dem Code gespielt, sollte das so funktionieren? Wenn 
ich auf eine der Touch Tasten drücke soll "test" getippt werden.

#include "intTemp.h"
#include "time.h"
#include "usb.h"
#include "touchinput.h"
#include "uart.h"
#include "bootloader.h"

uint32_t last;
uint8_t HIDKey1[4];
#define LED_PIN1 7 // Pin7
SBIT(LED1, 0x90, LED_PIN1); // Port1

void setup()
{
  init_freq();
  init_usb();
  init_touch();
  init_millis();
  init_uart();
  EA  = 1;// Enable Interrupts
  delay(250);
  sendAckMSG('B');
}

void loop() {
   if ((millis() - last) > 40) {
    last = millis();
    LED1 = !LED1;
  }
 if ( Touch_IN != 0 )
  {
    if ( Touch_IN & CH2 )jump_to_bootloader();
    if ( Touch_IN & CH3 )sendAckMSG('t');
    Touch_IN = 0;
     HIDKey1[0] = 't';
     HIDKey1[1] = 'e';
     HIDKey1[2] = 's';
     HIDKey1[3] = 't';          
     send_Keyboard_data_to_usb();
  }

  processUSB();
  processUart();
}

[Peter (Gast)]

I have had success with ch55x

[8051 Guy (Gast)]

Foer those of you that like to play with Chinese 8051, A more complete 
kid available take a look

http://www.sinowealth.com:8088/ftp//8051%20mcu/8bit%20flash%20mcu/ss450b_sh88f6161_6162/SH88F6161_6162%20V2.2.pdf

[Max M. (maxmicr)]

Peter schrieb:
> I have had success with ch55x

What does it do?

[Thomas Z. (usbman)]

Ich habe mich nochmal näher mit dem Config Bereich des CH552 
beschäftigt. Ich hatte da ja letztes Jahr schon ein paar Experimente 
gemacht. Im Anhang ein Programm um die Bits zu kontrollieren. Dabei ist 
das Bit zum sperren des Bootloaders aus Sicherheitsgründen gesperrt. Das 
Programm setzt momentan v1.1 Loader vorraus.

Ich habe einen Controller geopfert um das Verhalten der Bits zu testen. 
Wie erwartet ist nach dem Löschen des Bits 14 kein Bootloader Start mehr 
möglich ein manueller Aufruf funktioniert immer noch. Man kann danach 
auch nicht mehr die Bits ändern weil im GLOBAL_CFG das Bit gelöscht ist.

Lt Datenblatt ist das Bit bBOOT_LOAD readonly tatsächlich kann ich das 
Bit aber wieder setzen zumindest funktioniert das bei deaktivierten 
Bootloader.

Das Verhalten ist ein Weg wie man einen v2.31 Loader tauschen kann.
Thomas

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

Schön zu sehen das noch bewegung drin ist :)


Es gibt einen neuen Bootloader V2.40

Geflasht wird dieser gleich der V2.31 werde ihn bei gelegenheit 
auslesen, habe davon auch ein paar hier.


Leider werden auf Aliexpress CH552G varianten ohne vorgeflashten 
bootloader verkauft.

Ich wurde angeschrieben weil der Chip nicht erkannt wurde an usb und ich 
habe davon nun auch einen vorliegen.

Ich denke wenn man die ISP Programmierung reversed dann sollte man jeden 
beliebigen Bootloader flashen können und das würde ich soweit als ziel 
ansetzen.

[Thomas Z. (usbman)]

Aaron C. schrieb:
> Ich denke wenn man die ISP Programmierung reversed dann sollte man jeden
> beliebigen Bootloader flashen können und das würde ich soweit als ziel
> ansetzen.
Ja mit meinem Tool kann man ja Bit 15 manipulieren. Das wäre der erste 
Schritt um ISP freizuschalten. Leider wird das Bit vom WCH Tool bei 
jedem Flashen gelöscht.

WCH weigert sich ja konsequent zu ISP irgendwas zu veröffentlichen. Ich 
kann mir übrigens nicht vorstellen dass die Teile ohne Loader geliefert 
werden, vielmehr glaube ich dass der Loader einfach deaktiviert ist, was 
im Ergebnis aber das gleiche ist wenn man kein Programm auf dem 
Controller hat um den Bootloader manuell zu starten.

Zu v2.4 das ist vermutlich die Antwort auf eine Email von mir. Ich hatte 
WCH letztes Jahr auf die Sicherheitslücken im Loader aufmerksam gemacht. 
Wenn die das richtig gemacht haben funktioniert das bisherige Verfahren 
wahrscheinlich nicht mehr.

Mir stellt sich nun die Frage ob es noch mehr readonly Bits gibt die 
sich unter bestimmten Umständen doch beschreiben lassen. Ich denke da 
speziell daran aus einem ch552 einen ch554 zu machen das Die ist ja 
immer gleich.

Thomas

[Thomas Z. (usbman)]

Ich hab jetzt noch ein paar Tests gemacht...
Bit bBOOT_LOAD ist tatsächlich readonly solange der Bootloader nicht 
deaktiviert ist.

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

Habe nun auch einmal versucht den 2.40 zu dumpen und es hat nicht 
funktioniert, schade! das machte produkte mit dem CH eigentlich sehr 
interessant

Mit dem normalen dump tool/V2.30 Bootloader emulator sollte es ja 
weiterhin kein problem sein den bootloader selber zu dumpen dann kann 
man einmal vergleichen was genau geändert wurde

[Thomas Z. (usbman)]

Aaron C. schrieb:
> Habe nun auch einmal versucht den 2.40 zu dumpen und es hat nicht
> funktioniert, schade!

Das hatte ich so auch erwartet. Die haben dazugelernt. Wenn du meinen 
Fake Loader nach 0x3000 installierst und den startest sollte alles wie 
gehabt funktionieren. Alternativ halt ein Programm schreiben was den 
Loader über die ser. Schnittstelle ausgibt.

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

Anbei einmal den gedumpten V2.40 Bootloader

[Thomas Z. (usbman)]

Zeit für eine kleine IDA Session. Der Dump ist gut die Versions Info hab 
ich schon. Das Ding ist bis auf wenige Ausnahmen identisch zum 2.31 nur 
etwas länger.

[Thomas Z. (usbman)]

Aaron C. schrieb:
> Leider werden auf Aliexpress CH552G varianten ohne vorgeflashten
> bootloader verkauft.

mir ist gerade noch was eingefallen. Beim V2.31 und wie ich gerade 
gesehen habe beim V2.40 Loader kann die HW Aktivierung anstelle mit D+ 
auch mit P3.6 gemacht werden das ist lt WCHIsptool sogar der Default. 
Das könnte das Problem mit den Chips von Ali sein.

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

Thomas Z. schrieb:
> Aaron C. schrieb:
>> Leider werden auf Aliexpress CH552G varianten ohne vorgeflashten
>> bootloader verkauft.
>
> mir ist gerade noch was eingefallen. Beim V2.31 und wie ich gerade
> gesehen habe beim V2.40 Loader kann die HW Aktivierung anstelle mit D+
> auch mit P3.6 gemacht werden das ist lt WCHIsptool sogar der Default.
> Das könnte das Problem mit den Chips von Ali sein.

Oh danke richtig. Das teste ich !


EDIT.... Mhhh P3.6 ist USB DP :D


aber teste den P1.5 zur sicherheit einmal

[Thomas Z. (usbman)]

Mist verwechselt....

[Thomas Z. (usbman)]

Ich hab mir jetzt den Code näher angesehen. Mir sind bis jetzt nur 
wenige Änderungen aufgefallen. Die wichtigste Änderung ist dass beim 
Verify nun nur noch Addresse < 0x3800 erlaubt sind. Dann gibt es eine 
kleine Änderung im Startup Code und in Main fehlt der Timeout um den 
Softreset zu starten.
Ansonsten ist alles gleich, selbst die Variablen Belegung hat sich nicht 
geändert. Der Bug beim USB Setupcode ist immer noch drin.

[Thomas Z. (usbman)]

Die Verify Funktion kann nicht mehr zum Auslesen benutzt werden da der 
Bytewalk nicht mehr funktioniert.
Das Lowbyte der Addresse muss ein Vielfaches von 8 sein, was in der 
Konzequenz bedeutet dass man für 8 Bytes 2^64 Kombinationen testen 
müsste. Das ist praktisch nicht zu schaffen. Das haben die gut gemacht 
ich sehe keinen Weg das zu knacken.

Das einzige was man ev noch finden kann sind leere Bereiche indem man 
auf 0x00 oder 0xFF testet.

Ohne SPI Reader geht da nichts mehr. Als einziger Weg bleibt wohl nur 
ein deaktivierten SPI readout Schutz.

Thomas

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

Ok schade,

denke die möglichkeit des freien flash suchen könnte man für ein dumper 
ausnutzen da ist aber auch irgendwann schluss weil vor dem schreiben ja 
eh ein erase gemacht werden muss.

[Thomas Z. (usbman)]

Ich werde irgendwann nächte Woche den Loader hier einstellen. Momentan 
taste ich mich ausgehend von V2.31 per bin Vergleich vor. Etwa die 
Hälfte hab ich schon. Das hat den Vorteil dass so alle Änderungen schön 
sichtbar werden. Ich werde die Stellen  im Source dann mit v2.4 
kennzeichnen.

[Thomas Z. (usbman)]

Hier nun der Sourcecode für die v2.40. Da ich den Code von der v2.31 
abgeleitet habe sind alle bisherigen Kommentare drin geblieben. Als 
Besonderheit kann man zwischen v2.31 und v2.40 umschalten. Wenn die 
Startadresse auf 0x3800 steht ist der Code binärgleich zu den jeweiligen 
Originalen von WCH.
Zum übersetzen ist Keil notwendig die freie Version reicht. Das Header 
File mit den SFRs ist weiter oben zu finden.

[Thomas Z. (usbman)]

Ich habe das neue Bit unglücklicherweise bFlashErr genannt. bVerifyErr 
trifft es eher. Das Bit wird beim ersten Verify Error gesetzt und wird 
nur vom Erase Kommando oder Neustart zurückgesetzt. Wenn das Bit gesetzt 
ist schlagen nachfolgende Verify Versuche fehl.

Beim Erase werden jetzt 8 1k Blöcke zerstört vorher nur 4 Blöcke. 
Insgesamt ist der Bootloader nun dicht.

Thomas

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

Danke fürs reinschauen.

Ist aufjedenfall ziemlich interessant zu sehen das solch eine 
rückmeldung etwas bewirkt auch bis nach china :)

[Thomas Z. (usbman)]

Ich werde, wenn ich Zeit finde, basierend auf Bit 14 im Configspace 
vielleicht probieren ein universelles win Programm zu schreiben, um 
einen beliebigen Bootloader auf den Chips zu installieren.
Ich hab mir jetzt erst mal einen Fakeloader gebastelt um mit der V2.4 
etwas zu spielen.
Hat das mit dem Alichip funktioniert?

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

Der alichip ist leider weiterhin nicht ansprechbar und zeigt keine 
reaktion über usb, das Die ist verglichen und der Oszillator läuft auch 
also muss er tatsächlich blank sein.

Selbst wenn ein Programm geflasht wäre welches den Bootloader am Start 
verhindert müsste man ihn trotzdem in den Bootloader bekommen per Dplus 
pin.

Jedoch sollte dann SPI ja noch aktiviert sein vielleicht kann man damit 
testen per SPI zu kommunizieren wenn es bei den anderen gesperrt ist

[Thomas Z. (usbman)]

Dann hätte ich noch die Idee mal den Reset Pin auf Low zu legen. Du 
erinnerst dich an mein Problem mit dem ch559 als ich nach dem ersten 
Flashen nicht mehr an den Chip gekommen bin? Beim Ch552 kann man ja auch 
den ext Reset aktivieren.

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

Das versuche ich noch einmal, danke.

Der reset beim ch552 ist bissher standart mässig aktiviert also sobald 
high läuft er nicht mehr und floating / low gleich running. Hatte damit 
gerade erst für den HID zu Arduino code mit zutun teste es aber wie 
gesagt dennoch.

Auch besagt ja die spi anleitung das wenn reset high ist SPI slave aktiv 
ist soweit ich es verstanden hatte hat nichts mit dem testen zutun aber 
ist für später auf jeden Fall interessant

[Thomas Z. (usbman)]

Nun mir ist klar dass der ch559 was die Ports angeht etwas anders tickt. 
Floading ist bei einem default Port normalerweise eine 1. Vielleicht 
kannst du das Teil auch seriell dazu überreden in den Bootloader zu 
springen das hat mir damals beim ch559 den Arsch gerettet.

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

Leider hatte ich weiterhin keinen erfolg, auch über seriell nicht.

Mit einem normalen chip funktioniert seriell aber mit dem Ali chip 
weiterhin leider nicht.

[8051 Guy (Gast)]

Did you evaluate the possibility of the ali chip is a total fake ?

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

8051 Guy schrieb im Beitrag #6391339:
> Did you evaluate the possibility of the ali chip is a total fake ?

Yes its genuine. Compared the die with the real one

[Thomas Z. (usbman)]

Ich wollte eigentlich das Testprogramm zum manipulieren der Configbits 
auf die v2.31 erweiterten, damit es mit allen Loadern klar kommt. V2.31 
und v2.40 verhalten sich da ja identisch. Dazu hab ich mir das 
Schreibkommado 0xa8 noch Mal näher angeschaut.
Fazit es geht nicht, bit15 wir immer gelöscht bit14 immer gesetzt egal 
was man dem Kommando an Parameter mitgibt.

Damit fällt dies Option auch weg. Für Tests mit der SPI Schnittstelle 
bleibt also nur der V1.1 Loader übrig.

[ben utzer (Gast)]

Hallo,

meine CH559 Applikation ist im Grunde genommen fertig, nun möchte ich 
gerne einen Bootloader schreiben, welcher das Update von einem USB Stick 
ließt.

An sich nichts abwegiges, sowohl für das File Lesen, als auch für Flash 
schreiben gibt es Code Beispiele, neurdings auch ins Englische 
übersetzt:
https://github.com/bootrino/ch559samplestranslated

Beim Versuch das "CH559 U disk host file system interface" einzubinden 
stoße ich jedoch auf folgendes Problem: Ein Teil der Funktionalität wird 
nur als .LIB bereitgestellt. Ich compiliere mit SDCC und habe nun den 
Verdacht, dass die lib nicht mit SDCC kompatibel ist. Hat da jemand 
Erfahrungen oder kennt sich besser mit Keil und SDCC aus?

Klar zur Not schreibe ich das alles selber mit FatFS, möchte aber nur 
ungern das Rad neu erfinden hier.

vielen Dank

[Thomas Z. (usbman)]

Schau dir meinen UDisk Code weiter oben an. Der compiliert auch mit 
SDCC. Mit einem Sprung nach 0xD800 schaltet er den 1. Usbport in den 
Hostmode und holt ein ev vorhandenes vordefinierten File vom Stick und 
flasht es auf den Controller.

[ben utzer (Gast)]

oh großartig! Hatte zwar den thread durchsucht, aber das wohl leider 
nicht gefunden. danke

[Thomas Z. (usbman)]

udisk-2.zip ist die Variante die auch Support für SDCC hat. Ansonsten 
gibt bei WCH auch einen Download der alle Beispiele enthält. Dort ist 
auch die UDisk Lib im Source enthalten, allerdings nur für Keil und 
nicht besonders effektiv.
Mein Code ist vom WCH Beispiel abgeleitet.

[ben utzer (Gast)]

Hi Thomas,

zunächst mal vielen Dank für den uboot code, konnte ihn ohne Probleme 
compilieren. Mir ist klar, dass nicht alle USB-Sticks funktionieren 
(steht ja auch in der readme), war dann aber doch überrascht, dass von 
den 4 die ich hier habe leider keiner läuft. Bei 3 Stück war die 
Configurator Länge > 32 Byte, bei einem erhalte ich die Meldung "reading 
bootrecord failed".

Wenn ich den length check testweise raus nehme scheint alles zu laufen, 
es kann aber kein file gefunden werden.

Besteht irgendeine Chance durch besseres Parsen des Configuration 
Descriptor mehr Kompatibilität zu erreichen, oder sind das einfach alles 
die falschen Sticks? Beispiel Configuration Descriptor. Hier gibt es 
noch einen zusätzlichen Interrupt Endpoint. (7 bytes mehr)
Nach auskommentieren des length checks bekomme ich dann allerdings einen
"Open failed" error mit 0x42. Rootcluster und PartDataStart sind 0
Danke!

descriptors[0] = "Configuration Descriptor" 
bLength = 9 
bDescriptorType = USB_CONFIGURATION_DESCRIPTOR_TYPE (2) 
wTotalLength = 39 
bNumInterfaces = 1 
bConfigurationValue = 1 
iConfiguration = 0 
Reserved = 0 
SupportsRemoteWakeup = 0 
SelfPowered = 0 
PoweredByBus = 1 
MaxPower = 0x31 -> 98 mA 

descriptors[1] = "Interface Descriptor" 
bLength = 9 
bDescriptorType = USB_INTERFACE_DESCRIPTOR_TYPE (4) 
bInterfaceNumber = 0 
bAlternateSetting = 0 
bNumEndpoints = 3 
bInterfaceClass = UsbMassStorage (8) 
bInterfaceSubClass = 6 
bInterfaceProtocol = 80 
iInterface = 0 

descriptors[2] = "Endpoint Descriptor" 
bLength = 7 
bDescriptorType = USB_ENDPOINT_DESCRIPTOR_TYPE (5) 
bEndpointAddress = 1 
Reserved = 0 
Direction = Output 
type = Bulk (2) 
reserved = 0 
wMaxPacketSize = 512 
bInterval = 1 

descriptors[3] = "Endpoint Descriptor" 
bLength = 7 
bDescriptorType = USB_ENDPOINT_DESCRIPTOR_TYPE (5) 
bEndpointAddress = 2 
Reserved = 0 
Direction = Input 
type = Bulk (2) 
reserved = 0 
wMaxPacketSize = 512 
bInterval = 1 

descriptors[4] = "Endpoint Descriptor" 
bLength = 7 
bDescriptorType = USB_ENDPOINT_DESCRIPTOR_TYPE (5) 
bEndpointAddress = 3 
Reserved = 0 
Direction = Input 
type = Interrupt (3) 
reserved = 0 
wMaxPacketSize = 64 
bInterval = 8

[Thomas Z. (usbman)]

Welche Größen haben deine Sticks? Ich hab hier mit einem alten 1Gb und 
einem 16Gb Stick getestet.
Sind die Sticks wirklich Fat32 formatiert?
Ich muss mal nachschauen für was der  Interrupt EP benutzt wird das 
schaut nicht nach Bulk only aus.
Ansonsten sollte es kein Problem darstellen die Länge erst mal zu 
ignorieren.
Ich nehme an du testest mit dem Debug Release.
Dir ist klar dass der Filename immer upper Case sein muss und ev mit 
space aufgefüllt werden muss?

Noch ein Hinweis benutze keine USB3sticks. Der ch559 ist USB fullspeed 
only. Ich hab noch nie probiert ob 3.0 Stick korrekt die 1.1 Modi 
beherrscht Bulk ist dort ja nur 64 Bytes. Du kannst dir ja mal die 
bulksize der EPs per Debug Print ausgeben lassen.
Ich meine mich auch daran zu erinnern, dass im Original ein Test auf < 
32 GB drin war.... Ich hatte den chin. Kommentar auch übersetzt nicht so 
richtig verstanden.

[Thomas Z. (usbman)]

OK ich hab das gerade mal nachgelesen. MSC mit Interrupt EP sprechen das 
UFI Protokoll. Das beherrscht UDisk nicht dazu sind umfangreichere 
Änderungen am Protokoll notwendig. UDisk kann nur Bulk only 
Protokollcode 0x50. Tendenziell solltest du erst Mal mit einem alten 
Stick testen.

[ben utzer (Gast)]

Was mich eben stutzig macht ist, dass der Stick sich sehr wohl als
bInterfaceClass = UsbMassStorage (8)
bInterfaceSubClass = 6
bInterfaceProtocol = 80
Meldet. Also ganz klar bulk -only
UFI wäre wenn ich das richtig verstehe SubClass 4
Das ist ein recht alter 4GB Stick,
Ich probiere es weiter auch mit anderen Sticks, danke erstmal :)

[Thomas Z. (usbman)]

Bulk only Transport ist bInterfaceProtocoll=0x50. Das ist auch das was 
meine Sticks reporten.(usbmassbulk_10.pdf)  Kannst du mal die komplette 
Ausgabe von UsbDevView hier einstellen?

Ich muss allerdings gestehen, dass ich vorwiegend mit dem Keil getestet 
habe. Es ist nicht auszuschließen dass im SDCC Code noch ein Bug steckt.
Versuch dich mal im Debug Release mit zusätzlichen printf Ausgaben 
ranzutasten. Ich würde beispielsweise mal die bulksize der beiden 
Bulkeps ausgeben die müssen bei fullspeed auf 64 stehen. Zusätzlich 
kannst du mal ausgeben ob die Zuordnung für in und out korrekt 
abgebildet wird.

[ben utzer (Gast)]

Puh! Ok.
Aaaalso, nach einigen Stunden Specs lesen und USB transfers mitschneiden 
habe ich nun heraus gefunden:

1.
Zumindest Windows Disk Management und auch Rufus legen einfach keinen 
MBR an, wenn es auf dem Stick nur eine Partition gibt. Bei nur einer 
Partition, liegt das Dateisystem einfach an Adresse 0.
Nur bei 2 oder mehr Partitionen (oder wenn bootbar) wird ein MBR 
angelegt.

Das sollte sich durch einen zusätzlichen Check:

if( (TxBuffer[0]==0xEB) &&  // JMP
       (TxBuffer[1]==0x58) &&  // Marker FAT32
       (TxBuffer[2]==0x90))    // JMP offset

recht gut herausfinden lassen.

2. Manche Sticks geben sich als "Bulk only Transport"

bInterfaceClass = UsbMassStorage (8)
bInterfaceSubClass = 6
bInterfaceProtocol = 0x50

aus, haben aber noch zusätzliche Endpoints. Ich habe Sticks gesehen, die 
noch einen zusätzlichen Interrupt Endpoint haben z.B. Die sollten aber 
trotzdem kompatibel sein, man muss nur die Endpoints korrekt parsen

Ich werde mal morgen Code schreiben und berichten.

[Thomas Z. (usbman)]

ben utzer schrieb:
> Nur bei 2 oder mehr Partitionen (oder wenn bootbar) wird ein MBR
> angelegt.

Das passt meine Sticks sind alle bootbar entweder ein Dos oder div 
Linuxe. Auf die Idee, dass der MBR fehlen könnte, bin ich nicht 
gekommen. Das muss abgefangen werden. Den Jmp offset sollte man ev gar 
nicht auswerten. Die Fat32 Erkennung ist sicher noch ausbaufähig.

[S. R. (svenska)]

Thomas Z. schrieb:
> Auf die Idee, dass der MBR fehlen könnte, bin ich nicht gekommen.

Die Dinger nennen sich "Superfloppy". :-)

Ein besserer FAT-Check sieht so aus:

if( (TxBuffer[0] == 0xE9) ||
    (TxBuffer[0] == 0x69) ||
    ((TxBuffer[0] == 0xEB) && (TxBuffer[2] == 0x90)) ) {
        // ist FAT
}

[ben utzer (Gast)]

Kleines Update:

Hatte mit dem Bootloader von Thomas angefangen, aber nun mittlerweile so 
viel modifiziert, dass kaum mehr was vom Originalcode übrig ist. Werde 
den Code posten, wenn fertig.

Das ganze läuft dann über Petit FatFS und ist kompatibel mit FAT12, 16 
und 32. Unterstützt sowohl Sticks, mit als auch ohne MBR.

[Thomas Z. (usbman)]

Ich hab mir am WE das ch559evt.zip näher angeschaut. Dort gibts im PUB 
Ordner
einen Schaltpan der die Beschaltung zum ext SPI Program Interface 
zeigt.Meine Vermutung ist nun, dass RST aktiv sein muss damit man den 
Prog Mode erreichen kann.
Zusätzlich gibts eine OffLine Burner software bestehend aus exe und 
dll.Ich habe dann mal einfach mit dem PE explorer in die recoursen der 
exe geschaut.
Gefunden hab ich ein chin. Dialog und ein binary blob. Das binary könnte 
die FW für einen CH559 sein. Ich muss mal schauen wie ich das aus den 
Recourcen exportiert bekomme. Vieleicht kann man damit die ext 
Programmierung aktivieren.

Kennt jemand von euch eine Software die Unicode strings in Recourcen 
korrekt anzeigt? Der PE explorer zeigt nur ????? an. Für eine 
Übersetzung nicht hilfreich.
Deshalb auch nur als png exportiert dort wird der Text korrekt angezeigt

Thomas

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

Das sieht ja ziemlich vielversprechend aus die Datei scheint ja eine 
komplette ÍÑ»úÉÕ¼Æ÷ʹÓÃ˵Ã÷.pdf Anleitung zu sein

[Thomas Z. (usbman)]

so ich hab das blob exportieren können. Es ist tatsächlich eine CH559 
FW.
Die FW ist ca 32k gross und leider im large mode übersetzt. Das macht 
die Sache ziemlich unübersichtlich. Das wird etwas dauern bis das 
vernüftig formatiert ist. Das gute ist es gibt jede Menge debug strings.

Thomas

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

Denkst du es ist die Mini SPI firmware ?

[Thomas Z. (usbman)]

Aaron C. schrieb:
> Denkst du es ist die Mini SPI firmware ?
keine Ahnung ich hab allerdings die Hoffnung dass die FW für beide 
Offline Flasher ist und dass da irgend was drin ist für den ext SPI 
mode.

Noch ist es allerdings viel zu früh da eine Aussage zu treffen. IDA hat 
jedenfalls jede Menge libbcode aus der c51L.lib identifiziert. Leider 
gibts keineSchaltpläne der beiden Offline Flasher

Thomas

[nigg (Gast)]

Peter D. schrieb:
> oder
> Wickenhäuser

Hehe, dass der überhaupt bekannt wurde mit der grottigen IDE... Aber 
genau das macht's aus und irgendwo hab ich auch noch nen Schuhkarton 
voll mit Boards von denen. C535 oder so ähnlich mit riesigen 
Wannensteckern. Mehr Adaptergebastel als sonstwas...

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

@Thomas Z.
Wo wir gerade bei 8051 RE sind, hast du dich zufällig schonmal mit dem 
CC1110 beschäftigt?

Bin da bei einer firmware von preisschildern auf der suche nach dem RF 
teil also welche frequenz sie nutzen und welches protokoll genutzt wird.
Bin recht weit aber habe problem mit ghidra die richtigen Parameter für 
eine function rauszufinden auch weil die frequenzen über ein array 
geladen werden

Sorry für OT

[Thomas Z. (usbman)]

Aaron C. schrieb:
> @Thomas Z.
> Wo wir gerade bei 8051 RE sind, hast du dich zufällig schonmal mit dem
> CC1110 beschäftigt?
nein denn kenn ich nur vom hörensagen.
Kennst du den Compiler? Das sollte anhandvon finger prints relativ 
einfach rauszufinden sein.

ghidra kenn ich garnicht ich mach alles mit IDA

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

Der compiler müsste IAR sein.
Leider gibt es das SDK nicht offen und nur einfache nicht original SDK 
beispiele sonst könnte man gut den code vergleichen.

Mit ida habe ich es auch probiert aber ghidra ist dort angenehmer wegen 
der pseudocode darstellung, auch wenn es bei 8051 echte probleme hat

[Thomas Z. (usbman)]

Aaron C. schrieb:
> Der compiler müsste IAR sein.
also little endian. Gibt's für ghidra sowas wie die Erkennung von Lib 
Funktionen?

[Thomas Z. (usbman)]

kleines Update..
ich hab die Recourcen des Dialogs nun mit hilfe des Recource Hackers 
überarbeitet noch sind die Strings zu lang (chin Strings sind halt 
kürzer)

Mir ist aufgefallen, dass so ziemlich alle Controls des WCHISPTools 
vorhanden sind nur halt auf unsichtbar geschaltet

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

Cool, das sieht ja weiterhin sehr vielversprechend aus.

[Thomas Z. (usbman)]

Ich bin inzwischen ein Stück weiter, glaube allerdings nicht dass dies 
zum Ziel führt, den ext SPI zu entschlüsseln.

Was ich bisher gefunden habe:
1. Es gibt 2 Interrupt Funktionen USB und Timer2
2. SPI0 geht sehr wahrscheinlich auf das SPI Flash
3. Eine soft serial ist vermutlich eine I2C für die 7Seg
4. P4.0 und P4.1 sind die beiden LEDs / Statusleitungen
5. USB wird sowohl als Device oder Host betrieben
6. Es ist eine Art udisk für das Spi Flash implementiert.
7. printf geht auf Uart0 wegen der original putchar Funk.
8. P0 ist vermutlich das machine Control Interface

Ich kann den Code inzwischen bitgleich zum Original übersetzen, 
allerdings sind noch viel zuviele magic numbers im Code.
Als nächstes werde ich wohl die Keil libs in include files auslagern und 
ein paar Makros schreiben um die Quellen einzudampfen.

[Thomas Z. (usbman)]

Ein Zwischenstand:
Ich habe die wesentlichen Funktionen inzwischen identifiziert.
Nach wie vor hab ich keine Hinweise zu einem ev ext SPI Interface 
gefunden.
Ich bin mit der Speicher und Variablen Belegung fast durch. Es gibt etwa 
10 Code Referenzen die außerhalb des Codes liegen. Noch hab ich keine 
Idee was dort liegen muss, es wird aber von der Firmware nur lesend 
darauf zugegriffen. Ev sind das config Optionen.

Firmware Bugs habe ich auch schon gefunden und ein memset mit der Länge 
null, oder ein Code Pointer der auf den Bootloader zeigt, aber im 
Typbyte die Kennung für idata hat.

[Thomas Z. (usbman)]

Ich hab über die Feiertage etwas weiter gemacht...
In der Firmare ist keinerlei Code drin um den ext SPI programmer zu 
aktivieren :-(

Der große Offline Flasher ist einfach ein GangProgrammer der 8 Devices 
über USB Flashen kann. Er verwendet einen CH543 als Led Treiber und zur 
Tastenabfrage (I2C). Der 2. Baustein dürfte ein CH544 sein der als Hub 
für die Ports fungiert. Ev stellt der auch den Port für den Memory Stick 
bereit der die Statistik Daten speichert. Zusätzlich kann der große 
Flasher auch über ein Adapter Chips im Yamaichi Sockel flashen.

Die Firmare selbst kann beide Flasher bedienen. Der MiniOffline Flasher 
ist eine abgemagerte Version, dort wird ein Chip seriell programmiert.
Die Betriebsart wird mit P0.0 und P0.1 beim Mini eingestellt (4 Modes). 
Beim großen Flasher über einen DIP Schalter an P1.0 .. P1.2 (8 Modes).

Insgesamt nicht das was ich mir vorgestellt hatte. Mehr lässt sich ohne 
Schaltpläne nur schwer ermitteln.
Vielleicht frickle ich irgendwann mal ISD51 ans Ende der Firmware, damit 
man man in uVision auf der HW steppen kann.

[Thomas Z. (usbman)]

Seit einiger Zeit gibt es 2 neue Controller von WCH. CH556 und CH557. 
Der CH556 ist der kleine Bruder mit 2 Fach Usbhub und ohne RGB Led 
Interface

Gemeinsam ist den Chips:
 - 64k Flash
 - 8k  XRam
 - 2 x Uart
 - 2 x SPI
 - 1 x I2C Master
 - 1 x I2C Slave
 - 1 x Usb Device
 - 1 x Usb Host

Die Dinger sind im 48Pin Gehäuse pinkompatibel zum CH558/CH559.
Das Flash Interface wurde wesentlich modifiziert. Die Blocksize ist nun 
64 und lustigerweise werden beim Löschen die Bits auf 0 gesetzt. Ist 
also wohl eher ein EEPROM. Auch lustig: ein sfr was den Akku reversed 
ausgibt.

Einige sfrs sind wieder im xdata implementiert. Von WCH gibt es noch 
keinen Beispiel Code bis auf ein paar Usb Fragmente, die Header sind 
weitgehend unbrauchbar.
Da ich sowieso ein ch55x.h plane habe ich die header mal überarbeitet. 
Ich hab meine Version mal angehängt.

Thomas

[Thomas Z. (usbman)]

Mich hat das Endpoint Handling der CH5xx schon die ganze Zeit gestört, 
weshalb ich schon früh mit ein paar Makros gespielt habe. Allerdings hat 
mir das alles nicht so recht gefallen, bzw in einigen Fällen auch nicht 
richtig funktioniert, weshalb ich das bisher nicht benutzt habe.
Nun habe in einem neuen Projekt die Dinger mal ausprobiert und getestet. 
Die Macros sind in einem eigenen Header File untergebracht und sollten 
bei allen CH5xx Chips funktionieren.

Einen Hinweis zum USB core hab ich noch:
Bei meinem aktuellen Projekt habe eine ganze Weile nach einem Fehler 
beim USB Handling gesucht. Ursache war schlussendich eine falsche 
Reihenfolge bei der USB Initialisierung.
Es muss zuerst USB_CTRL bzw UDEV_CTRL initialsiert werden, ansonsten 
wird zumindest UEP2_3_MOD nicht korrekt gesetzt. Dazu ist leider nichts 
in den Docs zu finden. Gemerkt hab ich das auf einem CH559 dürfte aber 
ev auch die anderen Chips der Serie betreffen.

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

Danke dir für Das Update.

 Kann leider nicht viel meinerseits dazu beitragen derzeit aber finde es 
gut dass du immer noch dabei bist.

[Thomas Z. (usbman)]

hab gerade gesehen das mein Header File einen Fehler hat: (T und R 
vertauscht)
So ist es richtig:

#define STALL_IN(ep)  (UEP ##ep ##_CTRL |= UEP_T_RES_STALL)
#define STALL_OUT(ep) (UEP ##ep ##_CTRL |= UEP_R_RES_STALL)

[Andreas M. (amesser)]

Ich überlege gerade den CH552 als UART/JTAG Bridge für einen ESP32-S2 zu 
verwenden. Bevor ich in China bestelle, wenn jemand noch ein paar /5-10) 
Exemplare hat, die er gerne los werde möchte, würde ich nehmen wollen. 
Danke....

[Thomas Z. (usbman)]

Es gibt mittlerweile auch ein Shop in DE der die CH552 in beiden 
Gehäusen preiswert anbietet.

https://www.shotech.de/de/schaltkreise/mikrocontroller/mikrocontroller-8bit/

[Thomas Z. (usbman)]

Ich habe mal ein Compound Device bestehend aus MSD und VCP gebaut, 
zusätzlich würde noch ein 2. VCP oder ein HID Interface gehen.

Beim VCP hab ich auch den IAD Descriptor mit eingebaut ohne IAD 
funktioniert das zumindest in Verbindung mit dem MSD nicht (mehr). Die 
Idee ist ein Device zu bauen was ohne Treiber Installation direkt 
verwendet werden kann, weshalb ich ausschlieslich auf CLASS Interfaces 
setze.
Enum funktioniert und der Gerätemanager zeigt sowohl Comport als auch 
Memory Device an.

Zusätzlich habe angefangen  die USB Kompatibilität mit dem USB Command 
Verifyer Tool von der usb.org zu überprüfen. Das Tool ist zwar etwas 
wackelig, zeigt aber, dass keines der WCH samples ohne Errors 
durchläuft. Ich teste unter W10 und im Moment auf einem CH559. Der code 
sollte aber problemlos auf einem CH552 laufen.

const uint8_t code ConfigDesc[98] = 
{
   sizeof(ConfigurationDescriptor),
   USB_CONFIGURATION_DESCRIPTOR,
   sizeof(ConfigDesc),0,
   3,                      // 3 interfaces
   1,                      // one config
   USB_STRING_UNDEFINED,
   0x80,                   // buspwerd 
   100/2,                  // 100mA max 
   
   // MSD Class
   sizeof(InterfaceDescriptor),
   USB_INTERFACE_DESCRIPTOR,
   MSD_INTERFACE, 
   0,
   2,                      // 2 Endpoints
   USB_CLASS_MSD,
   MSD_SUBCLASS_SCSI,
   MSD_PROTO_BULKONLY,
   USB_STRING_UNDEFINED,

   sizeof(EndpointDescriptor),
   USB_ENDPOINT_DESCRIPTOR,
   0x2,
   EP_BULK,
   0x40,0x00,
   0,

   sizeof(EndpointDescriptor),
   USB_ENDPOINT_DESCRIPTOR,
   0x82,
   EP_BULK,
   0x40,0x00,
   0,

// IAD
   0x08,
   0x0B,
   VCP_CONTROL,                // first interface = 1
   2,                          // 2 interfaces 
   USB_CLASS_CDC,
   CDC_SUBCLASS_ABSTRACT,
   CDC_PROTOCOL_V250,
   USB_STRING_UNDEFINED,

// cdc class
   sizeof(InterfaceDescriptor),
   USB_INTERFACE_DESCRIPTOR,
   VCP_CONTROL,                // interface No 1
   0,                          // alternate setting
   1,                          // 1 extra endpoint
   USB_CLASS_CDC,              // class
   CDC_SUBCLASS_ABSTRACT,      // subclass
   CDC_PROTOCOL_V250,          // protokol
   USB_STRING_UNDEFINED,

   5,
   CDC_CS_INTERFACE,
   CDC_SUB_HEADER,             // identifier header
   BCD_CDC & 0xFF,BCD_CDC >> 8,//

   5,
   CDC_CS_INTERFACE,
   CDC_SUB_CALL_FUNCTION,      // identifier Call Management
   0x00,0x00,

   4,CDC_CS_INTERFACE,
   CDC_SUB_ABSTRACT_CTRL,      // identifier Abstract
   0x02,                       // cababilities

   5,
   CDC_CS_INTERFACE,
   CDC_SUB_UNION_FUNCTIONAL,   // identifier Functional
   VCP_CONTROL,                // interface 1 ctrl
   VCP_DATA,                   // interface 2 Data

   sizeof(EndpointDescriptor),
   USB_ENDPOINT_DESCRIPTOR,
   0x81,                       // ep1 in
   EP_INTERRUPT,               // interrupt
   8,0,
   0xFF,                       // interval

   //interface2 data interface
   sizeof(InterfaceDescriptor),
   USB_INTERFACE_DESCRIPTOR,
   VCP_DATA,                   // interface No 2
   0,                          // alternate setting
   2,                          // 2 extra endpoint
   CDC_CLASS_DATA,
   USB_SUBCLASS_UNDEFINED,
   USB_PROTOCOL_UNDEFINED,
   USB_STRING_UNDEFINED,

   sizeof(EndpointDescriptor),
   USB_ENDPOINT_DESCRIPTOR,
   0x03,                       // ep3 out
   EP_BULK,                    // bulk
   0x40,0x00,
   0x00,                       // interval

   sizeof(EndpointDescriptor),
   USB_ENDPOINT_DESCRIPTOR,
   0x83,                       // ep3 In
   EP_BULK,                    // bulk
   0x40,0x00,
   0x00
};

[Andreas M. (amesser)]

Heute habe ich den WCH552G auf meine Board aufgelötet und nach kleinen 
Startschwierigkeiten das CDC Beispiel auf UART0 angepasst zum Laufen 
bekommen. Sehr schön!

Mir ist jetzt aufgefallen, dass allerdings der Reset nicht funktioniert. 
Wenn ich, durch einen Drucktaster auf der RST Leitung einen High-Pegel 
anlege, dann passiert irgendwie nichts. Meine Led bleibt an und das 
Gerät verschwindet auch nicht vom USB Bus. Muss ich da noch irgendwas 
anprogrammieren?

[Thomas Z. (usbman)]

Andreas M. schrieb:
> Muss ich da noch irgendwas anprogrammieren?

Ja du musst den Reset Pin im WchIspTool beim Flashen aktivieren. Es gibt 
dafür eine Optionshaken

[Andreas M. (amesser)]

Thomas Z. schrieb:
> Ja du musst den Reset Pin im WchIspTool beim Flashen aktivieren. Es gibt
> dafür eine Optionshaken

Danke, dann muss ich wohl mal eines der freien Tools so anpassen, dass 
das geht, habe kein Windows :-)

Nachdem ich dann über ein paar Eigenheiten des SDCC (2-dim array) 
gestolpert bin und auch an einigen anderen Stellen zu kämpfen hatte, 
habe ich erst mal einen guten Zwischenstand bei meinem Projekt erreicht.

Auf dem WCH552 laufen jetzt parallel ein 115.2kBaud USB-To-Serial mit 
Double Buffering zum Programmieren des ESP32-S2 und eine JTag Emulation 
des espjtag Interfaces von Espressif. Letzteres hat wohl irgendwo noch 
ein Problem, der openocd findet zwar die CPU und kann auch Register 
auslesen aber im GDB klappt das setzen von Breakpoints und das Steppen 
noch nicht. Irgendwann bleibt dann auch die USB Kommunikation mit dem 
openocd stehen.

Um das näher zu untersuchen muss ich mir mal was überlegen, eventuell 
einen USB Control Transfer mit dem ich mir die Variablen aus dem WCH 
ziehen kann. Der espjtag treiber im openocd hat leider ein paar 
Schwachstellen wo er sich beim kleinsten unerwarten Verhalten am USB in 
eine Endlosschleife legt. Irgendwo wird wohl in meinem Programm was 
nicht passen, eventuell habe ich auch noch einen Dead-Lock im Ablauf. 
8051 und auch der SDCC ist für mich Neuland, man kann ja leider nicht 
einfach rein debuggen 
(https://github.com/espressif/openocd-esp32/blob/master/src/jtag/drivers/esp_usb_jtag.c)

Eventuell geht auch noch eine Schneller Baudrate, für 115200 muss die 
Chipfrequenz allerdings auf 24MHz gestellt werden, das ergibt dann 
ziemlich genau einen Takt-Teiler von 13.

Hier liegt das Projekt: 
https://gitlab.com/amesser-group/electronic-devices/bastelino-esp32-s2

PS: Auf den Bild darf man meine Unfähigkeit, dass richtige Gehäuse zu 
bestellen bewundern :-) Ich habe mich dummerweise am Produktbild auf der 
Shop-Webseite orientiert.

[Marek N. (Gast)]

Moin,

der Vollständigkeit halber möchte ich erwähnen, dass der 
Low-Cost-Programmer "EZP2019 Plus" (z.B. 
https://www.ebay.de/itm/264972921339) auch den CH552G verwendet.

Ich hatte mich gewundert, als ich den gestern aufgemacht habe und 
gesehen hab, dass es ein USB-Controller aus der CH-Famile ist, aber ohne 
Quarz.
Darum hab ich recherchiert und bin u.A. auf diesen Beitrag gestoßen.

Beste Grüße, Marek

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

Vielen dank für die info

Das heist andersrum ja auch das man den programmer nachbauen könnte :)

[Thomas Z. (usbman)]

Ich habe auch den Verdacht, dass viele dieser billigen LED Panel Meter 
den CH552 benutzen und dort einfach ein Dual Slope Converter in Software 
nachgebaut wird.

Ich hab leider keines zur Hand um das zu überprüfen.
Ist also nur eine Theorie aufgrund diverser Bilder.

[Thomas Z. (usbman)]

ich habe mal angefangen mit github zu spielen....
Herausgekommen ist ein erstes repro was sich mit den CH55x beschäftigt.
Hab da einfach mal ein paar infos reingehackt.

Noch sind nur ein paar grundsätliche Dinge drin. Aber ein Anfang ist 
gemacht..

https://github.com/usbman01/WCH-8-Bit-x51-controllers

[Andreas M. (amesser)]

Ich bin jetzt inzwischen mit meinem Debugger weitergekommen. Ich habe 
das Protokoll jetzt auf OpenULINK umgestellt und kann damit jetzt 
erfolgreich JTAG debuggen und parallel dazu die UART laufen lassen.

Jetzt versuche ich gerade den Stromverbrauch zu optimieren und bin dabei 
über ein Problem mit der PWM gestolpert. Ich dachte zunächst, es hängt 
irgendwie mit dem Standby zusammen, aber da ist noch was anderes nicht 
in Ordnung.

Mit einem Code-Schnipsel, der einfach nur schnell auf das PWM2_DATA 
Register immer wieder den gleichen Wert schreibt, sehe ich auf dem Oszi 
als Ergebnis, dass die PWM ab und zu, für einen Zyklus einen Duty-Cycle 
von 100% erzeugt und dann wieder den korrekten Duty-Cycle macht. Das ist 
mir aufgefallen, weil da eine LED dranhängt.

In dem Header und dem Manual liest man was von PWM FIFO. Wirklich 
Informationen habe ich dazu aber leider nicht gefunden. Weis da jemand 
genaueres, was man bei der PWM beachten muss? Leider sind ja alle 
Kommentare auf Chinesisch

[Harald (Gast)]

Andreas M. schrieb:
> Leider sind ja alle
> Kommentare auf Chinesisch

Google Translate aufs Handy, Kamera Live Übersetzung wählen und los 
gehts. Nicht super komfortabel, aber so ist Chinesisch kaum noch eine 
Hürde.

[Andreas M. (amesser)]

Harald schrieb:
> Google Translate aufs Handy, Kamera Live Übersetzung wählen und los
> gehts. Nicht super komfortabel, aber so ist Chinesisch kaum noch eine
> Hürde.

Das habe ich schon gemacht ( Copy-Paste aus dem PDF Reader reicht dazu 
auch) Allerdings sind die Informationen zur PWM leider sehr dürftig. 
Leider gibt es auch ausgerechnet zur PWM kein Schaubild über den 
Internen Aufbau. Meine Vermutung ist nämlich, dass die irgendwie noch 
einen PWM Sequenzer mit einer FIFO oder extra Puffer drinnen haben. Das 
Clock-Schaubild zeigt auch zwei Takte die in die Unit reingehen. Der 
eine kann mit einem Teiler konfiguriert werden wobei nicht wirklich klar 
ist, für was der Teiler ist. Wenn man die PWM Auflösung von 256 Stufen 
und den 8 Bit Teiler berücksichtigt, dann könnte man auf die Idde 
kommen, das der Teiler für den PWM Grundtakt zuständig ist. Das Oszi 
hatte das PWM Signal auf ca. 83Hz taxiert, der Grundtakt waren 6MHz ( 
Interner RC Oszillator)

Meine Vermutung ist, das der interne Komparator irgendwie auf die Nase 
fällt, wenn man das PWM Register zum falschen Zeitpunkt schreibt. Es 
gibt da ein paar Status Bits. Es gibt auch "End Of Cycle" Interrupte für 
die PWM. Ich werde mal versuchen die zu benutzen.

[Thomas Z. (usbman)]

Ich selbst ha mich noch nicht mit dem PWM Modul beschäftigt, weis aber 
aus dem WCH Forum, dass sich die Leute über die mangelhafte Doku 
beschweren.

- Wie hast du den initialisiert?
- welchen Teiler verwendest du bei welcher fSys?

Ist dir klar dass du nur neuschreiben darfst wenn das bPWM_IF_END Flag 1 
ist?
Also entweder pollen oder Interrupt aktivieren.
Das PWM Example aus CH554EVT.zip kennst du?

Edit ok den letzen Beitrag hatte ich nicht gesehen der beantwortet ja 
die Fragen

[Andreas M. (amesser)]

Thomas Z. schrieb:
> Ich selbst ha mich noch nicht mit dem PWM Modul beschäftigt, weis aber
> aus dem WCH Forum, dass sich die Leute über die mangelhafte Doku
> beschweren.
>
> - Wie hast du den initialisiert?

  /* setup pwm for led */
  PWM_CTRL  = bPWM2_POLAR | bPWM2_OUT_EN;
  PWM_DATA2 = 0x40;

> - welchen Teiler verwendest du bei welcher fSys?

Ich habe Fsys=6 MHz, Das PWM Teiler Register fasse ich (bisher)
nicht an. Allerdings wird Fsys je nach UART Baudrate erhöht.

> Ist dir klar dass du nur neuschreiben darfst wenn das bPWM_IF_END Flag 1
> ist?

Jetzt schon :-) Danke für den Hinweis, mein Chinesisch ist nicht so gut 
:-)

> Also entweder pollen oder Interrupt aktivieren.
> Das PWM Example aus CH554EVT.zip kennst du?

Ich hatte gestern mal angefangen verschieden Beispiele durchzusehen, bin 
aber noch nicht so weit gekommen.

(Falls es jemanden interessiert, der vollständige Quellcode liegt hier: 
https://gitlab.com/amesser-group/electronic-devices/bastelino-esp32-s2/-/tree/master/firmware/programmer)

[Thomas Z. (usbman)]

Andreas M. schrieb:
> mein Chinesisch ist nicht so gut
> :-)

meins auch nicht aber google Translate funktioniert erstaunlich gut

WCH hat übrigns was ganz ähnliches gebaut, die nennen es WCH Link 
baasierend auf einem CH549. Das Ding stellt einen DAP debugger + VCP 
bereit. Das Teil braucht ma wohl um den M3 Cortex oder den RISC V core 
unter dieser chin Moun River Studio IDE zu debuggen / flashen.

Infos unter
https://github.com/kaidegit/CMSIS-DAPbyWCH

[Andreas M. (amesser)]

Thomas Z. schrieb:
> WCH hat übrigns was ganz ähnliches gebaut, die nennen es WCH Link
> baasierend auf einem CH549. Das Ding stellt einen DAP debugger + VCP

Danke, gut zu wissen. Das Teil ist ja quasi für solche einfachen 
Debugger prädestiniert. Espressif hat bei seiner toolchain den openocd 
leider um eine ganze Menge Treiber erleichtert, so dass die Auswahl an 
verfügbaren Protokollen nicht so gut ist.

Aber ich werde es mir mal merken ( Falls ich meinen Lauterbach Power 
Debug irgendwann mal nicht mehr haben sollte )

[Thomas Z. (usbman)]

Eigendlich hatte der Vertrieb von WCH versprochen mir so einen WCH-Link 
kostenfrei zu schicken... Das war allerdings vor 5 Wochen. Seitdem hab 
ich nichts mehr von denen gehört. Das wird dann wohl auf einen Selbstbau 
rauslaufen, wenn der CH549 im SO16 Gehause wieder allgemein verfügbar 
ist

Momentan gibts nur die QFN Variante, die trau ich mich nicht von Hand zu 
löten,

[Andreas M. (amesser)]

Thomas Z. schrieb:
> Ist dir klar dass du nur neuschreiben darfst wenn das bPWM_IF_END Flag 1
> ist?

Ja, das war es. Mache es jetzt in der ISR, jetzt läuft die LED so wie 
sie soll. Danke!

Irgendwann muss ich mir dann nochmal das Powermanagement ansehen. In den 
Beispielen sieht man immer das  WAKE_CTRL direkt vor setzen des PD bits 
geschrieben wird im SAFE_MODE. Ich habe das bei mir ja aufgeteilt und 
Setze WAKE_CTRL nur einmalig beim Start und später nur noch das PD Bit.

Nach den Strommessungen her sehe ich aber keinen Unterschied im 
Stromverbrauch in beiden Methoden. Allerdings ist der Verbauch des 
Gesamtboards höher als erwartet. Kann aber gut sein, das der ESP nicht 
wirklich schläft.

[Thomas Z. (usbman)]

Andreas M. schrieb:
> Irgendwann muss ich mir dann nochmal das Powermanagement ansehen. In den
> Beispielen sieht man immer das  WAKE_CTRL direkt vor setzen des PD bits
> geschrieben wird im SAFE_MODE. Ich habe das bei mir ja aufgeteilt und
> Setze WAKE_CTRL nur einmalig beim Start und später nur noch das PD Bit.

beide Methoden sind gleichwertig. Ich vermute mal dass du den Chip bei 
USB Events und RX Events aufwecken willst. Ob du das nun einmalig beim 
ProgStart machst oder immer bevor du PD aktivierst ist dann egal.

Ich werde die Erkenntnisse zum PWM Modul in mein Repro zu den CH55x mit 
aufnehmen wenn ich das Repro umbaue.

[Thomas Z. (usbman)]

Da ich nicht mehr glaube dass der WCH Link hier noch ankommt, habe ich 
mir das Binary aus der Repro mal näher angeschaut. Das ist ja für den 
CH549 gebaut die es wohl auch in absehbarer Zeit nicht geben wird.
Das Binary besteht au 2 Progammen. Teil 1 ist wohl ein Bootloader der 
das WCH übliche IAP Protokoll macht (0x000 .. 0xBFF)

Teil2 (0xC00 .. 0xBC60) ist der eigentliche WCH-Link. Das Ding beherscht 
zwei grundsätzliche Betriebsarten. Einnmal HID/VCP damit ist wohl der 
CMSIS-DAP realisiert, die 2. Betriebsart ist vendor defined und ist ev 
das Interface zum RiscV.
Generell entspricht die Codequalität dem was wir von WCH schon kennen um 
max ineffizenten Code zu generieren

- alle Module im large Mode
- haufenweise Var Inits auf File Ebene (Inittable ist 640 Bytes lang)
- maximal umständliche Konvertierungen von LSB <> MSB
- viele unbenutzte Funktionen

Wegen der Code Größe kommen nur die 64k Chips in Frage also entweder 
CH549 CH557 CH559 wobei beim CH559 das Flash Interface ein anderes ist.
Ich hab für ein paar kurze Tests die USB Initialisierungen einfach mal 
auf den CH559 angepasst, das funktioniert auf Anhieb.
Ich bin mir relativ sicher dass man den CMIS_DAP auch auch einem CH552 
ans laufen bekommt wenn man die Vendor Betriebsart entfernt.

Weil ich neugierig war hab ich dieses mal auch Ghidra benutzt. Gefällt 
mir ausgesprochen gut. Ich glaube es lohnt sich dafür etwas flirt 
ähnliches zu bauen um die runtime libs zu lokalisieren.

[Andreas M. (amesser)]

Thomas Z. schrieb:
> Teil2 (0xC00 .. 0xBC60) ist der eigentliche WCH-Link. Das Ding beherscht
> zwei grundsätzliche Betriebsarten. Einnmal HID/VCP damit ist wohl der
> CMSIS-DAP realisiert, die 2. Betriebsart ist vendor defined und ist ev
> das Interface zum RiscV.

Ok, gut zu wissen.

Ich habe leider inzwischen bei meinem Code/Schaltung Probleme 
festgestellt. Ich weis noch nicht genau wo es herkommt. Meistens geht 
es, aber von Zeit zu Zeit gibt es bei der UART und auch beim JTAG 
Kommunikationsprobleme. Ich konnte noch nicht herausfinden wo es 
herkommt bzw. was das genaue Problem ist.

UART ist ja meist prädestiniert für Fehler im Timing, aber JTAG ist ja 
quasi-statisch bzw. durch den Takt synchronisiert und da sehe ich ja 
auch Fehler. Möglicherweise hängt es mit den Spannungspegeln zusammen? 
Der WCH läuft bei mir ja mit 5V damit er programmierbar ist. Deswegen 
habe ich vom WCH 5V -> ESP32 3.3V Levelshifter mit 74HC4050. Die 
Richtung ESP32 -> WCH habe ich direkt verbunden. Wenn ich das Datenblatt 
des WCH richtig lese, dann sollte der bei 5V Betriebsspannung ab 2,4V 
einen High-Pegel erkennen.

Ich hatte zunächst versucht die Pins des WCH, die ich als Eingang 
benutze als echte Inputs zu konfigurieren. ( Nicht den Bi-Dir Mode des 
8051) Das schien anfänglich auch zu helfen aber inzwischen habe ich den 
Fehler wieder gesehen. Mal sehen wie ich da weiterkomme. Vielleicht ist 
auch noch irgendwas in meinem Programm quer, aber das sollte ja wiederum 
die UART nicht treffen. Vielleicht gibt es Probleme wenn gerade viele 
Interupte im System aktiv und der USB Interrupt nicht zeitnah bedient 
wird? Ich fühle mich beim 8051 mit sdcc noch nicht wirklich heimisch. 
Irgendwo hab ich mal was von Overlays gelesen und das man da mit 
Interupten aufpassen muss.

Da der Fehler nur sporadisch auftritt muss ich mir mal überlegen wie ich 
das weiter untersuchen kann.

[Thomas Z. (usbman)]

Das riecht etwas nach nicht atomic Zugriff auf Variablen.
Kandidaten sind Variablen die sowohl im Irq als auch auserhalb verwendet 
werden , speziell dann wenn das 16 Bit Vars sind.

Wie hast du die Irqs priorisiert? Ev solltest du mal einen Irq in einer 
eigenen Registerbank laufen lassen.
WCH läßt beim Link alle 3 Interrupts (USB, Uart, Timer2) in eigenen 
Registerbänken laufen, Ich bin aber der Meinung das das zumindest beim 
T2 unnötig ist der nur  TimeOut Funktionen bedient. Man spart sich 
lediglich das PUSH/POP von R0..R7.

Ansonsten würde ich wohl den 2. Uart initialisieren und ab und an ein 
paar printfs raushauen. Dazu must du eine CharOut Funktion für diesen 
Uart dazulinken. Details dazu stehen im SDCC Handbuch.
Ist der code auf Git aktuell?

[Andreas M. (amesser)]

Thomas Z. schrieb:
> Wie hast du die Irqs priorisiert? Ev solltest du mal einen Irq in einer
> eigenen Registerbank laufen lassen.

Damit hatte ich mich bisher noch gar nicht beschäftigt. Das mit den 
Registerbänken muss ich mir dann auch mal ansehen wie das funktioniert. 
Bisher kenne ich sowas ähnliches nur vom ARM926/966, wobei dort ja nicht 
zwischen den verschiedenen IRQs unterschieden wird.

Wenn ich unterschiedliche IRQ Prios vergebe, unterbrechen sich dann die 
IRQs auch gegenseitig? Ich vermute mal, da braucht man dann zwingend 
unterschiedliche Bänke?

Thomas Z. schrieb:
> Ansonsten würde ich wohl den 2. Uart initialisieren und ab und an ein
> paar printfs raushauen. Dazu must du eine CharOut Funktion für diesen
> Uart dazulinken. Details dazu stehen im SDCC Handbuch.

Hmm, das Problem ist, das der WCH selbst ja nix davon mitbekommt wenn 
ein Fehler auftritt. Mal sehen ob ich da irgendwo ansetzen kann. 
Entweder beschwert sich der ESP-IDF Programmer über einen Timeout oder 
der openocd kann den ESP nicht anhalten. Beim Programmer reicht ein 
Neustart. Beim openocd meist jedoch nicht, da scheint das Verhalten eher 
vom Mond abhängig zu sein. :-) Manchmal hilft es einen anderen USB Port 
zu nehmen.

Thomas Z. schrieb:
> Ist der code auf Git aktuell?

Ja

[Thomas Z. (usbman)]

Andreas M. schrieb:
> Wenn ich unterschiedliche IRQ Prios vergebe, unterbrechen sich dann die
> IRQs auch gegenseitig? Ich vermute mal, da braucht man dann zwingend
> unterschiedliche Bänke?

nein das nichts miteinander zu tun. Mit dem Bankswitch sparst du nur die 
PUSH/POP für R0..R7, das heist deine IRQ Latenz wird etwas besser.

Die natürliche Priorität ist durch die Interrupt No vorgegeben, bedeutet 
ein IRQ mit der kleineren No wird immer einen Interrupt mit höherer No 
unterbrechen, wenn du nicht sperrst. (Ein wesenticher Unterschied zu den 
AVRs)

Der USB Irq liegt bei 0x43 bei dem würde ich die Prio anheben dann 
können die anderen Irqs den USB Traffic nicht mehr unterbrechen (unter 
der Vorraussetzung dss alle anderen IRqs auf Pri0 laufen)

Zum Verständnis deines Codes:
ich hab da grad mal etwas quergelesen
EP1 In ist der VCP Status (unbenutzt)
EP2 bulk In/Out dein JTAG
EP3 bulk In/Out der VCP     richtig so?

Ich hab leider nicht gesehen ob USB überhaupt auf einem Interrupt läuft.

[Andreas M. (amesser)]

Thomas Z. schrieb:
> Die natürliche Priorität ist durch die Interrupt No vorgegeben, bedeutet
> ein IRQ mit der kleineren No wird immer einen Interrupt mit höherer No
> unterbrechen, wenn du nicht sperrst. (Ein wesenticher Unterschied zu den
> AVRs)
>
> Der USB Irq liegt bei 0x43 bei dem würde ich die Prio anheben dann
> können die anderen Irqs den USB Traffic nicht mehr unterbrechen (unter
> der Vorraussetzung dss alle anderen IRqs auf Pri0 laufen)

Ah, das ist auf jeden Fall mal ein wichtiger Punkt. Ich war bisher davon 
ausgegangen, dass sich die Interrupte erst mal nicht gegenseitig 
unterbrechen können. Da muss ich meine Code nochmal prüfen. Meine 
aktuelle Implementierung macht die Annahme, dass die sich nicht 
unterbrechen.

Bei der ARM926/966 beziehungsweise bei aktuellen Cortex-R oder -A können 
sich Interrupte auch nicht standardmäßig einfach unterbrechen. Das muss 
erst explizit im Interrupthandler wieder freigegeben werden. Nur bei 
Cortex-M passiert das automatisch anhand der Priorität.

Thomas Z. schrieb:
> Zum Verständnis deines Codes:
> ich hab da grad mal etwas quergelesen
> EP1 In ist der VCP Status (unbenutzt)
> EP2 bulk In/Out dein JTAG
> EP3 bulk In/Out der VCP     richtig so?

Ja genau

> Ich hab leider nicht gesehen ob USB überhaupt auf einem Interrupt läuft.

Ja, usb.c Zeile 184 ist der Handler. Allerdings werden nicht alle 
Aktionen darin gemacht. bei JTAG z.B. wird der In/Out Endpoint einfach 
nur auf NAK gesetzt. Die eigentliche Datenverarbeitung geht dann über 
der Hauptschleife aus der main.c heraus gemacht. (openulink_protocol.c 
Zeile 215) Da Openulink Protocol arbeitet da quasi uni-direktinal, 
deswegen müsste das eigentlich passen.

Die Verarbeitung des CDC erfolgt größtenteils nur im Interrupt, nur das 
Löschen des "NAK" bits wird aus der Main-Schleife heraus gemacht, und 
zwar immer dann, wenn für den Out (USB->UART) der nächste Puffer frei 
ist oder der nächste Puffer für den In (UART->USB) Daten zum Versenden 
enthält. Wobei das natürlich schief gehen könnte bzw. wird wenn da 
gleichzeitig der USB Interrupt für den selben Endpoint aber die andere 
Richtung reinkommt bzw ein ganz anderer Interrupt und dann auf dem 
EP_CTRL rummacht. Argh...

Da werde ich wohl viel mit Interrupt-Locks ( EA=0;.. EA=1) arbeiten 
müssen. Was besseres fällt mir da grad nicht ein. Bei ARMs versuche ich 
das wo es geht zu vermeiden und nutze da das Verhalten aus, dass 
Interrupthandler sich nicht unterbrechen. Gibt es beim 8051 ein 
intelligenteren Weg das zu synchronisieren?

Nachtrag: Darf ich EA=0;.. EA=1; auch innerhalb eines Interrupthandlers 
schreiben?

[Thomas Z. (usbman)]

Immer dort wo du im MainContext an EPxControl rumfummelst muss zwingend 
der USB IRQ gesperrt werden. Also immer dann wenn du ein NAK/ACK aif den 
Bulk EPs machst. EA = 0/1 ist der falsche Ansatz die Bits des Interrupt 
Registers kannst du einzeln direkt setzen. IE_USB=1 / 0

Die anderen Interrupts dürfen weiterlaufen. Nur Variablen die im Irq 
Kontext und Main Kontext gelesen/geschrieben werden brauchen spez 
Beachtung insbesondere wenn es 16 Bit Vars sind.

EA im Interrupt zu setzen / löschen macht beim 8051 keinen Sinn ist aber 
erlaubt. Ich kenne sowas nur von den AVRs.

Durch die natürliche Priorität wird z.B dein TimerIrq für JTAG immer den 
UART IRQ unterbrechen können.

[Thomas Z. (usbman)]

>> zwei grundsätzliche Betriebsarten. Einnmal HID/VCP damit ist wohl der
>> CMSIS-DAP realisiert, die 2. Betriebsart ist vendor defined und ist ev
>> das Interface zum RiscV.

kleine Korrektur meinerseits:
Die 2 Betriebsarten sind CMSIS V1 bzw CMSIS V2 des DAP.
Bei V2 wird anstelle des HID Interfaces ein WinUSB  Device enumeriert.

https://arm-software.github.io/CMSIS_5/DAP/html/dap_revisionHistory.html

Die Umschaltung wird über Settings im DataFlash gemacht welches beim 
Start ausgewertet wird. Eine etwas abgespeckte Firmware wird auch in den 
CH552 passen. Ich probier das gerade mit dem Stick von Aaron aus. V1 
passt locker in 6kByte wenn man die lsb <> msb Konvertierung mit einem 
htonl() in Assembler erledigt. Auch die 128 Byte DataFlash würden 
ausreichen. Lediglich fSys wäre nur 24MHz anstatt der 48Mhz beim 
Original. Da muss man etwas an den nops beim SWD Interface anpassen.

[Andreas M. (amesser)]

Thomas Z. schrieb:
> Durch die natürliche Priorität wird z.B dein TimerIrq für JTAG immer den
> UART IRQ unterbrechen können.

Ich habe mich jetzt mal ein bischen mehr in das Thema Interrupte beim 
8051 eingelesen. So wie ich die verschiedenen Beschreibungen aus dem 
Internet verstehe, gibt es beim 8051 je nach Implementierung zwei bis 
vier Prioritätsebenen. Man kann jeden Interrupt durch entsprechende 
Konfigurationsregister einer dieser Ebenen zuordnen. Die 
Interrupthandler die zur gleichen Prioritätsebene gehören werden 
sequenziell nacheinander ausgeführt, entsprechend Ihre Interruptnummer 
und unterbrechen sich nicht gegenseitig. Ein laufender Interrupthandler 
kann nur von einem Interrupthandler einer höheren Prioritätsebene 
unterbrochen werden. Das macht für mich auch am Sinn, denn sonst wird 
die Synchronisierung zwischen Interrupten aufwändig und kostet 
Performance und Speicher.

Nach Deiner Beschreibung müsste dass dann beim WCH552 jedoch anders 
sein?

Thomas Z. schrieb:
> Immer dort wo du im MainContext an EPxControl rumfummelst muss zwingend
> der USB IRQ gesperrt werden. Also immer dann wenn du ein NAK/ACK aif den
> Bulk EPs machst.

Naja, wenn ich zum Beispiel im ISR den Bulk EP nach Empfang nur auf NAK 
stelle und dann später im Main Context nach der Verarbeitung der Daten 
den Bulk EP wieder auf ACK stelle, dann sollte das auch ohne 
Interruptsperre funktionieren. Denn solange der EP auf NAK steht dürfte 
gar kein weiterer Interrupt für diesen EP mehr auftreten und somit der 
Handler sowieso nicht mehr an dem Register rumfummeln. Ich denke man 
muss nur sicherstellen das die "Besitz"-Übergänge passen und je nach 
Zustand jeweils nur ein Kontext "fummelt".

[Thomas Z. (usbman)]

Andreas M. schrieb:
> Nach Deiner Beschreibung müsste dass dann beim WCH552 jedoch anders
> sein?
Nein ich hab das falsch beschrieben, das war Unsinn.
Interrupts der gleichen Prio unterbrechen sich nicht. Die Reihenfolge 
wird durch die Interrupt Nummer festgelegt.
Die WCH Dinger haben 2 Prio Ebenen.

zu EPxCtrl:
wenn du sicherstellst, das EPxCtrl nur durch einen Befehl manipuliert 
wird brauchts keine Sperre
Beispiel:  UEP1_CTRL &= ~MASK_UEP_T_RES; //stellt den EP1In auf ACK
das wird zu
anl   UEP1_CTRL, #~ MASK_UEP_T_RES; -> 1 Befehl

das ist aber nur bei einfachen Verknüpfungen sichergestellt. Oft wird 
EpXCtrl erst mal in den Akku kopiert dort manipuliert und dann 
zurückgeschrieben.
Da du nicht sicher sagen kannst ob es ein einzelner Befehl wird, ist die 
Sperre da die einfachste Lösung. Du kannst natürlich auch ins LST File 
schauen.
Mit der Sperre bist du auf der sicheren Seite. Ob diese in jedem Fall 
notwendig ist müsste man sonst für jeden einzelnen Fall überprüfen.

Übrigens macht das WCH bei einigen neueren Beispielen nun auch so.

[Thomas Z. (usbman)]

Ich arbeite im Moment an einem Replacement für das debug.c von WCH. 
Geplant ist die Erzeugung einer Lib die dann nur noch zur Anwendung 
gelinkt wird. Im ersten Schritt erst mal für Keil, ich will das jedoch 
auch den für SDCC machen.

Ich hatte debug.c bisher nicht verwendet, sondern einzelne Funktionen 
daraus in mein Projekt kopiert. Es hat mich gestört wenn unreferenced 
function warnings auftauchen.  Das passiert bei einer Lib nicht wenn 
diese korrekt gebaut ist.

Im Anhang ein Entwurf mit den Kategorien die ich so plane. Erste Tests 
waren erfolgreich. Da die Controller in der Regel keinen Quarzanschluss 
haben (den gibts nur im 20Pin Gehäuse). habe ich mich bei der 
ClockConfig momentan auf den internen Oszilator beschränkt.

Schwierigkeiten bereiten mir momentan noch die delay Funktionen. Ich 
plane die von der aktuell eingestellten Clockfrequenz abzuleiten. Das 
hat den Vorteil dass dann die delays unabhängig vom clock sind.
Allerdings werde ich wohl auf 8 bit Parameter gehen. Ein max von 255ms 
bzw 255us halte ich für ausreichend. wenn jemand eine geniale Idee dazu 
hat wie man das kompakt hinbekommt immer her damit.

Das Ganze kann man dann auf Git Hub anschauen. Das Project ist schon 
angelegt, aber noch auf private gestellt.

[Thomas Z. (usbman)]

hier eine simple Funktion in Assembler für Kopieraktionen. Ich habe das 
Parameterhandling an memcpy angelehnt allerdings kopiert die Funktion 
nur max 255 bytes.
der Prototyp:

void fastxcpy8 (unsigned char xdata *dest, //R6R7
                unsigned char xdata *src,  //R4R5 
                unsigned char  size)       //R3

und das dazugehörige asm Modul

sfr XBUS_AUX = 0xA2; 
?PR?_fastxcpy8?FASTXCOPY  SEGMENT CODE

    PUBLIC  _fastxcpy8
    $REGUSE _fastxcpy8(R7,A,DPTR)

    RSEG   ?PR?_fastxcpy8?FASTXCOPY
_fastxcpy8: 
       INC  XBUS_AUX   ;second DPTR is always dest      
       MOV  DPH,R6 
       MOV  DPL,R7     ;destination
          
       DEC  XBUS_AUX   
       MOV  DPH, R4
       MOV  DPL, R5    ;source

       mov  A,R3
       MOV  R7,A   
       JZ   ?C001      ;nothing todo 

?C000: MOVX A,@DPTR    ;read source
       INC  DPTR       ;maybe enable autoinc on DPTR0
       DB   0A5H       ;MOVX @DPTR1,A & INC DPTR1
       DJNZ R7,?C000
?C001: RET

END

Das INC DPTR könnte man noch sparen wenn man das autoinc feature 
aktiviert.

Ich habe mich bewußt für die memory specific pointer endschieden weil 
sonst nicht alles in den Registern übergeben werden kann. Eine 2. 
funktion fastccpy8 kann aus dem Codebereich kopieren.

Ach ja fast vergessen das passt so natürlich nur den Keil C Compiler. 
SDCC muss ich erst noch anlesen.

[Thomas Z. (usbman)]

ich hab jetzt mal die Delay Funktionen implementiert. Die brauchen 
vermutlich noch etwas Feintuning und bei fSys <=750 KHz stimmen die 
Zeiten wohl nicht. Das ist aber beim Original auch so.
Der Source ist unter 
https://github.com/usbman01/Replacement-WCHs-debug.c
zu finden. Noch habe ich keine Projekt Dateien drin und die Doku fehlt 
weitgehend das kommt noch wenn ich das ding auch mit SDCC am laufen 
habe.

[Thomas Z. (usbman)]

so es gibt ein erstes build für den SDCC. Das war nicht so ganz einfach 
weil nur sehr wenig in den docs steht wie man libs baut. Auch die Sache 
mit der Parameter Übergabe könnte besser beschrieben sein. So wie das 
verstehe muss mindestens SDCC 4.0 eingesetzt werden, weil es vorher 
einen Bug in sdar gab und der alte lib manager nicht mehr mitgeliefert 
wird.

Ich habe ein paar Tests im Simulator gemacht um die Parameterübergabe 
bei fastxcpy8 zu überprüfen das hat sowohl in Keil als auch in SDCC gut 
ausgesehen.
Für den SDCC baue ich das Ganze einfach mit einer passenden Batch Datei. 
Noch hab ich nicht überprüft ob die ASM Module für die fastcopy 
Funktionen auch für den large mode korrekt sind.

Näheres unter dem Gitlink. Das ist aber noch sehr dynamisch dort. Es 
fehlen immer noch vernüftige uart module. Wer sich das Zeug runterladen 
will sollte unbedingt die Ordnerstruktur einhalten, da mein build sowohl 
unter Keil als auch unter SDCC darauf abgestimmt ist.

[Thomas Z. (usbman)]

Für die Reload Werte beim Uart0 (T1 Baudrate) hab ich mir mal ein 
Spreadsheet gebaut.
Damit kann man ganz gut sehen wenn der Fehler zu groß wird. 2.4% würde 
ich schon als grenzwertig betrachten, hat aber bisher bei mir noch 
funktioniert.

Das Sheet für Open Office ist hier:
https://github.com/usbman01/Replacement-WCHs-debug.c/tree/main/doc

[Ray R. (cluso99)]

Hallo,
Ich habe gerade dieses Forum gefunden.
Ich benutze deepL, um vom Englischen ins Deutsche zu übersetzen, also 
entschuldige, wenn es nicht ganz korrekt übersetzt wird.

Ich bin gespannt auf meine CH55xT Leiterplatten (derzeit in der Luft so 
in ein paar Tagen fällig). Ich habe einige 559T, 559L Chips und 551G 
Chips und die Electrodragon 552, 554 & 559 Boards auch.

Ich habe SDCC, MinGW und make heruntergeladen und funktionieren, aber 
ich habe noch keine 55x Chips programmiert.

Derzeit lese ich mich durch diesen Thread und freue mich darauf, zu 
berichten und zu lernen.

Ray :)

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

[Thomas Z. (usbman)]

Ray you are welcome.

You may write here in English too. Most people here will understand it.

[Ray R. (cluso99)]

Thanks Thomas.

What program are you using to program the CH55x chips (via USB)?
I am using Windows 10 Pro x64.

There seems to be 3a few choices
WCHISPTOOL
WCHPROG
CHPROG

I also found the CH55xOneClickCompiler but haven't downloaded / tried it 
yet.

I am looking for a simple / best way to get into programming these 
chips. I have designed a pcb that will take the CH552/CH554/CH558/CH559 
T versions (SSOP-20 & TSSOP-20) chips for testing these chips which 
shoule be here in a few days.

[Thomas Z. (usbman)]

Ray R. schrieb:
> What program are you using to program the CH55x chips (via USB)?

As long as you are using Win i would go for the WCHISPTOOL. Not because 
its the best tool but it works and installs certified drivers for 
accessing usb.

As far as i know all other tools need libusb therefore you have to lock 
libusb to  the bootloader VID/PID. Usually thats done by zadig. When 
doing so the WCHISPTOOL cant find the chip anymore until you remap the 
driver again.

There are options which can be set only by WCHISPTOOl (RST pin for 
example on CH552 or alternate Boot Pin Option).

CH55xOneClickCompiler is from Aaron here.

My own Flasher which also uses the wch driver is still not ready.

i have put some infos about the CH55x together at
https://github.com/usbman01/WCH-8-Bit-x51-controllers

There you can find headerfiles which are compatible with Keil and SDDC, 
basically they are the same as posted here.

Thomas

[Thomas Z. (usbman)]

One note on your PCB.
WCH sais while flashing VCC should be at 5V. From expierance i know it 
might work in most cases at 3.3V too. So you may omit that switch and 
the LDO unless you want to save power.

According to some posts @3.3V max fSys is 16MHz.

[Ray R. (cluso99)]

Thanks Thomas :)

WCHISPTOOL is working and programming my Electrodragon CH552 board 
nicely.

However, I have a problem with compiling as the code produced is 
completely different to the precompiled hex file.

I then downloaded and tried Aaron's CH55xOneClickCompiler which also 
doesn't produce a correct hex file. I disabled the download in the bat 
file and used the wchisptool instead.

I'm still trying to find the problem. Perhaps the oneclick compiler has 
the wrong paths. I'm not familiar with SDCC or even GCC - I'm more a 
designer and assembler programmer although I do program in python in my 
current day job.

My pcbs arrived today so as soon as I sort this compile problem I cna 
build the boards. Looking forward to this :)

Ray

[Ray R. (cluso99)]

Just a little more info to my compile problem...

I have SDCC v4.1.0 (latest) and also v3.9.3 #11345 (MINGW64). I swapped 
the directory out as I have the PATHs set. Neither compiles the simple 
blink program correctly ie does not compare to the same as the hex file 
provided with the download, and neither compiled programs work after 
downloading. The original hex file does download correctly.

BTW I haven't used SDCC or GCC before so I am a novice here.

Ray

[Thomas Z. (usbman)]

well if you are comparing original hex files from WCH to your own ones 
they are different, because WCH uses KEIL and you use SDCC.

Both versions 3.9 and 4.1 will be ok for you, although 3.9 has a bug 
when it comes to creating libs. Me i am using Keil (prefered) and SDCC 
4.1.
With my own device headers I can compile the source with both compilers.

Do you get any warnings or errors during compilation?
Please post the used cmdline and your blinky.c

[Ray R. (cluso99)]

Thanks Thomas :)

I think I have found the problem. I was testing with a CH552 which I 
assumed to be a subset of CH554. The header file CH554 is being used. 
When I tested with a CH554 chip/board the program worked and the LED(s) 
flashed.

The ch552.h file (downloaded with WCH-8-bit-x51-controllers-master) 
seems quite different from the ch554.h file I was using with the 
CH552oneClickCompiler by Aaron. Keil version???

Seems I will need a CH552.h and debug.h and debug.c to compile for the 
CH552, and similarly for the CH558 & CH559 too.

Is there any common way to use all these chip series with the one set of 
headers?

My PCB can use the 20pin CH552T  CH554T  CH558T / CH559T. Currently I 
only have CH559T chips but was planning to order some of each of these.

I also have some CH551G, CH554E, CH558L and CH559L chips but I haven't 
done pcbs for these yet.

Ray

[Ray R. (cluso99)]

CH554 c program to flash P1.0-1.7 & P3.0-3.5 (14 pins) attached for 
CH554-T TSSOP-20.

I am using Aaron's CH55xOneClickCompiler-master to compile (excluding 
chflasher.exe) an using WCHISPTOOL to flash the code with Enable RST Pin 
unchecked & Run the target program checked.

Note this does not work on CH552 chips - need to get ch552.h working 
with this.

Next:
1. Get serial working
2. Get SPI working (not strictly SPI so will be bit-bashing)


Thanks to Thomas for helping and to Aaron for his CH55xOneClickCompiler 
download :)

[Thomas Z. (usbman)]

Ray R. schrieb:
> The ch552.h file (downloaded with WCH-8-bit-x51-controllers-master)
> seems quite different from the ch554.h file I was using with the
> CH552oneClickCompiler by Aaron. Keil version???

yes that is because this files can work with many compilers. (see 
compiler.h)
I have testet it with Keil, SDCC and IAR. Tasking is still on my todo 
list.
There is however one difference in my files:
I did not include any typedefs like UINT16 or uint16_t because in my 
opinion these should not be part of a device header. In SDCC just 
#include <stdint.h> to have uint16_t....

BTW CH552 and CH554 differ just in one Bit (USB HOST mode) you always 
can use CH554 header files thats save. So your program should work on 
CH552 too.

CH559 is a complete different matter, because some sfrs changed position 
and there are sfrs in xdata space too (LED,USB and others)
I have tried to create some universal header some time ago but have 
decited otherwise, because even on such a header you need to get a 
define from cmdline to choose the right ones. This would make it more 
complex.

That debug.c is originally from WCH and peronally i had never used it, 
but just copied needed funktions to my app. (delay_xx in your case)
Replacing that debug.c by a lib is my actual goal. You can see my 
efforts under https://github.com/usbman01/Replacement-WCHs-debug.c but 
its still incomplete, usage examples are missing, no docs. But there is 
a first build.bat for SDCC.
As you can see there i prefer relative paths.

So i have no idea why your prog does not work on CH552 but we know at 
ALI there are guys selling disfunctional CH552 chips.

[Ray R. (cluso99)]

Thanks Thomas :)

I will try again to use the CH554 hex file on CH552. The boards I'm 
currently using are from Electrodragon - I have a CH552, CH554 and a 
CH559. The chips I have currently are from LCSC but I do have a few 
coming from eBay as they were out of stock at LCSC.

I'll take a look at your replacement debug.c. Perhaps I can help 
although I am not really a C programmer.

Ray

[Thomas Z. (usbman)]

as long as you can access the bootloader you dont have those fakes.

if you want to get rid of that debug.c just copy that delay_us and 
delay_ms
into you main.c and remove debug.c from your batch.

[Ray R. (cluso99)]

Thomas,

The working code for CH554 will not work on CH552. I know the CH552 
works because I can program it with an pre-compiled blink.hex file and 
it does report the downloaded CH554 code as successful. I am not sure 
where to look.

I compared the CH554.h file with the WCH CH552.h file and noticed that 
there was a #define ID_554 0x54 so I tried adding #define ID_CH552 0x52 
but that did not work. All registers and bit definitions are the same so 
that's not the problem.

I simplified the code. Here is the compile info
C:\SDCC\OneClick>compile006
+ SDCC\bin\sdcpp.exe -nostdinc -Wall -std=c11 -I"/" 
-D"FREQ_SYS=24000000" -obj-ext=.rel -D__SDCC_CHAR_UNSIGNED 
-D__SDCC_MODEL_LARGE -D__SDCC_FLOAT_REENT -D__SDCC=3_9_3 
-D__SDCC_VERSION_MAJOR=3 -D__SDCC_VERSION_MINOR=9 
-D__SDCC_VERSION_PATCH=3 -DSDCC=393 -D__SDCC_REVISION=11345 
-D__SDCC_mcs51 -D__STDC_NO_COMPLEX__=1 -D__STDC_NO_THREADS__=1 
-D__STDC_NO_ATOMICS__=1 -D__STDC_NO_VLA__=1 -D__STDC_ISO_10646__=201409L 
-D__STDC_UTF_16__=1 -D__STDC_UTF_32__=1 -isystem 
"SDCC\bin\..\include\mcs51" -isystem "SDCC\bin\..\include"  "main006.c"
+ SDCC\bin\sdas8051.exe -plosgffw "main006.rel" "main006".asm
+ SDCC\bin\sdld.exe -nf "main006.lk"
packihx: read 18 lines, wrote 25: OK.
hex2bin v1.0.1, Copyright (C) 1999 Jacques Pelletier
Lowest address = 00000000
Highest address = 0000010F

C:\SDCC\OneClick>

And the zipped files are attached. Any help would really be appreciated 
as I don't know where to look :)

BTW I found an error in debug.c that comes with Aaron's 
CH552OneClickCompiler. This line
#elif FREQ_SYS == 26000000
  CLOCK_CFG = CLOCK_CFG & ~ MASK_SYS_CK_SEL | 0x05;  // 16MHz
should be
#elif FREQ_SYS == 16000000
  CLOCK_CFG = CLOCK_CFG & ~ MASK_SYS_CK_SEL | 0x05;  // 16MHz

[Ray R. (cluso99)]

Oops. Forgot the zip file.
Ray

[Thomas Z. (usbman)]

wow what a complicated cmd line in that batch most of it is not needed.
I will check that and upload a simplified batch.
I can understand why beginners with c give up when they see that.
Aaron uses the large model which is not neccessary in most cases, 
especially on such a simple program.

I will come back later. first need to look for Aarons debug.c

[Thomas Z. (usbman)]

this ch554.h just can work if compiler.h is in the include path, which i 
guess is not for your installation.
It seems a mix of my own header files and the original WCH ones. The 
echo off may cover all warnings and errors.

[Thomas Z. (usbman)]

Ray, that hex file you postet works perfectly P1.4 is blinking. I did 
simulate that in Keil.
Here a more simplified compile batch for the small mode. That hex is 
also working. So i actually dont know whats wrong. Whatever the problem 
is its neither the compiler nor the main.c.

[Ray R. (cluso99)]

Thanks Thomas.
Your compile.bat is much simpler. I didn't want to mess with it too much 
until everything is working.

The .hex file I posted works on the CH554 but doesn't work on the CH552.

I can download good hex files to the CH552 so I know both the WCHISPTOOL 
and the CH552 board are working.

However, the .hex file(s) that I compile only work on the CH554 but not 
on the CH552.

Do you have a real CH552 and if so, could you please try this program? 
It should flash P1.4 and P3.3.

Thanks,
Ray

[Thomas Z. (usbman)]

ok I will setup one of my boards (Aarons stick) and test it this 
evening.
Here its 10 AM. But guess you are in very differnt timezone so it wont 
matter for you.

[Ray R. (cluso99)]

Thanks Thomas.
Yes it’s now 10:30pm here - Sydney, Australia. We’re GMT+10. We FaceTime 
our daughter and her family who live in London most nights so I’m 
familiar with time zones.
Ray

[Ray R. (cluso99)]

I looked at the hex file to see what is happening. There is setup code 
that is not in the listing $0006-$005E and $$00D4-$00D8 that I decoded. 
I'm not quite sure what it is doing yet. I also noticed that the 
register _SAFE_MOD $A1 (safe mode) is being set by the main.c code 
multiple times.

Now I need to learn 8051 assembler code. I have written lots of 
assembler code for various micros over the last 45 years so it shouldn't 
be a problem.

[Ray R. (cluso99)]

The instructios at $0055 were wrong
            90  mov   DPTR,#0x0001
            00
            01
            E4  clr   A
            F0  movx  @DPTR,A
            A3  inc   DPTR
:04 005B 00 D8  djnz  R0,0xfc

[Ray R. (cluso99)]

Problem Solved :)

The CH552 board had the wrong link soldered. The 3V was joined to VSS 
instead of 5V. I was sure that I had successfuly programmed this board 
but I must have been mistaken.

Thanks for your help Thomas and sorry for wasting your time.

Are you still programming with these CH55x chips? If so, which ones and 
what are you doing with them?

[Thomas Z. (usbman)]

The asm code you posted is part of the c-startup, I would not think to 
much about it.
I am using CH552 mostly for various USB applications. (MIDI  CDC  
MSC). 2 projects already reach the comercial state. Because of the 
security flaws in V1 and V2.3 bootloader i developed my own loader with 
some extras to replace the V1.1 loader. For new chips with 2.4 loader 
this is no longer neccessary.

For development i am using my own 48 Pin CH559 breakout board. WCH has 
some intersting other chips including ARM / RISC but currently most of 
them are not available.
I started with ASM 40 years ago but these days i use c and c++. Its just 
a hobby now although i have no problem with making some extra money with 
it. :-)

[Peter (Gast)]

Bei solchen Riesen-Threads hat ja jeder das Problem, keinen Durchblick 
mehr zu haben und neue Einsteiger in den Thread müssten erstmal 3 
Stunden lang lesen. Ich kann es auch nicht leiden, wenn die gleichen 
Fragen immer wieder kommen, nur weil die Leute zu faul zu Lesen sind ... 
aber das ist hier mittlerweile so viel Text, dass das unmöglich ist.
Daher verzeiht bitte, wenn ich jetzt nicht mehrere hundert Posts 
durchlesen möchte um die Frage evtl. beantwortet zu bekommen: kann der 
Controller als USB Host agieren, so dass ich eine Tastatur oder Barcode 
Scanner anschließen kann und die empfangenen Infos (also gedrückte Taste 
/ gescannten Datenblock) per UART ausgeben kann? Gibt es da schon 
fertigen Code für?
Danke!

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

Moin.

Dies kann der CH554, CH558 und CH559

Für den CH559 habe ich mit Bitluni einen code für genau dein vorhaben 
erstellt.

https://youtu.be/Th88RiSmj2w

[Peter (Gast)]

Ohh super! Das Video schaue ich mir heute Nachmittag mal an.
Jetzt wollte ich mal eben sehen, wo ich die WCH µC herbekomme ..... kann 
es sein, dass man die hier in Europa nirgends kaufen kann? Selbst Ebay 
zeigt mir nichts. Klar bei Ali, aber dauert ja Wochen...

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

Hätte sonst noch ein paar die ich abgeben kann.

Ca. 20 x CH559 und diverse (300 x ) nicht usb host fähige CH552

[Ray R. (cluso99)]

Aaron,
What were you planning with all those CH552’s?
Are they CH552T?

I just received my pcbs back which take CH552/4/8/9 T versions.

Has anyone checked to see if the CH340 is just a preprogrammed CH551-4?

Ray

[Ray R. (cluso99)]

Peter,
I have just read through the whole thread. Lots of good info but took a 
while to read through it!
Ray

[Ray R. (cluso99)]

Thomas,
Nice. I work 2 days/week programming in python. I don’t know much about 
C or C++.
For the past 10 years I’ve been playing with the Parallax propeller P1 
and P2 chips. They are 8 core 32-bit micros. The P2 has 512KB shared RAM 
plus 4KB RAM per core and we’re overclocking to 360MHz.
Ray

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

@Ray

I just bought them without any reason, they where just cheaper that way

The ones i got are the CH552G, the ones from the first image of this 
thread.

The CH340 / Series is a fully different chip, there are DIE shots and a 
bit of RE available in the web.

[Ray R. (cluso99)]

Here are my basic CH55xT boards, and the boards I building to use them.

[Ray R. (cluso99)]

Oops. Adding the second jpg cancelled the first. This is the basic 
CH55xT board.

[Ray R. (cluso99)]

I found this website by Christian where you can do pinout diagrams.
https://christianflach.de/ic-pinout-diagram-generator/
I have emailed Christian the code to add the CH552 family. There is a 
problem with the CH552P QFN pinout. Here is a pic of the pinouts

[Ray R. (cluso99)]

Today I did the pinout diagrams for the CH340 series, the CH551G, 
combined the CH552/4 series, and the CH558/9 series.
Hopefully they will be on the website soon :)

[Ray R. (cluso99)]

Thomas,
Now that I have the latest SDCC compiler v4.1.0 working for both CH552 
and CH554 I have been looking at debug.h and debug.c and CH554.h.

I recall you saying you wanted to tidy debug up. To me (not a GCC/SDCC C 
programmer) it seems that debug is not really debug, but rather a few 
utility routines.

What are your thoughts as I don't want to reinvent the wheel? I can do 
something here to help if you would like, before I get too involved with 
coding my project.

BTW I found these typos in debug.h. I am not sure where these fixes 
should be posted.
#ifndef  UART0_BUAD
#define  UART0_BUAD    9600
#endif

#ifndef UART1_BAUD
#define  UART1_BUAD    9600
#endif

BUAD should be BAUD in 3 places.

Ray

[Thomas Z. (usbman)]

Ray, this debug.c comes from from WCH, including all typos and limits. I 
guess originally the main purpose was to have printf ready for debug 
outputs on UARRT0.
The clock & baudrate are setup by defines which means fixed consts at 
compile time. If you change clock during runtime for some reason, 
neither uart nor delay will work correctly.

The main reason why i dont use debug.c is because under Keil you get 
warnings about unused functions. Not a real problem but i always fix my 
code until no warnings pop up.

BTW That usage of debug.c for printf does not work anyway under SDCC out 
of the box, because under SDCC putc is not part of the std lib. In keil 
a putc version is linked to the code if printf is used for sending the 
output to UART0. So for SDCC you have to provide your own putc to get 
printf ready.

There is one more thing:
If you check the reload calculations for the baudrate. They use a long 
div which is a very bad idea on a 8 bit controller stupid since they 
just use a div by 10.

I have not worked on my debug.lib for the last too weeks. I know there 
are still some flaws in the SDCC asm parts which needs to be fixed. I 
still did not figure out how i have to handle params for the large mode.

[Ray R. (cluso99)]

Thomas. Thanks for your info.
I'm not sure what you suggest I do. I don't have Keil so I'm stuck with 
SDCC.

Debug.c needs to be compiled with SDCC separately.

Should I create a new library folder for CH55x and place the library in 
it?
Split debug.c (and debug.h) into separate files (CH554config and 
CH554serial and CH554wdtTimer) ie For the basics - CfgFsys, mDelayus, 
mDelayms and put the UART routines into another file and Timer/Watchdog 
into a third file?

Place CH554.h and CH559.h into this folder too?

Ray

[Thomas Z. (usbman)]

well as i said i dont use that debug.c at all. My controller usually 
work at the default fSys (6MHz) so i just copy those 2 delay functions 
to main and set #define  FREQ_SYS 6000000L. So i have no neet for 
CfgFsys().

When it comes to serial com i setup the UART manually (UART1). For the 
Reload values I use the spread sheet from my repro.

I just once had a case up to now on the ch559 where i had change fSys to 
48MHz to speedup some descrampling. For that i just changed the clock 
for this function and fall back to the default when finished.

As for CH554.h or CH559.h I have them local in \inc which means i need 
to copy  them always into the local project. Others prefer to have those 
files in SDCC\inc directory. Then you always can do a #include <CH554.h> 
instead of some #include ".inc\CH554.h"

But these are all my preferences. You also simply can use debug.c but 
dont forget to use -DFREQ_SYS=%dfreq_sys% when compiling debug.c

[Ray R. (cluso99)]

Here is my try at conditional compiling the various routines in debug.c.
What I tried was to use #define in the main file (blink4.c) but it does 
not pass through to my debug.c/h replacement (ch554_lib.c/h) so I needed 
to compile using -Dxxx parameters.

[Ray R. (cluso99)]

I also tried splitting debug.c/h into config.c/h delay.c/h uart0.c/h 
uart1.c/h wdtm.c/h but in the end I wasn't happy with this.

[Ray R. (cluso99)]

As I mentioned a few posts back, I have done the CH55x family pinouts. 
They are now live soif you find any errors please let me know.
Christian has done a fantastic job to take a javascript definition and 
render them in pictures.

https://christianflach.de/ic-pinout-diagram-generator/

[Thomas Z. (usbman)]

Ray R. schrieb:
> I also tried splitting debug.c/h into config.c/h delay.c/h uart0.c/h
> uart1.c/h wdtm.c/h but in the end I wasn't happy with this.

yes and that tons of ifdefs are not the best way to handle this problem. 
This is where a real lib may be a better solution. Just put every single 
function in an extra file compile them and create a lib containing all 
that functions.

The linker will just include functions used in the app. Problem solved.
Check my example. The functions are named a bit different because 
functions also behave a little different. For example my delay functions 
currently just take 8 bit params and maybe they still need some 
finetune.

I am still not sure if i should uses the same names.
That multible definitions you will get comes from my own compiler.h. It 
seems there is something wrong with my sfr16 makro for SDCC. for now you 
may just ignore it. I will soon update the git repro.

[Ray R. (cluso99)]

Thanks for posting this Thomas. I will take a look tonight and report 
back.
Did you take a look at the pinout diagrams?

[Thomas Z. (usbman)]

Ray, note this lib is not very well tested, there might still be bugs 
inside.
At this time its more like a proof of concept. That fastcopy functions 
will work in smal model only.
Yes i checked that pinouts nice work.

[Thomas Z. (usbman)]

Thomas Z. schrieb:
> That multible definitions you will get comes from my own compiler.h. It
> seems there is something wrong with my sfr16 makro for SDCC.

here is modified version of the lib with no warnings. I need to update 
my compiler.h

[Thomas Z. (usbman)]

Ich habe heute die Debug Lib vervollständigt und auch das Keil 
Projektfile hochgeladen. Es ist nun möglich die Lib für Keil und SDCC zu 
bauen.

Ich würde mich über Tests aber auch Kritik / Verbesserungsvorschläge 
freuen.

Einen Haken hat die Sache noch ich hatte mich beim Anlegen mit dem 
Ordner vertippt, CH544 anstelle von CH554. Ich bin leider noch ein 
ziemlicher Nob was Gid angeht. Ich hab noch nicht rausgefunden wie man 
ein Verzeichnisname ändert.

https://github.com/usbman01/Replacement-WCHs-debug.c

Nachtrag: vieleicht kennt jemand hier einen Weg wie man sdar ein 
controlfile mitgeben kann. Ich bin da nicht so recht schlau geworden wie 
das geht. Das würde die überlange zeile in der Batch verhindern.

[Ray R. (cluso99)]

This will partially reduce the line length

set s=..\obj\sdcc\
sdar -rc %s%ch554_debug_SDCC.LIB %s%clksetup.rel %s%wdtchange.rel 
%s%wdtfeed.rel %s%wdtstart.rel %s%wdtstop.rel %s%delayms.rel 
%s%delayus.rel %s%pwm1_alt.rel %s%pwm2_alt.rel %s%uart0_alt.rel 
%s%uart1_alt.rel %s%fastxcopy.rel %s%fastccopy.rel %s%simpleuart.rel 
%s%uart0_24M.rel %s%uart0_16M.rel %s%uart0_12M.rel %s%uart0_12M.rel 
%s%uart0_6M.rel %s%uart0_3M.rel %s%uart0_750k.rel %s%initstdio.rel

BTW The ch554_debug_SDCC.LIB you posted 2 posts back seems to compile 
unused routines in the hex file. Is there a way to not include unused 
routines?

[Ray R. (cluso99)]

Or try this - the ' ^\n\t' cases a continuation followed by newline and 
a tab.

sdar -rc ^
  ..\obj\sdcc\ch554_debug_SDCC.LIB ^
  ..\obj\sdcc\clksetup.rel ^
  ..\obj\sdcc\wdtchange.rel ^
  ..\obj\sdcc\wdtfeed.rel ^
  ..\obj\sdcc\wdtstart.rel ^
  ..\obj\sdcc\wdtstop.rel ^
  ..\obj\sdcc\delayms.rel ^
  ..\obj\sdcc\delayus.rel ^
  ..\obj\sdcc\pwm1_alt.rel ^
  ..\obj\sdcc\pwm2_alt.rel ^
  ..\obj\sdcc\uart0_alt.rel ^
  ..\obj\sdcc\uart1_alt.rel ^
  ..\obj\sdcc\fastxcopy.rel ^
  ..\obj\sdcc\fastccopy.rel ^
  ..\obj\sdcc\simpleuart.rel ^
  ..\obj\sdcc\uart0_24M.rel ^
  ..\obj\sdcc\uart0_16M.rel ^
  ..\obj\sdcc\uart0_12M.rel ^
  ..\obj\sdcc\uart0_12M.rel ^
  ..\obj\sdcc\uart0_6M.rel ^
  ..\obj\sdcc\uart0_3M.rel ^
  ..\obj\sdcc\uart0_750k.rel ^
  ..\obj\sdcc\initstdio.rel

[Thomas Z. (usbman)]

Ray R. schrieb:
> BTW The ch554_debug_SDCC.LIB you posted 2 posts back seems to compile
> unused routines in the hex file. Is there a way to not include unused
> routines?

i guess you mean the various delayus variants. I dont see a way to not 
include them at this time, because of the way the function is designed.

As you can see I just use the Clk register to determine which delayus 
will be used. So therefore i have to include all variants. Until now the 
750Khz delay and 187khz delay are missing and give no acurate response.

[Deqing (Gast)]

Aaron C. schrieb:
> Hello.
>
> The CH554, CH558 and CH559 can do this
>
> For the CH559 I have a code with Bitluni for exactly your project
> created.
>
> https://youtu.be/Th88RiSmj2w

I'm sharing the lesson I learned about the USB host. DO NOT USE it 
without a crystal. The internal oscillator is not accurate enough and 
some peripheral (especially AVR V-USB) will not send ACK back to host. 
This has been confirmed with the FAE.

[Thomas Z. (usbman)]

Deqing schrieb:
> The internal oscillator is not accurate enough and some peripheral
> (especially AVR V-USB) will not send ACK back to host. This has been
> confirmed with the FAE.
thanks for that Info, I know some of that threads at WCH but i cant 
confirm that. I build a host based on a CH559 and could successfully 
enumerate a memory stick. No problem with datatransfer too.

AVR V-USB ist a lowspeed device timing ist completely done in firmware. 
Maybe its a problem on LS devices or V-USB itself.

Even WCH sells preprogramed chips with hostmode and without xtal CH9350

[Deqing (Gast)]

Thomas Z. schrieb:
> Deqing wrote:
>  > The internal oscillator is not accurate enough and some peripheral
>> (especially AVR V-USB) will not send ACK back to host. This has been
>> confirmed with the FAE.
> thanks for that info, I know some of that threads at WCH but i cant
> confirm that. I build a host based on a CH559 and could successfully
> enumerate a memory stick. No problem with datatransfer too.
>
> AVR V-USB is a low-speed device timing is completely done in firmware.
> Maybe its a problem on LS devices or V-USB itself.
>
> Even WCH sells preprogramed chips with hostmode and without xtal CH9350

I guess the V-USB only sample 1 time for each bit while hardware USB 
samples more times each bit. With my test, a CH549 with 1.4% clock error 
dit not get any ACK. A CH549 with 0.6% clock error got ACK at the 6th 
request. A CH549 with 0.3% clock error got ACK every time.

I did not get such issue with another USB peripheral so it may not be a 
common problem.

[Thomas Z. (usbman)]

Deqing i am interested on the bootloader of the CH549. Could you do me a 
favour and read out code from 0xF400 to 0xFFFF and post a binary here or 
send it to my git email account. As you might know i am intersted on 
those loaders and these chips are not available right now.
That would be great

[Deqing (Gast)]

Thomas Z. schrieb:
> Deqing i am interested on the bootloader of the CH549. Could you
> do me a
> favor and read out code from 0xF400 to 0xFFFF and post a binary here or
> send it to my git email account. As you might know i am intersted on
> those loaders and these chips are not available right now.
> That would be great

I can help with that and I got multiple CH549. Do you have a code 
dumping the flash so I can save some time writing one?

[Thomas Z. (usbman)]

Deqing schrieb:
> I can help with that and I got multiple CH549. Do you have a code
> dumping the flash so I can save some time writing one?

thanks that will be great. I will prepare some code tomorrow to dump it 
via Uart0 in ascii. Here its already 8 pm. So you just need to connect a 
serial converter to uart0 and open some terminal.

[Thomas Z. (usbman)]

Hello Deqing,
i compiled a simple dumper in keil. If i did not make any mistake it 
should dump the the bootloader to UART0 @ 57600 8N1 in ascii.
The zip contains the complete keil project, but you may simply use 
dumper.hex

Thanks

[Deqing (Gast)]

Thomas Z. schrieb:
> Hello Deqing,
> i compiled a simple dumper in keil. If i did not make any mistake it
> should dump the the bootloader to UART0 @ 57600 8N1 in ascii.
> The zip contains the complete keil project, but you may simply use
> dumper.hex
>
> Thanks

Not sure why the code did not generate anything meaningful on UART, I 
guess it is the baudrate issue. I rewrote the code in Arduino with CDC 
anyway.

All CH549 chips I have prints the same thing with a lot of 0 between 
F400 and FBFF. I guess it may be protected?

[Thomas Z. (usbman)]

mm thanks for the dumping. As for CH549 this cant be the complete 
loader. I think you are right seems they disabled movc from 0xF400 to 
0xFC00. I dont see any other way to dump this.
The b formater is special to Keil. The intersting thing is that this 
loader is bigger than the other ones. I have already a 2.4 from the 
CH554.

I wonder what will be dumped with E_DIS=1. Maybe a dump from 0x0000 to 
0xFFFF.

[Deqing (Gast)]

Thomas Z. schrieb:
> mm thanks for the dumping. As for CH549 this cant be the complete
> loader. I think you are right seems they disabled movc from 0xF400 to
> 0xFC00. I dont see any other way to dump this.
> The b formater is special to Keil. The intersting thing is that this
> loader is bigger than the other ones. I have already a 2.4 from the
> CH554.
>
> I wonder what will be dumped with E_DIS=1. Maybe a dump from 0x0000 to
> 0xFFFF.

It doesn't help much.

[Thomas Z. (usbman)]

Deqing schrieb:
> It doesn't help much.

ok seems this is a new core then, that simple aproaches dont work. 
Anyway thanks for your help. Maybe i can figure out something later.

[Deqing (Gast)]

Thomas Z. schrieb:
> Deqing schrieb:
>> It doesn't help much.
>
> ok seems this is a new core then, that simple aproaches dont work.
> Anyway thanks for your help. Maybe i can figure out something later.

I also tried to use the A6 verify command to dump the data. 
Unfortunately even with the data on 0xFC00, the A6 command did not 
respond OK. So I think there must be some protection as well.

[Thomas Z. (usbman)]

Deqing schrieb:
> I also tried to use the A6 verify command to dump the data.
> Unfortunately even with the data on 0xFC00, the A6 command did not
> respond OK. So I think there must be some protection as well.

Well A6 does not work anymore in the Bootloader aera in V2.4 they fixed 
that. I could compile a V2.3 from CH559 to a different start address and 
do a fix that it would report itself as a CH559. But i am not so shure 
If that would help.
If they disabled movc there ist no way i can think of.

Further that matches with some confirmation at the WCH bbs where one guy 
said calling the bootloader manually does not work on CH549.

[Peter (Gast)]

Aaron C. schrieb:
> -8051 Kern mit den Meisten Standard Register, befehlen usw. nur 10-15x
> Schneller

In Zeiten von ARM Cortex M braucht das kein Mensch mehr.

Es sei denn, man hat schon einen 5k Euro IAR-Compiler.

[Thomas Z. (usbman)]

I did some disassembly on 0xFC00 and that part follows the general 
patterns i know from the other V2.4 loader.

Even the vars are at the same places.
some addresses:
- 0xFBCA : main
- 0xFC79 : mainloop
- 0xFCA7 : Serial Dispatcher
- 0xFD32 : FlashProgPage
- 0xFD8D  : Keil rand()
- 0xFE23 : PrepareUsbPaket()
- 0xFE5A : CopyDescPaket()
- 0xFE8E : Keil ?C?CLDPTR
- 0xFEA7 : Keil ?C?CSTPTR
- 0xFEB9 : FlashErasePage()
- 0xFED4 : C_Startup
- 0xFEE0 : Uart0Rx()
- 0xFEEB : Uart0Tx()

A educated guess might be that 0xF400 and 0xF800 range is only activated 
as long as bBOOT_LOAD ==1 which means just on PwrOnReset cleared on 
SoftReset.

Since the FlashInterface is very different from the CH559 i am hoping 
that it might be possible to change some bits from 0 to 1 in the unused 
part starting at 0xFEF5. If that is possible it simply means that last 
segment is not protected. Otherwise there is no way and the chips are 
secure.

if thats working there would be the place for an attack. I need to find 
some of that chips.

[Thomas Z. (usbman)]

Ich hab mir einen neuen Stick auf Basis des CH552 gebaut. Die Platine 
enthält die So16 Variante der CHxxx chips 2 Leds und eine Stiftleiste 
die entsprechend der WCH-Link Platine belegt habe. auf der Unterseite 
gibts optional einen 3.3V Regler sowie ein SPI Flash.
Die Platine ist mit Eagle designed, da ich aber gerade dabei bin auf 
KiCad umzustellen, hab ich das mal in KiCad importiert. Bis auf ein paar 
Bauteil Bezeichner, die ich manuell verschoben hatte, entspricht das 
Layout weitgehend dem Eagle Original.

Als erstes habe ich meinen Midi Source und ein DualCDC portiert, beides 
funktioniert unter Keil schon mal. Es ist auch das erste mal dass ich 
meine debug lib verwendet habe (Uart1Alt(), fastccpy()). Zwar keine 
große Sache zeigt aber dass ich mit der Lib auf dem richtigen Weg bin.

Für die USB Midi Funktion versuche ich mir gerade ein FW Update via 
SysEx zu bauen, die Idee dabei ist eine 2. Kopie im Flash 
bereitzuhalten, die CRC zu testen und dann je nach Ergebnis beim Start 
die FW auszutauschen.

[Harald (Gast)]

Ich wollte mal etwas mit der USB-Host Funktion des CH559 spielen, habe 
mir einige Tutorials dazu angesehen. Während ich auf die HW warte mal 
drei Fragen dazu an die CH55x-Spezialisten:

1. Mir fällt auf, dass die Host-Designs alle ohne Quarz sind. 
USB-Devices ohne Quarz sind ja keine Seltenheit, beim Host habe ich das 
aber noch nicht gesehen. Ist der interne Oszillator so gut oder müssen 
die Slaves einfach mit der Abweichung leben? Bei einem Device ohne Quarz 
kann ich mir das gut vorstellen, bei einem Device mit Quarz hingegen 
weniger.

2. An einem CH559 im SSOP20 habe ich nur einen USB-Port, oder habe ich 
da etwas übersehen?

3. Kann ich an der USB-Serial Software zwei USB-Geräte gleichzeitig 
anschließen und die werden beide zum UART übertragen?

Vielen Dank!

[Thomas Z. (usbman)]

Harald schrieb:
> Ist der interne Oszillator so gut oder müssen
> die Slaves einfach mit der Abweichung leben?

Ich hab vor einiger Zeit mal auf dem CH559 einen Host gebaut der einen 
Memory Stick enumeriert das hat problemlos ohne quarz funktioniert. 
Falls du da Bedenken hast kannst du ja einen ext Quarz benutzen und die 
PLL passend einstellen, hab ich allerdings noch nie gemacht.

zu 2: ja nur ein Port

zu 3. verstehe ich nicht

[Harald A. (embedded)]

Hallo Thomas,
Vielen Dank für deine Antworten. Es ist nicht so, dass ich mich um einen 
Quarz reißen würde - es hat mich nur gewundert. Ich denke mal, dass es 
in gewissen Grenzen ganz gut ohne Quarz funktioniert, im Zweifel sollte 
man wahrscheinlich besser einen Quarz einbauen.

Zu 3. - ich meinte diesen Source hier:
https://github.com/MatzElectronics/CH559sdccUSBHost
Ich habe mir das Video von Aaron aber nochmal genau angeschaut und er 
packt ja tatsächlich zwei USB-Geräte an den CH559. Also funktionieren 
zwei USB Devices gleichzeitig.

[Thomas Z. (usbman)]

Harald es gibt Hinweise, dass V-USB Probleme an einem Host ohne Quarz 
hat, Deqing hat weiter oben was dazu geschrieben. Aaron und ich haben 
das bei Devices mit HW USB nicht bemerkt.
Das Beispiel von Aaron kenne ich nicht im Detail. Der CH559 besitzt 
keinen Hub man muss also manuell zwischen den beiden Host Ports 
umschalten. Es gibt nur einen gemeinsamen Registersatz für beide Host 
Ports.
WCH hat übrigens auch einen Controller mit integriertem HUB. CH555 der 
wohl weitgehend vom CH556/7 abgeleitet ist. Diese Teile sind relativ neu 
und noch nicht allgemein verfügbar.

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

Hier ist der code von dem genannten beispiel
https://github.com/atc1441/CH559sdccUSBHost/blob/master/USBHost.c

[Harald A. (embedded)]

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. 
Danke auch für die Erläuterung mit dem Hub. Im verlinkten Source wird ja 
dauernd vom RootHubPort gesprochen, meint dann aber offensichtlich in 
diesem Zusammenhang etwas anderes.

Völlig bekloppt an dem Teil ist ja die Tatsache, dass man ausgerechnet 
einen der Quarz-Anschlüsse für den Download auf GND ziehen muss. Damit 
führt man schön die HF spazieren und ggf. noch auf einen Taster zur 
„verbesserten“ Abstrahlung.

[Thomas Z. (usbman)]

Harald A. schrieb:
> Völlig bekloppt an dem Teil ist ja die Tatsache, dass man ausgerechnet
> einen der Quarz-Anschlüsse für den Download auf GND ziehen muss. Damit
> führt man schön die HF spazieren und ggf. noch auf einen Taster zur
> „verbesserten“ Abstrahlung.

na ja zu dem Zeitpunkt beim PowerOn Reset ist das ein ganz normaler Port 
Pin. Der Controller läuft auf dem internen Oszilator, Ich glaube 12MHz.
Das ganze FW Update läuft via internal Oszilator. Erst deine Anwendung 
gibt dann den ext Oszi frei und setzt die PLL. WCH empfiehlt danach etwa 
10 ms zu warten bis das alles stabil läuft. Einen Taster wirst du nur in 
der Debug Version haben üblicherweise ist da einfach an Jumper gegen 
GND. Aufpassen must du nur wenn statt dem quarz ein Oszilator verwendet 
wird.
Erst deine FW macht aus P4.6 den XI.

Zum Verständniss:
Beim PowerOn Reset und nur da wird anstelle des ResetVectors (0x000) 
nach 0xF400 zum Bootloader gesprungen. Ich vermute dass da einfach das 
BootloaderSegment nach 0x000 gespiegelt ist.
Das ist natürlich Spekulation, deckt sich aber mit Erkenntnissen aus 
Experimenten mit Reset Pin und den Config Registern.