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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Harald schrieb:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Das->Dass)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zwei Anmerkungen/Fragen zum Schaltplan:

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

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

Gruß
Thomas

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

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

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

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

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

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

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


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

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

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


Gruß
Thomas

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kleines Board das aussieht wie ein ISP-Dongle.

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

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

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

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

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

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

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

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

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

Folgendes ist mir aufgefallen:

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

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

Source folgt sobald die ASM Datei ordentlich formatiert ist.

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

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

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

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

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

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

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

Gruß
Thomas

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

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

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

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

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

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

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

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

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

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

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

1

void mem_cpy (uint8_t *dest,uint8_t *src,uint8_t len)

2

{

3

   while(len--) *dest++ = *src++;

4

}

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

Effektiver wäre folgende Variante:

1

void mem_cpy (uint8_t xdata *dest,uint8_t code *src,uint8_t len)

2

{

3

   while(len--) *dest++ = *src++;

4

}

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

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

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

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

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

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

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

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

Gruß
Thomas

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

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

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

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

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

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

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

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

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

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

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

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

RiscV Mikrocontroller von WCH für 10ct:

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

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

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

• PWM_CK_SE := 0 -> PWM_CK = FSYS/256
• PWM_CK_SE := 1 -> PWM_CK = FSYS/1
• PWM_CK_SE := 2 -> PWM_CK = FSYS/2
• ....

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

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

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

Gruß, SIGINT

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

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

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

Andreas M. schrieb:

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

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

In USB Terms < 64 bytes sind Shorttransfer (automatisch terminiert) = 64 Bytes braucht ein ZLP um das Ende zu erkennen

64 Bytes ist ein 64 Byte Transfer + Rest

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

Thomas Z. schrieb:

In USB Terms < 64 bytes sind Shorttransfer (automatisch terminiert) = 64 Bytes braucht ein ZLP um das Ende zu erkennen

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

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

Hab was interesanntes gefunden :-)

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

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

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

Barzotto T. schrieb:

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

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

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

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

There go front and back pictures with NOR pins identified.

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

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

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

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

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

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

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

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

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

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

Ich habe dann den Bootloader disassembliert und einige ungewöhnliche Dinge gefunden.

1. Der 2.0 Loader benutzt das V1.1 Kommando Interface.
2. Der Loader benutzt Interrupts (serial, usb, T0)
3. Es gibt tatsächlich keinen Test auf leeres Flash
4. Die Benutzung von D+ als Bootpin ist im Loader nicht vorgesehen

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

Hier ein kleines Projekt für die dunkle Jahreszeit:

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

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

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

Vorstellbar ist eine Nutzung auch als SPI bridge.

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

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

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

Aaron C. schrieb:

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

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

Max M. schrieb:

einen USB-Stick "vorgaukeln"

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

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

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

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

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

Hallo Thomas,

dein usbasp-Klon funktioniert prima:

1

Processing -U flash:w:MultiIO.hex:i

2

Reading 10694 bytes for flash from input file MultiIO.hex

3

Writing 10694 bytes to flash

4

Writing | ################################################## | 100% 1.93s

5

Reading | ################################################## | 100% 1.75s

6

10694 bytes of flash verified

7

8

Processing -U efuse:w:0xFF:m

9

Reading 1 byte for efuse from input file 0xFF

10

Writing 1 byte (0xFF) to efuse, 1 byte written, 1 verified

11

12

Processing -U hfuse:w:0xD9:m

13

Reading 1 byte for hfuse from input file 0xD9

14

Writing 1 byte (0xD9) to hfuse, 1 byte written, 1 verified

15

16

Processing -U lfuse:w:0xFF:m

17

Reading 1 byte for lfuse from input file 0xFF

18

Writing 1 byte (0xFF) to lfuse, 1 byte written, 1 verified

19

20

Avrdude done.  Thank you.

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

Jochen D. schrieb:

dein usbasp-Klon funktioniert prima:

danke für deine Rückmeldung. Ich hätte noch ein paar Fragen:

• Welche Version von avrdude benutzt du?
• Welche Atmel Controller hast du geflasht?
• Hat es bei dir sofort funktioniert (ohne Treiber Install)

• Welche Version von avrdude benutzt du?

avrdude 8.0

• Welche Atmel Controller hast du geflasht?

Atmega324PB

• Hat es bei dir sofort funktioniert (ohne Treiber Install)

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

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

Thomas Z. schrieb:

Ich tue mich noch etwas schwer mit dem TPI Modul

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

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

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

ich habe das Projekt mal auf Github eingestellt.

https://github.com/usbman01/CH552_usbASP

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

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

Hallo Thomas.

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

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

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

Vielleicht hilft Dir das Beispiel etwas weiter bei Makefiles.

Gruss Tom

Habe noch ein Beispiel vergessen:

1

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

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

Tom A. schrieb:

Habe noch ein Beispiel vergessen

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

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

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

Gruss. Tom

Guten Tag,

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

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

Noch ein paar Gedanken/Informationen:

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

Christian E. schrieb:

• Bootloader-Version: 2.40

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

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

Thomas Z. schrieb:

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

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

Thomas Z. schrieb:

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

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

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

• Ich will mich nicht /softlocken/.

Christian E. schrieb:

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

• Ich will mich nicht softlocken.

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

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

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

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

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

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

Thomas Z. schrieb:

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

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

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

Christian E. schrieb:

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

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

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

Ich hab jetzt meinen CH552 basierten ISP so erweitert, das er jetzt auch die PIC18FxxQ41 programmieren kann. Der Code ist noch recht rudimentär aber tut was er soll.

Thomas Z. schrieb:

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

Hi Thomas! Any news on the 2.40 bootloader? I was thinking of erasing a small chunk of memory to reset the bWrProtect bit and then loading a program to print a memory dump, but the bootloader doesn't accept values ​​lower than 8, so we'll lose most of the dump.

Sergiy schrieb:

Hi Thomas! Any news on the 2.40 bootloader?

no, in fact meanwhile i think there is no way to dump the firmware for v2.4 and v2.5 bootloaders.