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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Aaron C. (Firma: atcnetz.de) (atc1441)


Angehängte Dateien:

Lesenswert?

Moin, da es Leider noch sehr wenig über die WCH Mikrocontroller im web 
zu finden gibt, erst recht nicht im Deutschen raum würde ich hiermit 
einen Thread eröffnen und ein wenig drauf aufmerksam zu machen.
Falls es was zu meckern gibt immer her damit :), heute ist aber nicht 
Freitag...

Es gibt eine Mikrocontroller Serie von der Firma WCH mit integriertem 
USB und auch USB Host für wenig Geld wie z.b. der CH552 oder CH554.

Bei LCSC gibt es sie in stock: https://lcsc.com/products/WCH_11013.html


Die Mikrocontroller haben einen von Werk aus Programmierten USB 
Bootloader also lassen sie sich ohne weitere Hardware programmieren.

Vielen wird der CH340 ein Begriff sein da dieser auf vielen China 
Arduino Clones usw. als USB zu UART Wandler eingesetzt wird.

Hier einige Eckdaten vom CH552:
-8051 Kern mit den Meisten Standard Register, befehlen usw. nur 10-15x 
Schneller
-Integrierter Oszilator bis 24Mhz
-3x Timer
-2x 8bit PWM
-1x SPI Master/Slave
-2x UART
-4x ADC 8bit
-6x Touch Input
-16K ROM
-1K xRAM
-256b iRAM
-i2c ist per Bitbanging kein Problem(Beispiel vorhanden)



Der CH554 Kann zusätzlich noch USB Host und DMA.

Zum Betrieb wird eigentlich nur eine 3.3-5V Spannungsquelle, ein 20KOhm 
Widerstand und 2 Kondensatoren benötigt.

Hier wird die Serie etwas genauer Beschrieben:
https://www.electrodragon.com/w/WCH#MCU_.2B_USB_CH55x_Series

zudem gibt es hier einige demos für Keil:
https://github.com/Edragon/WCH

hier weitere Demos für SDCC inkl. compilier Anleitung für Windows und 
Linux:
https://github.com/Blinkinlabs/ch554_sdcc


In einer Nächtlichen Langweile habe ich mal einige CH554G 
Mikrocontroller bestellt und mich nun etwas mehr damit beschäftigt,
Habe jegliche Hardware ansprechen können und mir eine kleine Platine bei 
JLCPCB angefertigt, anbei noch ein Paar Bilder.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Das klingt interessant. Danke für den Hinweis!

von Tim  . (cpldcpu)


Lesenswert?

Viel zu teuer, über 0.05USD kommt mir keine neue MCU ins Haus. :)

Ich warte noch darauf, dass die Chinesen etwas anderes als PIC and 8051 
kopieren. Immerhin gibt es auch schon einen günstigen CM0 bei LCSC. 
Allerdings ist ein STM32F030 auch schon für 0.3X USD zu haben.

von Tim  . (cpldcpu)


Lesenswert?

Was ist denn der Unterschied zwischen dem 551 und 554? Letzterer ist 
deutlich teurer.

von Doctor Snuggles (Gast)


Lesenswert?

Am interessantesten ist:

"Bugs

    The IC only can be flashed up to 200 times, please notice this.
"

Ansonsten ist die MCU ja nicht so interessant. Hat nix, was andere und 
besser dokumentierte AVRs oder Cortexe nicht haben.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

WCH hat auch 32-Bit-MCUs mit ARM-Kern, wie z.B. den CH563.

Ein (natürlich chinesisches) Datenblatt gibts hier:
https://datasheet.lcsc.com/szlcsc/Jiangsu-Qin-Heng-CH563L_C87387.pdf

Auch ohne Chinesischkenntnisse kann man dem folgendes entnehmen:

ARM5TE, 224K Flash, 64K SRAM, 28K Dataflash, 10/100MBit-NIC, USB2.0 und 
die übliche Peripherie (2 16550-kompatible UARTs, 4 Timer, diverse I/Os, 
SPI).

Im 128poligen TQFP-Gehäuse kostet der dann bei LCSC aber "richtig" Geld, 
nämlich auch in der 6000er-Staffel mehr als 3 USD.

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


Lesenswert?

Tim  . schrieb:
> Was ist denn der Unterschied zwischen dem 551 und 554? Letzterer ist
> deutlich teurer.

Der CH551 hat nur 10K ROM und der CH554 hat 16K ROM zusätzlich noch USB 
Host, das unterscheidet eigentlich am meisten.

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

Bei dem CH554 kann man wider rum Geräte anschließen. also z.b. eine 
Tastatur oder Maus an den Mikrocontroller und der ließt diese dann aus 
und macht sache X bei bestimmten tastendruck auf der Tastatur.

Doctor Snuggles schrieb:
> Am interessantesten ist:
>     The IC only can be flashed up to 200 times, please notice this.

in einem Russischen Forum hat einer ein dauer test gemacht und mehr als 
1000 mal beschrieben ohne Probleme.

: Bearbeitet durch User
von Einer K. (Gast)


Lesenswert?

Tim  . schrieb:
> Ich warte noch darauf, dass die Chinesen etwas anderes als PIC and 8051
> kopieren.

Suche mal nach:
LGT8F88A
LGT8FX8D
MD-328D

In wie weit das Kopien sind, mag ich nicht beurteilen wollen.
Aber der AVR-GCC kompiliert dafür.

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


Lesenswert?

Habe gerade noch ein Video auf YouTube hochgeladen wo ich die 
Mikrocontroller etwas in nicht ganz gutem English erkläre.

https://www.youtube.com/watch?v=IDCQNa2ywiM

: Bearbeitet durch User
von Bastler (Gast)


Lesenswert?

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

Schneller als der Ur-8051 oder aktuelle Versionen?
Von Silabs hab ich vor über 10 Jahren einen eingesetzt der auch nur 1-2 
Clocks/Instruction benötigt.
Zugegeben ist der teurer als 0,20€.

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


Lesenswert?

im Datenblatt steht 8 bis 15 Mal schneller als der Standard mcs51 würde 
also von dem Original ausgehen.
Die ch Reihe läuft zusätzlich ja noch mit max 24 Megaherz also noch mal 
doppelt so schnell

: Bearbeitet durch User
von Guido Körber (Gast)


Lesenswert?

STM8 und STM32 sind in ähnlichen Preislagen, dafür gibt es dann auch 
lesbare Doku ;)

von Harald A. (embedded)


Lesenswert?

Guido Körber schrieb:
> STM8 und STM32 sind in ähnlichen Preislagen, dafür gibt es dann auch
> lesbare Doku ;)

Man sollte das doch einfach als Wissensbereicherung sehen (oder auch 
nicht). Microcontroller aus China werden uns in der nächsten Zeit 
vermehrt über den Weg laufen und eine Konkurrenz zu den Etablierten 
bilden. Das darf man in einem Forum wie diesem doch gerne vorstellen, 
oder nicht? Ich denke es war nicht die Absicht des TE hier den heiligen 
Gral vorzustellen, der alles Andere in den Schatten stellen soll.

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


Lesenswert?

Harald A. schrieb:
> Ich denke es war nicht die Absicht des TE hier den heiligen
> Gral vorzustellen, der alles Andere in den Schatten stellen soll.

Danke, so ist es.


Und zu der Doku, es gibt eine Übersetzung ins Englische und zudem kann 
man die Standards des 8051 einfach übernehmen.

Der Chip ist super für einfache Dinge mit USB, könnte ihn mir auch 
vorstellen als eine USB Bridge für esp8266 oder esp32.

von Harald A. (embedded)


Lesenswert?

Hallo Aaron,
gibt es hier noch neue Erkenntnisse? Hast du das Projekt weiter 
verfolgt? Dem Foto nach hast du davon ja einige verarbeitet.

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


Lesenswert?

Harald A. schrieb:
> Hallo Aaron,
> gibt es hier noch neue Erkenntnisse? Hast du das Projekt weiter
> verfolgt? Dem Foto nach hast du davon ja einige verarbeitet.

Moin, naja habe leider noch keinen super Einsatzzweck gefunden, es bahnt 
sich da aber eine Modellbau LED Steuerung an bei der 10 Leds in 
verschiedensten mustern leuchten sollen und neue muster per USB 
geschrieben werden können.
Dafür ist der Chip perfekt.

Also am Ball bleibe ich aufjedenfall, habe den 8051 ziemlich gut 
durchschaut und habe viel mit dem "Projekt" gelernt was interrupt, 
timmer etc angeht.

Leider ist bei so wenig Interesse anderer die Lust weniger geworden.

Grüße

: Bearbeitet durch User
von Harald A. (embedded)


Lesenswert?

Persönlich finde ich den CH554 interessant, denn für wenige Cent gibt es 
USB Host/Device Unterstützung, das ist schon ein Alleinstellungsmerkmal.

Forum-Disclaimer: Mir ist sehr klar, bei welchen Stückzahlen sich das 
lohnt bzw. nicht lohnt. Und ich weiß auch, dass es zahlreiche andere uCs 
mit ähnlichen/besseren Features gibt. Mich interessiert das trotzdem, 
insbesondere asiatische Produkte. Danke für das Verständnis!

von Mehmet K. (mkmk)


Lesenswert?

Aaron C. schrieb:
> Leider ist bei so wenig Interesse anderer die Lust weniger geworden.

Ich bin sicher, dass viele so wie ich mit Interesse Deine Beitraege 
lesen. Aus meiner Sicht waere es schade, wenn das Ganze im Sande 
verlaufen würde. Auch wenn ich für diesen Chip keine Verwendung habe: 
interessant finde ich ihn allemal.
Nochmals Danke für Deine bisherigen - und hoffentlich zukünftigen - 
Beitraege

von Peter D. (peda)


Lesenswert?

Aaron C. schrieb:
> Also am Ball bleibe ich aufjedenfall, habe den 8051 ziemlich gut
> durchschaut und habe viel mit dem "Projekt" gelernt was interrupt,
> timmer etc angeht.

Ja, beim 8051 kann man schnell mit neuen Derivaten einsteigen. Das 
nötige include File mit den SFR-Definitionen für den Keil oder 
Wickenhäuser zu schreiben, ist ja kein Ding.
Der CH558L mit 12Bit-ADC sieht interessant aus. Und 32kB Flash sind ja 
beim effizienten 8051-Core geradezu riesig.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

Der 559 sieht auch sehr interessant aus.
Mit integriertem RootHub.
Entweder 2 Hosts hat man dann oder 1 Host und 1 Slave.

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


Lesenswert?

Mehmet K. schrieb:
> Aaron C. schrieb:
>> Leider ist bei so wenig Interesse anderer die Lust weniger geworden.
>
> Ich bin sicher, dass viele so wie ich mit Interesse Deine Beitraege
> lesen. Aus meiner Sicht waere es schade, wenn das Ganze im Sande
> verlaufen würde. Auch wenn ich für diesen Chip keine Verwendung habe:
> interessant finde ich ihn allemal.
> Nochmals Danke für Deine bisherigen - und hoffentlich zukünftigen -
> Beitraege


Vielen dank für die Netten Worte :)



ich fand den CH552 gerade wegen dem Preis super interessant, der CH554 
ist schon wieder so "Teuer", jedoch der CH551 mit dem 10Kb speicher 
wieder zu klein.

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


Angehängte Dateien:

Lesenswert?

Guten Abend,


habe mich nun nochmal mit dem Mikro beschäftigt und dabei ist ein USB 
Tastatur Emulator bei raus gekommen, Quasi ein USB Rubber Ducky.

Dabei wird viel der vorhandenen Hardware genutzt, die Touch Sensoren, 
der Timer, software bootloader eingang und natürlich die USB 
pheripherie.

hier ein Video darüber: https://youtu.be/cSYMe4xyGeo

zudem habe ich ein Blog eintrag erstellt dieser beinhaltet aber im 
grunde alles was hier steht: http://atcnetz.de

von Harald (Gast)


Lesenswert?

Ich habe die Links nicht alle durchgearbeitet, könntest du mir kurz 
sagen, ob das alles mit SDCC kompiliert wurde?

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


Lesenswert?

Harald schrieb:
> Ich habe die Links nicht alle durchgearbeitet, könntest du mir kurz
> sagen, ob das alles mit SDCC kompiliert wurde?



Bis  auf die USB-Stick Speicher Geschichte wurde alles mit sdcc 
kompiliert
Beim sdcc SDK ist aber auch ein Python Script dabei mit dem man die Keil 
Dateien größtenteils sdcc kompatibel machen kann also selbst das sollte 
kein Hindernis sein

von Sigint 112 (sigint)


Lesenswert?

Nabend zusammen,
  hab mir jetzt auch mal ein paar von den Teilen bestellt. Ich habe 
gesehen, daß der Bootloader wohl auch Seriell unterstüzt, beim CH552. 
Hat damit schon jemand erfahrungen gesammelt? Ich würde die Software 
gerne per WINE nutzen und das geht leider nicht, wegen der Treiber. 
Seriell ist dagegen kein Problem. Leider sind die Chips noch nicht 
angekommen. :-|
Mich würde auch interessieren, wie man den Chip flashen kann, sollte der 
Bootloader zufälligerweise defekt sein... hat jemand na Ahnung, ob es 
irgendwo dazu infos gibt? Ich hab bis jetzt noch nicht viel zu der 
Chipreihe gefunden.

Gruß,
   Sigint

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


Lesenswert?

Sigint 1. schrieb:
> Nabend zusammen,
>   hab mir jetzt auch mal ein paar von den Teilen bestellt. Ich habe
> gesehen, daß der Bootloader wohl auch Seriell unterstüzt, beim CH552.
> Hat damit schon jemand erfahrungen gesammelt? Ich würde die Software
> gerne per WINE nutzen und das geht leider nicht, wegen der Treiber.
> Seriell ist dagegen kein Problem. Leider sind die Chips noch nicht
> angekommen. :-|
> Mich würde auch interessieren, wie man den Chip flashen kann, sollte der
> Bootloader zufälligerweise defekt sein... hat jemand na Ahnung, ob es
> irgendwo dazu infos gibt? Ich hab bis jetzt noch nicht viel zu der
> Chipreihe gefunden.
>
> Gruß,
>    Sigint

Moin, habe mal die Serielle Programmierung versucht bin da aber nicht zu 
Erfolgs Ergebnissen gekommen.

Hier gibt es aber ein open Source Tool um die Chips auch in Linux über 
USB zu schreiben: https://github.com/rgwan/librech551

Das Protokoll ist eigentlich auch super simpel und kann einfach 
nachgebaut werden, habe mir überlegt eine Android App zu schreiben um 
auch mit dem Handy Uploaden zu können.

Der Bootloader ist fest im Chip eingebrannt und kann nicht Kaputt 
gemacht werden oder zerflasht werden. bzw, das schafft man nur wenn man 
es wirklich will.

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



Lesenswert?

Habe direkt mal mit der Android App Angefangen, erste erfolge sind zu 
sehen.

Kann mittels des Kommandos dafür über USB den Chip identifizieren.

Auch aus dem Bootloader ins normale Programm starten geht mittels 
Kommando.

Anbei ein Bild vom ersten versuch. die 52 ist der Identifier für den 
CH552

von Bernd K. (prof7bit)


Lesenswert?

Tim  . schrieb:
> Ich warte noch darauf, dass die Chinesen etwas anderes als PIC and 8051
> kopieren.

GigaDevice klont einige STM32 (heißen dann GD32xxxxx) und zwar machen 
die das mit so einer Hingabe und Inbrunst daß sie sogar eigene 
Handbücher dafür schreiben (komplett neu geschrieben, alles mit eigenen 
Worten formuliert, neue Tabellen und Diagramme gemalt, etc.) und auch 
eine selbstgeschriebene Standard Peripheral Library mit ausliefern.

von Thomas (Gast)


Lesenswert?

@Aaron
Ich finde die Chips schon sehr interesant, vorallem der CH552 sieht gut 
aus.
Ich hätte hier auch eine Anwendung als Ersatz für nicht mehr lieferbare 
Controller von Cypress. (AN2131)
Das Problem ist aber ein Datenblatt zu finden. Der link auf Github ist 
auch tot. Auserdem scheint was mit dem rar file auf deiner Seite nicht 
zu stimmen.

Thomas

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


Lesenswert?

Thomas schrieb:
> @Aaron
> Ich finde die Chips schon sehr interesant, vorallem der CH552 sieht gut
> aus.
> Ich hätte hier auch eine Anwendung als Ersatz für nicht mehr lieferbare
> Controller von Cypress. (AN2131)
> Das Problem ist aber ein Datenblatt zu finden. Der link auf Github ist
> auch tot. Auserdem scheint was mit dem rar file auf deiner Seite nicht
> zu stimmen.
>
> Thomas


Mhh das mit dem rar File habe ich gerade nochmal probiert, das ist so 
richtig.
Es muss vorher die SDCC Umgebung, wie hier 
beschrieben:https://github.com/Blinkinlabs/ch554_sdcc, erfolgreich 
installiert sein und danach muss man den Inhalt in die SDCC Ordner 
einfügen.

Womit hattest du da Probleme?

Hier: 
https://github.com/Blinkinlabs/ch554_sdcc/blob/master/documentation/CH554%20manual%20english.pdf
Gibt es das Datenblatt per Google auf Deutsch Übersetzt. es ist das für 
den CH554 aber es ist bis auf den USB Host teil komplett gleich.

von Thomas (Gast)


Lesenswert?

Aaron C. schrieb:
> Womit hattest du da Probleme?

ich konnte dein Rar File zwar runterladen aber nicht öffnen. Ich hab das 
mehrmals probiert.

Ich habe den SDCC zwar installiert aber die Performance ist halt immer 
noch deutlich schlechter als der Keil. Zuletzt hab ich das mit meinen 
TEA Routinen erst wieder überprüft. Ergebnis: 30 % mehr code und ca 20% 
sclechtere Laufzeit. Zusätzlich besitze ich auch den Wickenhäuser 
Compiler aber der ist ja sowas von tot und auch noch schlechter als der 
SDCC.

Auserdem spiele ich immer mal wieder mit dem Turbo51 Pascal Compiler. 
Das ist aber mehr eine Spielerei (Ich habe vor vielen Jahren mal mit 
Pascal angefangen :-) ). http://turbo51.com

Im Moment kämpfe ich mich durch die chinesische Webside, da werde ich 
wohl meine Kontakte nach China aktivieren müssen.

Thomas

von Peter D. (peda)


Lesenswert?

Thomas schrieb:
> Zusätzlich besitze ich auch den Wickenhäuser
> Compiler aber der ist ja sowas von tot und auch noch schlechter als der
> SDCC.

Komisch, ich meine mich zu erinnern, daß er gegenüber dem SDCC als 
besser optimierend beworben wurde.
Daß ein Compiler nicht mehr weiter entwickelt wird, schränkt in keinster 
Weise seine Verwendbarkeit ein. Ich benutze einen Keil C51 von 1995.

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


Lesenswert?

Habe die Datei nun nochmal als zip hochgeladen, einfach auf der Seite 
erneut runterladen.

Die SDCC Umgebung ist denke ich nicht sonderlich optimiert und deswegen 
so "schlecht" bin aber dennoch glücklicher damit, da keil ja leider 
nicht kostenlos verfügbar ist.

Zudem ist die Android App fertig und kann hier vom Google Playstore 
runtergeladen werden: 
https://play.google.com/store/apps/details?id=com.atcnetz.de.ch55xprogrammer

sie ist derzeit nur mit bin Files kompatibel aber man kann die hex 
Dateien ja zu bin umwandeln, denke ist gant hilfreich wenn man mal 
schnell eine andere Firmware flachen will. Wird sich schon ein nutzen 
finden :D

Dazu hier auch noch ein kurzes Video: https://youtu.be/rFKiSagsnLs

von Thomas (Gast)


Lesenswert?

Peter D. schrieb:
> Komisch, ich meine mich zu erinnern, daß er gegenüber dem SDCC als
> besser optimierend beworben wurde.

Ja die Werbung... Er hat auch behauptet besser zu sein als Keil. War 
wohl sein Wunschtraum. Ebenso die Garantie das er sichergestellt hat das 
man seinen Compiler immer aktivieren kann. Die 100 Euro jedenfalls hätte 
ich mir damals sparen können.

Ich geb dir aber recht. Am Keil hat sich seit den Dos v3 Versionen jetzt 
nicht so viel geändert.

Thomas

von Thomas (Gast)


Lesenswert?

Aaron C. schrieb:
> Habe die Datei nun nochmal als zip hochgeladen, einfach auf der Seite
> erneut runterladen.

Dank dir das ZIP kann ich öffnen

Thomas

von Thomas (Gast)


Lesenswert?

Im übersetzten Datenblatt fehlen leider die beiden für mich wichtigsten 
Kapitel über die InSystem Programmierung des Fash Roms (6.4  6.5)
ich habe mir deshalb das Original Datenblatt beschafft und diese 
Abschnitte mal übersetzt. Das Englisch der Google Übersetzung it zwar 
etwas seltsam aber durchaus verständlich.
Ich werde das mal meinem Bekannten zeigen. Vieleicht kann der mir noch 
ein paar Hinweise geben. Er ist allerdings nicht vom Fach kann also 
nichts zur Technik sagen.
So wie ich das verstanden habe werden beim Flash Rom immer 16 Bit 
programmiert. Unklar ist mir noch welches Byte des ROM_DATA Registers 
dabei an den geraden Addressen landet.

Thomas

von Andreas R. (daybyter)


Lesenswert?

Mit dem USB Host und dem günstigen Preis könnte man mit dem 554 z.B. 
einen Adapter bauen, um USB Joysticks/pads an Retro Computer wie den c64 
anzuschließen?

von Peter D. (peda)


Lesenswert?

Hat schonmal jemand den Keil PK51 von Silabs ausprobiert?
Wenn man sich registriert, bekommt man den product key.

https://www.silabs.com/products/development-tools/software/8-bit-8051-microcontroller-software#keil

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Thomas schrieb:
> Das Englisch der Google Übersetzung it zwar etwas seltsam aber durchaus
> verständlich.

Nimm deepl. Das übersetzt um Längen besser als Google, es kennt nur 
deutlich weniger Sprachen.

https://www.deepl.com/translator

von Christoph M. (mchris)


Lesenswert?

>Autor: Aaron C. (Firma: atcnetz.de) (atc1441)

Du bist auf Hackaday:
https://hackaday.com/2019/02/17/how-to-program-a-really-cheap-microcontroller/

Mittlerweile glaube ich ja fast, dass Hackaday das MC-Netz mit liest.

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


Lesenswert?

Christoph M. schrieb:
>>Autor: Aaron C. (Firma: atcnetz.de) (atc1441)
>
> Du bist auf Hackaday:
> https://hackaday.com/2019/02/17/how-to-program-a-really-cheap-microcontroller/
>
> Mittlerweile glaube ich ja fast, dass Hackaday das MC-Netz mit liest.

:D Ja denke auch das dort bestimmt welche hier mitlesen, diesmal hab ich 
da aber selber drauf hingewiesen und einen sehr netten Kontakt mit einem 
"Hackadayer" gehabt.

von Thomas (Gast)


Lesenswert?

Rufus Τ. F. schrieb:
> Nimm deepl. Das übersetzt um Längen besser als Google, es kennt nur
> deutlich weniger Sprachen.

Chinesisch ist da hält nicht dabei

Thomas

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Thomas schrieb:
> Chinesisch ist da hält nicht dabei

Hrgmrnmpf. Mistverdammter. Ich hatte aus irgendeinem Grund den Eindruck, 
Du wolltest was aus dem Englischen ins Deutsche übersetzen --- da wäre 
Deepl von Vorteil. Aber natürlich, WCH-Datenblätter sind verm. auf 
Mandarin geschrieben ...

Vergiss' also das geschriebene.

von Mehmet K. (mkmk)


Lesenswert?

Peter D. schrieb:
> Hat schonmal jemand den Keil PK51 von Silabs ausprobiert?
> Wenn man sich registriert, bekommt man den product key.

Diese Frage lag auch mir auf der Zunge :)

von Sigint 112 (sigint)


Lesenswert?

@Aaron: Wow... der Android Flashloader ist ja wirklich klasse :-D 
Schade, daß ich von Androidprogrammierung nicht wirklich viel Ahnung 
habe... hätte gerne einen C-Compiler für die 8051er in Android. Einen 
Assembler gibts ja schon. :-)

@Thomas: Wenn ich das richtig lese, dann kann man die CH55x auch ohne 
Bootloader ISP flashen. Wäre interesannt das Protokoll zu haben... 
leider hab ich nichts gefunden. Auf der Webseite gibts auch keine 
passende Hardware.
Aber selfprogramming scheint wohl machbar zu sein. Damit könnte man 
wahrscheinlich den Bootloader von innen heraus tauschen.
Möglicherweise kann man den internen Flash wie ein SPI-Flash 
ansprechen... werd das mal testen, wenn die Chips angekommen sind.

@Anreas R: Die Idee mit dem C64-Adapter ist cool... mit Pegelwandler 
sollte das doch machbar sein :-D

von Thomas (Gast)


Lesenswert?

ich bin wir inzwischen sicher wie das Schreiben ins Flash Rom und ins 
Datenflash funktioniert. Die Google Übersetzung des Original Datenblatts 
für den 552 hat mich weitergebacht. Das Vorgehen ist wie schon 
geschrieben In Kapitel 6.4 und 6.5 beschrieben. Und genau diese 
Abschnitte fehlen ja im oben genannten PDF.
Ich werde  vermutlich morgen abend eine englische Beeschreibung hier 
einstellen.

Soviel vorab:
- Das Flash wird 16 Bit weise beschrieben, start immer an geraden 
Addressen.
- Ob das Flash vorher gelöscht werden muss hab ich noch nicht gefunden
- im Moment gehe ich von einem Autoerease aus.
- Das Flash geht bis 0x3FFF ab 0x3800 liegt der Bootloader.
- Solange ein Byte programmiert wird die Codeausführung angehalten
- Wenn man also den Bootloader nicht braucht kann man den überschreiben

Thomas

von Thomas (Gast)


Lesenswert?

Mehmet K. schrieb:
> Peter D. schrieb:
>> Hat schonmal jemand den Keil PK51 von Silabs ausprobiert?
>> Wenn man sich registriert, bekommt man den product key.
>
> Diese Frage lag auch mir auf der Zunge :)

ja das geht du hat halt dann nur Silabs devices. Der Compiler is aber 
nicht eingeschränkt nur halt nicht die aktuellste Version. Das spielt 
aber keine Rolle solange man eigene Headerfiles benutzt.

Wie sch schon geschrieben habe hat sich am compiler selbst nich mal 
soviel seit den DOS Zeiten geändert. Der Simulator und die Debug 
Möglichkeiten sind der eigentliche Hit.
Die Einschränkungen liegen in der Datenbank (Bequemlichkeit) und der 
Simulator kann halt nicht mehr zyklen genau arbeiten wenn du was anderes 
als Silabs benutzt.
Er ist aber immer noch besser als alles andere was ich bisher gesehen 
habe.

Thomas

von Bernd K. (prof7bit)


Lesenswert?

Sigint 1. schrieb:
> hätte gerne einen C-Compiler für die 8051er in Android.

Alle Schaltjahre stolpere ich mal über ein Posting wo sich jemand sowas 
(oder was vergleichbar bizzarres) wünscht. Ich frag mich dann jedesmal 
wozu in aller Welt sollte jemand ein Verlangen danach danach verspüren 
auf dem Handy auf dem noch nicht mal ne vernünftige Tastatur vorhanden 
ist C zu programmieren?

"OK, Google: uint8_t m = ((uint8_t*)&a)[i++ * 4] >> s;"

???

Ich persönlich finds wesentlich entspannter gemütlich am Tisch zu sitzen 
mit ner greifbaren Tastatur und mehreren großen Bildschirmen und einer 
frei einteilbaren Tastatur/Maus/Fenster-Oberfläche.

Bitte erhelle mich, was ist der Zweck eines C-Compilers auf einem 
hochgradig auf einhändigen (zweifingrigen) Medienkonsum optimierten 
System?

: Bearbeitet durch User
von Goodwill (Gast)


Lesenswert?

Bernd K. schrieb:

> Alle Schaltjahre stolpere ich mal über ein Posting wo sich jemand sowas
> (oder was vergleichbar bizzarres) wünscht.

2019 ist kein Schaltjahr.

> "OK, Google: uint8_t m = ((uint8_t*)&a)[i++ * 4] >> s;"

Statt des WorldWideWebSnoopers(WWWS) nimmt man duckduckgo.com.

> Bitte erhelle mich, was ist der Zweck eines C-Compilers auf einem
> hochgradig auf einhändigen (zweifingrigen) Medienkonsum optimierten
> System?

Android gehört zum WWWS, also nur offline verwenden.

von Peter D. (peda)


Lesenswert?

Thomas schrieb:
> ja das geht du hat halt dann nur Silabs devices.

Das betrifft dann aber nur den Debugger und Simulator.
Compilieren kann der Keil ausnahmslos jedes 8051 Derivat. Nur die 
Spezialfeatures sind dann eingeschränkt, z.B. Banking ab >64kB.

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

hier wie versprochen die Übersetzung zusammen mit etwas code. Da ich 
noch keine Chips habe ist das nur eine Trockenübung Fehler sind nicht 
ausgeschlossen.

Thomas

von Thomas (Gast)


Lesenswert?

Peter D. schrieb:
> Das betrifft dann aber nur den Debugger und Simulator.
> Compilieren kann der Keil ausnahmslos jedes 8051 Derivat. Nur die
> Spezialfeatures sind dann eingeschränkt, z.B. Banking ab >64kB.

genau aber mal ganz dumm gefragt:
Hast du banking auf einem 8051 jemals benutzt? Und damit meine ich nicht 
jetzt sondern vor 20 Jahren?

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


Lesenswert?

Thomas schrieb:
> hier wie versprochen die Übersetzung zusammen mit etwas code. Da ich
> noch keine Chips habe ist das nur eine Trockenübung Fehler sind nicht
> ausgeschlossen.
>
> Thomas

Danke dafür :), aber mal eine Frage zu dem Code, damit schreibt sich ja 
das Programm selber in den Flash, möchtest du damit den Bootloader 
tauschen? man muss ja sowieso schon das Programm geflasht haben damit es 
sich selber flashen kann ?!

Grüße

von Peter D. (peda)


Lesenswert?

Thomas schrieb:
> Hast du banking auf einem 8051 jemals benutzt? Und damit meine ich nicht
> jetzt sondern vor 20 Jahren?

Nein, noch nie.
Mein größtes Programm ist über viele Jahre auf ~48kB angewachsen.

Ich wollte damit auch nur ausdrücken, daß alle 8051 sehr sauber 
zueinander kompatibel sind. Der Compiler muß also gar nicht wissen, 
welches Derivat er compilieren soll. Zusätzliche SFRs kann man ganz 
einfach in einem h-File definieren.

Z.B. bei den AVRs sieht das ganz anders aus. Die unterscheiden sich 
durchaus im Befehlssatz und anderen Dingen, die der Compiler wissen muß.

von Thomas (Gast)


Lesenswert?

Aaron C. schrieb:
> Danke dafür :), aber mal eine Frage zu dem Code, damit schreibt sich ja
> das Programm selber in den Flash, möchtest du damit den Bootloader
> tauschen? man muss ja sowieso schon das Programm geflasht haben damit es
> sich selber flashen kann ?!

Nun die kurze Antwort ist ganz einfach: Das Programm kann sich nicht 
programmgesteuert selbst überschreiben.
Nun die Lösung: Es gibt auf dem Chip 2 Programme. Das ist kein Problem 
und ein Bootloader macht das ja ganz genauso. Der Trick an der Sache 
sind die Interrupt Vectoren. Einfach verlängern geht nicht.
Der Bootloader kommt nur genau einmal während der Inbetriebnahme zum 
Einsatz. Danach ist er gesperrt oder vieleicht sogar üeberschrieben 
falls der Speicherplatz nicht ausreicht.
Danach muss sich das Device selbst über irgend einen Kanal updaten 
können. Bei einem USB Device bietet sich ja an, ein FW update per USB 
einzuspielen.

Ich hab das in der Vergangenheit schon ein paar mal gemacht (u.A mit 
einem 89c51RB2). Dazu werden alle Interrupt Vectoren die in beiden 
Programmen verwendet werden nicht mehr direkt aufgerufen, sondern die 
Vectoren werden dynamisch zugewiesen. Es gibt für jeden Vektor dazu 2 
Bytes im DATA seg. Die bei beiden Programmen an genau der gleichen 
Stelle liegen. Ich benutze dazu den Speicherplatz der 3. Registerbank 
(0x18) da haben dann 4 Vectoren Platz.
Den C Compiler muss man dazu anweisen keine Irq Einträge zu erzeugen das 
wird manuell in einem ASM file gemacht.

Beispiel mit dyn Interrupt (ext Irq 0) Der Updater liegt bei 0x0000 der 
Appcode irgendwo im Speicher
1
dseg    at 18h          ;must be the same address in BOOT
2
                        ;and App Code
3
irq0vect: DS 2  
4
5
CSEG at BOOT
6
        LJMP Init         ;c startup code
7
org  Boot +3h             ;ext irq 0
8
        PUSH  irq0vect+1  ;2 cycles LSB first  
9
        PUSH  irq0vect+0  ;2 cycles   
10
        RET               ;2 cycles never do a RETI here
11
        ;....
12
org  Boot +23h
13
        LJMP AppCode +23h ;SIO is used only in App
14
        ;...
Bevor nun irgendwelche Interrupts aktiviert werden müssen alle dyn. 
Vectoren initialisiert werden. In c beispielsweise mit
  irq0_vect = &Irq0Isr;
Beide Brogramme können ganz normal in C geschrieben werden Sie werden 
einfach auf unterschiedliche Startaddressen gelinkt. Bis eine 
Interruptroutine angesprungen wird dauert es ein paar Zyklen länger. Die 
App Firmware wird dann in Boot ins Flash geschrieben

Thomas

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


Lesenswert?

Thomas vielen dank für deine doch sehr ausführliche antwort.

Ich glauhe ich verstehe nun deinen grund, für mich persönlich wäre diese 
lösung aber zu aufwendig.

Es gibt ja so die möglichkeit via programm in den Bootloader zu gehen in 
dem man adresse 0x3800 direkt anspringt, dort kann ja das firmware 
update stattfinden und man geht zurück ins normale programm.
Wenn wieklich der platz zu klein wird kann man ja immer noch die nächst 
grössere variante nehmen mit mehr speicher.

Denke aber natürlich das dort jeder seine eigenen vorlieben hat.

Ein software update über eine funk verbindung oder ähnliches wäre damit 
aber natürlich deutlich einfacher bzw. Überhaupt Möglich.


Im übrigen hat WCH auch ein Forum in dem auch gut was an beispielen zu 
verfügung gestellt wird. Ist auf Chinesich aber google übersetzt es doch 
ausreichend.

http://www.wch. * cn/bbs/thread-65023-1.html

Sternchen wegnehemen, .cn ist hier wohl nicht erlaubt.

: Bearbeitet durch User
von Mehmet K. (mkmk)


Lesenswert?

Die Beispiele beziehen sich auf CH558 und CH559; keine Ahnung, ob man 
diese bei den günstigen CH552 oder CH554 1:1 benutzen kann.
Wenn nicht, kommt man preislich in die Naehe von Silabs-MCUs.

LCSC     CH559L    1St. 1,60 USD
Digikey  C8051F385 1St. 2,29 USD

Kleiner Hinweis: der STM32F072C8 ist bei Aliexpress schon für 1 USD zu 
haben.

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


Lesenswert?

Mehmet K. schrieb:
> Die Beispiele beziehen sich auf CH558 und CH559; keine Ahnung, ob man
> diese bei den günstigen CH552 oder CH554 1:1 benutzen kann.
> Wenn nicht, kommt man preislich in die Naehe von Silabs-MCUs.
>
> LCSC     CH559L    1St. 1,60 USD
> Digikey  C8051F385 1St. 2,29 USD
>
> Kleiner Hinweis: der STM32F072C8 ist bei Aliexpress schon für 1 USD zu
> haben.


Achso hätte ich vielleicht noch erwähnen sollen, die sind untereinander 
alle recht kompatibel, ausser wenns natürlich um beispiele geht die 
hardware verwendet die der CH552 z.b. nicht hat. wie usb host Funktion.

Hatte soweit auch alle Beispiele einmal getestet und zu SDCC portiert, 
dabei z.b. Dataflash lesen/schreiben, PWM, SPI, TouchKey, ADC usw. noch 
garnicht angesehen hatte ich mir die USB-C funktion, glaube damit kann 
man auch die Ladepower von USB-Ladegeräten umschalten und sowas aber da 
bin ich mir nicht so sicher.

Kann auch noch diese datei: 
http://www.wch.*cn/download/CH554EVT_ZIP.html empfehlen.
Dort sind auch noch sehr gute Hardware beispiele dabei.

Inkl. express versand hatte ich pro stück damals 0,25€ gezahlt, waren 
aber auch 400 Stück :D

von Mehmet K. (mkmk)


Lesenswert?

Aaron C. schrieb:
> ... waren aber auch 400 Stück

Zum Erfolg-Haben verdammt :)

von Thomas (Gast)


Lesenswert?

Aaron C. schrieb:
> Es gibt ja so die möglichkeit via programm in den Bootloader zu gehen in
> dem man adresse 0x3800 direkt anspringt, dort kann ja das firmware
> update stattfinden und man geht zurück ins normale programm.

das ist auch für das Development vollkommen ok. Bei einem kommerziellen 
Device geht sowas schon aus Sicherheitsgründen nicht. Niemand auser dem 
Hersteller des Devices sollte in der Lage sein einfach mal so irgend 
welche FW auf die HW aufzuspielen. Es ist also ein Muss den Bootloader 
abzuschalten. Ich benutze für FW updates gerne die HID Schnittstelle.

Noch ein paar Hinweise zu meinem Code. Die Klimmzüge mit den Odd 
Addressen
sind sehr wahrscheinich gar nicht notwendig. Ich habe Hinweise gefunden 
dass der Chip wohl kein Autoerase hat und wohl Page weise gelöscht 
werden muss.
(PageSize 2k??). Wenn dem so ist kann man sich das Klimbim sparen.

Ich hab mal WCH dazu angeschrieben mal schauen ob da was kommt.

Thomas

von Bernd K. (prof7bit)


Lesenswert?

Thomas schrieb:
> Niemand auser dem
> Hersteller des Devices sollte in der Lage sein einfach mal so irgend
> welche FW auf die HW aufzuspielen.

Man will doch eher das Auslesen verhindern damit keiner mal eben ohne 
Aufwand Klone auf den Markt werfen kann.

Aber ob einer imstande ist sein gekauftes Gerät zu schrotten oder zu 
einer Kaffeemaschine umzufunktionieren indem er komplett eigene Firmware 
dafür schreibt sollte doch dem Hersteller herzlich egal sein.

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


Lesenswert?

Thomas schrieb:
> Aaron C. schrieb:
>> Es gibt ja so die möglichkeit via programm in den Bootloader zu gehen in
>> dem man adresse 0x3800 direkt anspringt, dort kann ja das firmware
>> update stattfinden und man geht zurück ins normale programm.
>
> das ist auch für das Development vollkommen ok. Bei einem kommerziellen
> Device geht sowas schon aus Sicherheitsgründen nicht. Niemand auser dem
> Hersteller des Devices sollte in der Lage sein einfach mal so irgend
> welche FW auf die HW aufzuspielen. Es ist also ein Muss den Bootloader
> abzuschalten. Ich benutze für FW updates gerne die HID Schnittstelle.
>
> Noch ein paar Hinweise zu meinem Code. Die Klimmzüge mit den Odd
> Addressen
> sind sehr wahrscheinich gar nicht notwendig. Ich habe Hinweise gefunden
> dass der Chip wohl kein Autoerase hat und wohl Page weise gelöscht
> werden muss.
> (PageSize 2k??). Wenn dem so ist kann man sich das Klimbim sparen.
>
> Ich hab mal WCH dazu angeschrieben mal schauen ob da was kommt.
>
> Thomas


Ok, diesen einwand verstehe ich 100% dafür ist es wirklich besser ein 
sicheres update verfahren zu entwickeln, am besten dann ja 
verschlüsselt.

Die PageSize vom erase ist 1kByte


Wegen des auslesens der firmware kann man code protect aktivieren dann 
sollte er sich nicht mehr auslesen lassen.

Grüsse

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


Lesenswert?

Nach einen Youtube Kommentar wurde ich auf Bascom 51 
https://www.mcselec.com/index.php?option=com_content&task=view&id=16&Itemid=104 
aufmerksam gemacht, habe dort mal ein Blink example Kompiliert und das 
auf den CH552 geflasht. das Hat erstaunlicherweise ohne weitere 
modifikation funktioniert.

Habe mich zudem Gestern an ein Video gesetzt in dem ich einfach mal 
zeige wie ich eins der USB Boards Löte, ist nicht besonders informativ 
aber vielleicht hilft es ja dem einen oder anderen.

https://youtu.be/CvWF2xtwHZE

: Bearbeitet durch User
von Thomas (Gast)


Lesenswert?

ich habe Rückmeldung von WCH erhalten.

Hier die Ergebnisse:

1. Es ist nicht notwendig den Chip per Page Erase zu löschen. Ich habe 
zwar im Headerfile ch559.h ein define gefunden mit Kommentar dass damit 
eine 1 KByte Flashrompage gelöscht wird: #define ROM_CMD_ERASE 0xA6
WCH hat aber geschrieben das ein Löschen nicht notwendig ist. Das 
FlashRom
ist also gar kein herkömliches Flash.

2. Der Bootloader ist wohl gegen überschreiben speziell geschützt. Den 
kann man nicht so einfach überschreiben.

3. Mit meiner Vermutung über die Endianess lag ich falsch. Mein code 
wird also definitiv falsche Daten flashen.
CHS schreibt: MSB wird an geraden Adressen geschrieben LSB an ungeraten.

Ich werde meine IAP Flash Routinen anpassen und auch noch eine Funktion 
einauen, dass nur dann geflashed wird wenn sich das Zielword vom zu 
schreibenden word unterscheitet.

Thomas

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


Angehängte Dateien:

Lesenswert?

Das war ja eine sehr schnelle Antwort von denen.

Ich meine auch das in der Übersicht der austausch des Bootloaders nur ab 
dem CH554 beworben wird. Dazu ein Bild als Anhang.

Wird es denn dann schwieriger das sich der Chip selber flasht oder kann 
man theoretisch einfach zwei Programm trotzdem nebeneinander auf dem 
flash speichern? also sagen wir 2K für den Bootloader opfern und den 
Rest fürs normale Programm, dann dürften sich nur nie die Adresse 
aufrufe kreuzen wenn ich das richtig verstehe.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Aaron C. schrieb:
> Wird es denn dann schwieriger das sich der Chip selber flasht oder kann
> man theoretisch einfach zwei Programm trotzdem nebeneinander auf dem
> flash speichern?

Ne Bemerkung mal nebenbei: Guckt euch evtl auch mal die M051x von 
Nuvoton an. Das sind zwar Cortex M0 und gehören hier nicht rein, aber 
die haben eine nette Sache, nämlich einen separaten Flashrom von m.W. 
4K, der für einen Bootlader gedacht ist. Dieser Flashrom kann anstelle 
des normalen Flashrom's eingeblendet werden.

W.S.

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


Lesenswert?

W.S. schrieb:
> Aaron C. schrieb:
>> Wird es denn dann schwieriger das sich der Chip selber flasht oder kann
>> man theoretisch einfach zwei Programm trotzdem nebeneinander auf dem
>> flash speichern?
>
> Ne Bemerkung mal nebenbei: Guckt euch evtl auch mal die M051x von
> Nuvoton an. Das sind zwar Cortex M0 und gehören hier nicht rein, aber
> die haben eine nette Sache, nämlich einen separaten Flashrom von m.W.
> 4K, der für einen Bootlader gedacht ist. Dieser Flashrom kann _anstelle_
> des normalen Flashrom's eingeblendet werden.
>
> W.S.

Ist das aber nicht auch wie hier der bootloader bereich der sich ab dem 
ch554 frei beschreiben lässt ?!. Es ist halt standartmässig der wch usb 
bootloader dort "installiert"

Schaue es mir nach der Arbeit einmal an.

von Thomas (Gast)


Lesenswert?

Bei dem Flashloaader halten die sich etwas bedeckt. Ev ist es einfach 
so, dass der nur mit einem ext SPI programmer überschrieben werden kann.
Ich denke dass die einfach nicht alles öffentlich dokumentieren.

Mein Konzept wird weiterhin funktionieren, nur halt mit etwas weniger 
ROM, da der Bereich ab 0x3800 später dann brach liegt. Auf der anderen 
Seite wird es nicht notwendig sein, die Programe an Flashpage Grenzein 
auszurichten. Dies wäre ja notwenig gewesen wenn ich das Flash pageweise 
hätte löschen müssen.

Thomas

von Sigint 112 (sigint)


Lesenswert?

Schade, meine Chips sind immer noch nicht da. Kann es kaum erwarten mit 
den Teilen rumzuspielen.

 Hmm... hatte gehofft, daß WCH etwas mehr Infos preisgibt. Laut 
Datenblatt kann man ja schon bei den CH552 mit einem externen Programmer 
den Bootloader tauschen. Ich denke, daß es bei der ganzen Reihe gehen 
dürfte.
Ich würde den Loader gerne gegen einen HEX-Loader tauschen. Dann kann 
man per serieller Verbindung (CDC) einfach ne neue HEX-Datei 
rüberschicken.
Ich werd mal mit dem ISP-Interface rumspielen, wenn die Chips da sind. 
Vielleicht kann man durch ausprobieren das Protokoll herausfinden... 
leider hab ich damit aber keine Erfahrung.

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

hier ein update der Flash Routinen. Ohne Entschlüsselung sind es etwa 
300 byte code. Mit TEA decoder etwa 800 Byte. Der code ist ausfürlich 
komentiert, die Funktionen somit verständlich sein.

Thomas

von Thomas (Gast)


Lesenswert?

Bei der Durchsicht der USB Beispiele ist mir die komplexe USB Interrupt 
Routine aufgefallen. Das werde ich auf jedenfall versuchen zu änderen. 
Ich habe hier ein Framework was z.B die SetupRequests in main 
bearbeitet.
Der USB interrupt muss dann nur ein paar Flags setzen und entsprechende 
ACK  NAK  STalls setzen und ev die Endpoints befüllen.

Dadurch wird die USB Funktionalität meiner Meinung nach wesentlich 
übersichtlicher. Zusätzlich ist mir aufgefallen, dass keinerlei Abfragen 
vorhanden sind ob das Device einen SetConfigure erhalten hat. Lt spec 
dürfen vorher nur Requests auf dem EP0 bearbeitet werden.

Mal schauen wie weit ich da komme.

Thomas

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


Lesenswert?

Thomas schrieb:
> Bei der Durchsicht der USB Beispiele ist mir die komplexe USB Interrupt
> Routine aufgefallen. Das werde ich auf jedenfall versuchen zu änderen.
> Ich habe hier ein Framework was z.B die SetupRequests in main
> bearbeitet.
> Der USB interrupt muss dann nur ein paar Flags setzen und entsprechende
> ACK  NAK  STalls setzen und ev die Endpoints befüllen.
>
> Dadurch wird die USB Funktionalität meiner Meinung nach wesentlich
> übersichtlicher. Zusätzlich ist mir aufgefallen, dass keinerlei Abfragen
> vorhanden sind ob das Device einen SetConfigure erhalten hat. Lt spec
> dürfen vorher nur Requests auf dem EP0 bearbeitet werden.
>
> Mal schauen wie weit ich da komme.
>
> Thomas


Find ich gut wie weit du kommst. Mir fehlt dann doch in die richtung das 
wissen.

Wenn du möchtest kann ich dir ein paar chips/boards zukommen lassen ?!

Grüsse

von Stephan (Gast)


Lesenswert?

Hallo,

wenn ich der Anleitung für Windows

https://github.com/Blinkinlabs/ch554_sdcc

folge bekomme ich in der Gitbash den folgenden Fehler

bash: mingw32-make.exe: command not found

Kann es sein dass Qt in u.A. Version installiert sein muß?

# Mingw tools (for Make)
export PATH=$PATH:/c/Qt/Qt5.10.0/Tools/mingw530_32/bin

Die Installation kam mir aber ein wenig groß vor (35GB) und im Text wird 
darauf hingewiesen dass es wohl auch anders geht.

TODO: Use standalone mingw tools instead of the ones from Qt

Wie habt ihr das gemacht?

Grüße
Stephan

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


Lesenswert?

Stephan schrieb:
> Hallo,
>
> wenn ich der Anleitung für Windows
>
> https://github.com/Blinkinlabs/ch554_sdcc
>
> folge bekomme ich in der Gitbash den folgenden Fehler
>
> bash: mingw32-make.exe: command not found
>
> Kann es sein dass Qt in u.A. Version installiert sein muß?
>
> # Mingw tools (for Make)
> export PATH=$PATH:/c/Qt/Qt5.10.0/Tools/mingw530_32/bin
>
> Die Installation kam mir aber ein wenig groß vor (35GB) und im Text wird
> darauf hingewiesen dass es wohl auch anders geht.
>
> TODO: Use standalone mingw tools instead of the ones from Qt
>
> Wie habt ihr das gemacht?
>
> Grüße
> Stephan

Hatte damal auch ein problem damit, es musste noch der genaue include 
pfad in der git bashrc datei angegeben werden,

in ordner c:\users\BENUTZER eine datei namens .bashrc anlegen und 
folgendes einfügen.

# SDCC compiler tools
export PATH=$PATH:/c/Program\ Files/SDCC/bin

# Mingw tools (for Make)
export PATH=$PATH:/c/mingw/bin

alias make=mingw32-make.exe

ist alles aus dem Kopf und bin gerade nicht mehr ganz sicher, am besten 
etwas probieren.

hoffe das hilft weiter.

von Thomas (Gast)


Lesenswert?

Nun es liegt ganz einfach daran dass ich mich mit USB, mit 
Unterbrechungen, seit fast 20 Jahren beschäftige. Ich habe in der Zeit 
mit verschiedensten USB Chips gearbeitet. Mit der Zeit ist dann dieses 
Framework entstanden. Zuletzt habe ich das für den STM gemacht.
Im Prinzip ist es so, dass ich für jeden Chip eine Lib baue. In den 
Projekten linke ich dann nur noch die Lib für den entsprechenden chip. 
Immer dann wenn ich merke dass in der Lib was fehlt portiere ich die 
fehlende Funktionaltiät auf alle anderen Chips. So ist in der 
Zwischenzeit eine ganz ordentliche Sammlung enstanden. Einige Projekte 
sind auch im Auftrag für komerzielle Produkte entstanden.
Hab grad noch mal nachgeschaut: Es sind inzwischen mehr als 20 VID / PID 
Kombinationen.

Aaron C. schrieb:
> Wenn du möchtest kann ich dir ein paar chips/boards zukommen lassen ?!
Vielen Dank ich werde mich vielleicht Ende nächster Woche bei dir 
melden.


Thomas

von Stephan (Gast)


Lesenswert?

Hallo AAron vielen Dank für Deine schnelle Antwort,

die Pfade hab ich, so wie das in der Anleitung stand, in die vorhandene 
bashrc. im Verzeichnis von Git gemacht.

C:\Users\Stephan\AppData\Local\Programs\Git\etc

Deshalb sucht er beim Aufruf von make auch nach der mingw32-make.exe. 
Soweit funktioniert das scheinbar.

Es ist nur so daß auch ein Pfad eben für QT angegeben ist,

> # Mingw tools (for Make)
> export PATH=$PATH:/c/Qt/Qt5.10.0/Tools/mingw530_32/bin

ich aber kein QT installiert habe. Darauf geht die Anleitung auch nicht 
ein. Es steht da im Grunde nur, daß diese Schritte noch beschrieben 
werden müssen.

Ist denn bei dir ein Ordner mit Qt s.o. vorhanden?

Grüße, Stephan

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


Lesenswert?

Stephan schrieb:
> Ist denn bei dir ein Ordner mit Qt s.o. vorhanden?

Nein, ich habe nur MinGw installiert, glaube das konnte man bei dem 
Installer einzeln anwählen.

Ist leider auch schon etwas länger her, erinnere mich aber wie gesagt 
daran das es da auch eine stunde haperte

von Stephan (Gast)


Lesenswert?

Der Pfad in die Mingw Installation ist richtig.

export PATH=$PATH:/c/MinGW/bin
alias make=mingw32-make.exe

funktioniert.

Hat gestern irgendwie nicht gklappt aber möglicherweise hab ichs auch 
nicht richtig gespeichert. Jetzt geht es.

Danke nochmal, Stephan

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


Lesenswert?

Stephan schrieb:
> funktioniert.


Sehr gut, dann schonmal viel erfolg :)

von Sigint 112 (sigint)


Lesenswert?

Erfolg! Meine Chips sind angekommen und funktionieren perfekt. ? 
Allerdings will librech551 nicht funktionieren. Der erkennt den Chip, 
bleibt aber ohne Ausgabe in einer Dauerschleife hängen. Hatte das 
Problem auch jemand? Das WCH-Tool funktioniert. Jetzt muss ich mir noch 
ne schöne Platine designen... Lochraster sieht so unprofessionell aus.

von Stephan (Gast)


Lesenswert?

Ich habs mal testweise mit -e durchlaufen lassen das ging.
Es muss sich natürlich im programming mode befinden sonst findet er 
nichts.

Libre CH551 Flasher 2018
Detected device CH552
Device rom capacity 16384, data flash capacity 128
Device bootloader version: 1.1

Now performing erase...
Erase done

Excited! 0..0

von Stephan (Gast)


Lesenswert?

Verwendetes System war übrigens:

Version Linux Mint 19 Tara 64-bit
Kernel Linux 4.15.0-43-generic x86_64

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


Lesenswert?

Sigint 1. schrieb:
> Erfolg! Meine Chips sind angekommen und funktionieren perfekt. ?
> Allerdings will librech551 nicht funktionieren. Der erkennt den Chip,
> bleibt aber ohne Ausgabe in einer Dauerschleife hängen. Hatte das
> Problem auch jemand? Das WCH-Tool funktioniert. Jetzt muss ich mir noch
> ne schöne Platine designen... Lochraster sieht so unprofessionell aus.

Sehr gut.

Hast du eine bin oder hex datei probiert mit librech551? Leider kann das 
nähmlich derzeit nur bin files.

-e muss man nicht extra beim flashen eingeben das wird dann automatisch 
gesetzt.

Habe mal testweise eine hexdatei in diesen simulator geladen 
https://www.edsim51.com wird erfolfgreich ausgeführt. War mir vorher 
nicht 100% bewusst aber die ch serie ist ja im endeffelt einfach nen 
8051 mit zusatz hardware integriert :D


Hier habe ich nun mein usb stick pcb öffentlich gemacht: 
https://easyeda.com/editor#id=|16fcda923b0e480093d7de9a6e215691|c61357efe74646b28d6abb5bdbe1d837
Die beiden fehler sind dort nun auch behoben und die Power led lässt 
sich auch via pin schalten.


Viel spass beim basteln.

: Bearbeitet durch User
von Thomas (Gast)


Lesenswert?

ich habe mich inzwischen etwas intensiver mit dem usb core beschäftigt 
und
auch angefangen erste Teile neu zu schreiben. Hier die Initialisierung 
wie
Sie im Hid Beispiel gemacht werden allerdings etwas strukturierter und
mit englischen Kommentaren.

Thomas
1
/** configure and init the usbcore
2
    
3
    Configure EP0 and additionally the two  HID EPs EP1 and EP2.
4
    Enable USB interupt for transfer, usb reset and usbsuspend.
5
    Finally the usb core is switched on as a fullspeed device since
6
    the pullup is connected to D+.
7
    
8
*/
9
void UsbDeviceConfigure(void)
10
{
11
    IE_USB      = 0;                                          // disable usb irqs
12
    USB_CTRL    = bUD_PD_DIS;                                 // Usb off, no pulldowns  
13
    //
14
    // setup ep0 todo the next line is possibly wrong 
15
    // depends previous settings check this carefully
16
    //
17
    UEP0_CTRL   = UEP_R_RES_ACK | UEP_T_RES_NAK;              // IN ready, OUT busy  
18
    UEP0_DMA    = (uint16_t) EP0_Buffer;                      // Set Ep0 DMA to the EP0 Buffer
19
    //
20
    // setup ep1 in single buffer mode with auto toggle
21
    //
22
    UEP4_1_MOD  = UEP4_1_MOD & ~bUEP1_BUF_MOD | bUEP1_TX_EN;  // EP1 enable 
23
    UEP1_CTRL   = bUEP_AUTO_TOG | UEP_T_RES_NAK;              // autotoggle NAK on recieve
24
    UEP1_DMA    = (uint16_t)EP1_Buffer;                       // Set the DMA
25
    //
26
    // setup ep2 in single buffer mode with auto toggle
27
    //
28
    UEP2_3_MOD  = UEP2_3_MOD & ~bUEP2_BUF_MOD | bUEP2_TX_EN;  // Enable EP2 
29
    UEP2_CTRL   = bUEP_AUTO_TOG | UEP_T_RES_NAK;              // autotoggle NAK on recieve
30
    UEP2_DMA    = (uint16_t)EP2_Buffer;                       // set the DMA
31
    // 
32
    // disable remaining eps 
33
    //
34
    UEP2_3_MOD &= ~(bUEP3_RX_EN | bUEP3_TX_EN);               // EP 3 is disabled   
35
    UEP4_1_MOD &= ~(bUEP4_RX_EN | bUEP4_TX_EN);               // EP 4 is disabled
36
    //
37
    // this may go to main changed the order of commands
38
    // so enableing the usb port will be the last action 
39
    // the following code activates the usb core
40
    //
41
    USB_DEV_AD  = 0x00;                                         // device address = 0
42
    UDEV_CTRL   = bUD_PD_DIS;                                   // already done but does not hurt
43
    USB_CTRL    = bUC_DEV_PU_EN | bUC_INT_BUSY  | bUC_DMA_EN;   // Connect use dma set busy
44
    USB_INT_EN  = bUIE_SUSPEND  | bUIE_TRANSFER | bUIE_BUS_RST; // enable usb irqs
45
    USB_INT_FG  = 0xFF;                                         // clear all usb int flags
46
    UDEV_CTRL  |= bUD_PORT_EN;                                  // enable usb port 
47
    IE_USB      = 1;
48
    EA          = 1;
49
}

von Sigint 112 (sigint)


Lesenswert?

Hmpf... ich hab irgendwie ne Denkblockade. Irgendwie bekomme ich 
librech551 auf keinem Rechner ans laufen. Hab 2 Linux-Systeme (VMs) und 
3 Windows-Systeme (cygwin) getestet. Auf keinem will das laufen. Auf 
einem Cygwin bekomme ich immer libusb_error_io bei BULK_IN.
Ausserdem spinnt SDCC auch rum. Ich wollte den gesamten Programmspeicher 
mit MOVC auslesen und seriell übertragen. SDCC erzeugt da aber irgenwie 
eine komische loop, die nicht vorhanden ist. Seltsamerweise auch nicht 
im Assembler Listing... das Programm hängt aber trotzdem in einer 
Schleife fest.
Anscheinend kann man aber den Bootloader auslesen... an entsprechender 
Stelle kommt Programmtext. Leider hab ich noch Probleme mit 
Übertragungsfehlern... deshalb ist der Code nicht brauchbar.

Ich versuch es mal direkt in Assembler. By the way: Welche Baudrate kann 
ich bei 6MHz Takt verwenden, ohne Übertragungsfehler zu haben. Konnte 
noch keine finden, mit 0% Fehlerrate. :-(

von Thomas (Gast)


Lesenswert?

Vermutlich werde ich am Wochenende meine FW fertig haben die wird dann 
auch den Bootloader auslesen können. Bei 6MHz bleibt nur T2 zur genauen 
Baudratenerzeugung.

Thomas

von Stephan K. (nightowl)


Lesenswert?

Ich hab nur die dev Version von der libusb nachinstallieren müssen und 
dann lief make durch.
Dann noch einmal make Install und fertig.
Ich habe allerdings nur mit -e also nur einen Löschvorgang getestet.
Bei Bedarf kann ich aber auch nochmal ein File flashen.

Stephan

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

hier die neuen header Fiels für den CH552. Sie sind kompatible mit Keil 
und SDCC, die Unterscheidung passiert automatisch einfach mit #include 
"ch552_new.h" einbinden.
In den Header Files habe ich die USB Definitionen und Typ Deklatationen 
rausgeschmissen.

Thomas

von Sigint 112 (sigint)


Lesenswert?

So langsam kotzt es mich an. :-(
Nichts was ich versuche funktioniert wirklich. Ich schaffe es nichtmal 
den UART0 mit Timer2 ans laufen zu bringen. Welche Register muss ich 
anfassen, damit das läuft?!? Hab meherer Beispiele im Netz probiert, 
z.B. folgende:
1
SCON=0x50;
2
T2MOD|=(bTMR_CLK|bT2_CLK);
3
T2CON=0x34;
4
RCAP2=0xFB1e;
5
EXF2=0;
6
EXEN2=0;
7
RCLK=1;
8
TCLK=1;
9
C_T2=0;
10
CP_RL2=0;
11
TR2=1;
12
13
oder
14
15
SCON = 0x50;      /* uart in mode 1 (8 bit), REN=1 */
16
T2MOD|=(bTMR_CLK|bT2_CLK);
17
T2CON =0x34;      /* RCLK = 1; TCLK=1; */
18
T2COUNT=0xFB1E;
19
RCAP2=0xFB1E;
20
TR2 = 1;      /* Timer 2 run */
21
TI = 1;
22
RI = 0;

Nichts läuft. Mit Timer1 kein Problem, abgesehen von den 
Übertragungsfehlern. :-(

von Thomas (Gast)


Lesenswert?

Dann zeig mal ein vollständiges Programm so mit Clocks, kommentierte 
T2Initialsierung Interrupt Aktivierung....
Thomas

von Thomas (Gast)


Lesenswert?

Im Datenblatt sect 12.4.2 Timer2 Serial Port 0 Baud Räte Generator
und sect 13.2.2 UART.
Dort ist alles beschrieben inc. Berechnung der Reload Werte für die 
Baudrate

Das ist die normale x51 Hardware Beispiele sollten sich in jedem HW 
Tut.befinden. Nur die 2. ser. Schnittstelle ist spezieller.

Thomas

von Sigint 112 (sigint)


Lesenswert?

Hiermit funktioniert die Schnittstelle endlich:
1
#include<mcs51/ch55x.h>
2
3
__code unsigned char *prog=0;
4
5
6
void wait(int v)
7
{
8
  int i;
9
  for(;v>0;v--){
10
    for(i=1;i<600;i++){}
11
  }
12
}
13
14
15
void putc(unsigned char c)
16
{
17
  SBUF=c;
18
  TI=0;
19
  while(!TI){};
20
}
21
22
23
void main(void)
24
{
25
  long int adr=0;
26
  SP=0xfe;
27
  EA=0;
28
29
30
  SCON = 0x40;
31
  T2CON =0x34;
32
  T2MOD=0xc0;
33
  RCAP2=0xFD8F;
34
  TI = 1;
35
36
  for(adr=0;adr<0xFFFE;adr++)
37
  {
38
    putc(*prog);
39
    prog++;
40
  }
41
42
  while(1);
43
}

Leider funktioniert das Auslesen des Programmspeichers nicht so, wie ich 
es mir gedacht habe.

von Thomas (Gast)


Lesenswert?

Warum  SP= 0xFE. Das ist hoffentlich nicht der Stackpointer...

Üblicherweise macht der Compiler das selbst.

Thomas

von Sigint 112 (sigint)


Angehängte Dateien:

Lesenswert?

Ich hab den Bootloader ausgelesen und der Code scheint korrekt zu sein. 
Irgendwie schaffe ich es aber nicht die fehlenden .DB Stellen zu 
disassemblieren. Aber schon mal ein erster Erfolg.

von Thomas (Gast)


Lesenswert?

Warum  SP= 0xFE. Das ist hoffentlich nicht der Stackpointer...

Üblicherweise macht der Compiler das selbst.

Thomas

Sigint 1. schrieb:
> Ich hab den Bootloader ausgelesen und der Code scheint korrekt zu sein.
> Irgendwie schaffe ich es aber nicht die fehlenden .DB Stellen zu
> disassemblieren. Aber schon mal ein erster Erfolg.

Lad das Teil mal als bin File hoch, ich schicke es dann durch den IDA

Thomas

von Sigint 112 (sigint)


Angehängte Dateien:

Lesenswert?

Hier die Bin. Der Bootloader steht bei 0x3800

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Hier das IDA disassembly. Ich habe die Funktionen schon umbenannt und 
ein paar Referenzen aufgelöst und teiweise die Formatierung angepasst. 
Die IDA Ausgabe ist nicht wirklich toll.

Das Teil wurde wohl mit Keil C51 geschrieben.

Thomas

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


Lesenswert?

Cool. Wäre ja interessant ob es auch ein funktion zum auslesen des 
flashes im bootloader gibt.

Habe so beim durchscrollen leider nichts eindeutiges gefunden.

von Thomas (Gast)


Lesenswert?

naja wenn dann ist es in einer der 11 Funktionen des Dispatchers 
verborgen.
Die Analyse wird aber nicht so ganz einfach weil dazu die Bedeutung 
aller
Ram Referenzen im idata notwendig ist.
Vielleicht mach ich das mal später oder sigint macht da was...

Generell hat das für mich keine Prio weil ich das nicht brauche. Für das 
Verständnis des Teils ist es aber hilfreich.
Der Bootloader kann wohl auch über die serielle Schnittstelle 
angesprochen werden. Ich vermute mal dass sigint dort einsteigt.

Thomas

von Thomas (Gast)


Lesenswert?

da ich mit meiner App noch ein paar Probleme habe (Ich kämpfe momentan 
mit LibUsb sowie mit de Implementierung der Makros für SDCC), hier ein 
kleiner Zwischenstand zum Bootloader.
Diie Mainfunktion des Bootloaders in C. Sie ist nicht 100% identisch zum 
Original sollte aber funktionsgleich sein und das Wesentliche zeigen.

Thomas
1
bit      bit00;         // ??? 
2
bit      bSoftReset;    // 1  for going to reset
3
bit      bFirstSer;     // 1  for first serial
4
bit      bit03;         // ???
5
6
uint32_t Key;
7
uint8_t  Bootkey[8];
8
uint8_t  RAM_2A;
9
  
10
void main (void)
11
{
12
   uint8_t cfg;
13
   uint8_t pins;
14
   uint8_t i;
15
16
   SAFE_MOD   = 0x55;
17
   SAFE_MOD   = 0xAA;
18
   WAKE_CTRL |= bWAK_RST_HI & ~(bWAK_RST_HI | bWAK_P3_2E_3L | bWAK_RXD0_LO);
19
20
   bSoftReset = 0;
21
   bit00      = 1;
22
   bFirstSer  = CHIP_ID & 0x01;
23
   EA         = 0;
24
   TR0        = 0;
25
   TF0        = 0;
26
27
   if(bFirstSer)
28
   {  // setup first serial
29
      SCON  = 0x50;
30
      T2CON = 0;
31
      PCON  = SMOD;               // double speed
32
      TMOD  = 0x20;               // T1 8 Bit autoreload
33
      T2MOD = bTMR_CLK | bT1_CLK; // clock speed
34
      TH1   = 0xF3;               // reload value
35
      TR1   = 1;
36
   }
37
   else
38
   {  // setup second serial
39
      SCON1  = 30;
40
      SBAUD1 = 0xF3;
41
   }
42
43
   cfg = CBYTE[0x3FF4];  //bootloader config
44
   if (cfg & 0x02)
45
   {  // check boot pins
46
      if ((UDP)  || (MOSI)) pins = 1;
47
      else                  pins = 0;
48
   }
49
   //
50
   //  check boot contitions
51
   //
52
   if ( (pins)                                                  // pin boot
53
        || (GLOBAL_CFG & bBOOT_LOAD)                            // software boot
54
        || ((CBYTE[0x0000] == 0xFF) && (CBYTE[0x0001] == 0xFF)) // no code
55
      )
56
   {  // init usb
57
      USB_CTRL   = 0;
58
      IE_EX      = 0x0C;
59
      UEP0_DMA   = 0;
60
      UEP2_DMA   = 0x00C0;
61
      USB_CTRL   = bUC_DEV_PU_EN | bUC_INT_BUSY | bUC_DMA_EN;
62
      UDEV_CTRL  = bUD_PD_DIS | bUD_PORT_EN;
63
      USB_INT_FG = 0xFF;
64
      USB_INT_EN = bUIE_SUSPEND | bUIE_TRANSFER | bUIE_BUS_RST;
65
   }
66
   else
67
   {  // no boot contition
68
      if(cfg & 0x01)
69
      {  //init timer0
70
         TMOD |= 0x01;
71
         TL0   = 0xC0;
72
         TH0   = 0x63;
73
         TR0   = 1;
74
      }
75
      else bSoftReset=1;
76
   }
77
   //
78
   // init a 128 bit bootkey
79
   //
80
   for (i=0;i < 8; i++) Bootkey[i]=Scrambled();
81
82
   while (1)
83
   {
84
      if (bSoftReset)
85
      {  // do a reset
86
         SAFE_MOD   =  0x55;
87
         SAFE_MOD   =  0xAA;
88
         GLOBAL_CFG =  bSW_RESET;
89
         while(1);
90
      }
91
      else
92
      {  // handle serial and usb
93
         if ((U1TI) || (RI))
94
         {
95
            RAM_2A = 0x96;
96
            SerialDispatcher();
97
         }
98
99
         if (USB_INT_FG & 0x07)
100
         {
101
            RAM_2A = 0x96;
102
            HandleUsbEvents();
103
         }
104
      }
105
      if (TF0)
106
      {  //timeout
107
         TF0        = 0;
108
         TR0        = 0;
109
         bSoftReset = 1;
110
      }
111
   }
112
}

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Ein update zum bootloader asm file. Es sind ein paar Fehler korrigiert 
sowie die idata Referenzen aufgelöst. Das File erzeugt mit Keils A51 ein 
zum Original identisches bin File.Der Keil A51 kann ja zum Glück mit den 
SFR Files von C umgehen. Der Funktionsdispatcher hat immer noch große 
Lücken bei den Komentaren.

Was ich anfangs für Stackchecks gehalten habe, sind wohl nur 
Endlosschleifen falls bestimmte Funktionen nicht korrekt aufgerufen 
werden. Keine Ahnung was die damit erreichen wollen.

Für mich interesant ist die Code Flash Routine. Dort sind Bereichs 
überprüfungen drinn, die ein Überschreiben des Loaders verhinderen. 
Vieleicht kann man den Bootloader doch einfach überschreiben...

Thomas

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


Angehängte Dateien:

Lesenswert?

Danke für den Sourcecode, bekomme den aber leider nicht compiliert mit 
Keil  51 muss ich was bestimmtes beachten ?

Habe heute auch endlich die Neue PCB version von dem "USB Stick" 
erhalten.
nun endlich ohne Fehler und alle LED's Schaltbar.

Wenn bedarf besteht kann ich davon welche weiter geben.

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


Lesenswert?

Okay, Keil hat den Bootloader nun erfolgreich Kompiliert, mann muss auch 
den/das richtige target auswählen :D

von Thomas (Gast)


Lesenswert?

Aaron C. schrieb:
> Danke für den Sourcecode, bekomme den aber leider nicht compiliert mit
> Keil  51 muss ich was bestimmtes beachten ?

Eigentlich nicht das Header File hast du im Suchpfad oder im gleichen 
Ordner wie das Assembler File?

Thomas

von Thomas (Gast)


Lesenswert?

Die blinden Stellen im Bootloader werden weniger....
Es gibt wohl auch eine Verfy Funktion. Wenn ich das richtig verstehe, 
werden die Daten verschlüsselt übertragen. Als Schlüssel benutzen Sie 
die bootkey variable und es gibt einen Dispatcher call um den Schlüssel 
zu tauschen.
Die Beschreibung im librech551 master mainfile sind leider falsch/ 
unvollständig.

Thomas

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


Lesenswert?

Thomas schrieb:
> Die blinden Stellen im Bootloader werden weniger....
> Es gibt wohl auch eine Verfy Funktion. Wenn ich das richtig verstehe,
> werden die Daten verschlüsselt übertragen. Als Schlüssel benutzen Sie
> die bootkey variable und es gibt einen Dispatcher call um den Schlüssel
> zu tauschen.
> Die Beschreibung im librech551 master mainfile sind leider falsch/
> unvollständig.
>
> Thomas


Ja das mit der verschlüsselung hatte ich auch schon ansatzweise gesehen. 
I  librech551 nutzen sie ja einen standart key für die übertragung um es 
einfacher zu machen wenn ich das richtig verstanden habe, habe das in 
der android app auch einfach so übernommen.

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Ein paar Kommentare vom Dispatcher
1
JmpTable:                     ;
2
    ljmp  JumpFunction0       ;a1 detect chip V2  
3
    ljmp  JumpFunction1       ;a2 BootControl
4
    ljmp  JumpFunction2       ;a3 newkey?
5
    ljmp  JumpFunction3       ;a4 erase Code Flash  (2k page)
6
    ljmp  JumpFunction4       ;a5 write  encoded code flash
7
    ljmp  JumpFunction5       ;a6 verify encoded code flash
8
    ljmp  JumpFunction6       ;a7 
9
    ljmp  JumpFunction7       ;a8 write Boot Options
10
    ljmp  JumpFunction8       ;a9 erase Data Flash
11
    ljmp  JumpFunction9       ;aa write encoded data flash
12
    ljmp  JumpFunction10      ;ab read data flash

Thomas

von Thomas (Gast)


Lesenswert?

noch ein update zum bootloader.
die Erase Page Funktion ist m. E. kaputt die lässt jedes 2 WORD aus und 
kann nur die erste Page löschen

Die zusätzlichen Klammern sind nur wegen dem Code Folding im Editor 
drin.
Thomas
1
      case 0xA4:  // erase code Flash page 2k
2
           {  // <a4> <x> <x> <page>
3
              if (cmdbuffer[3] < 8) 
4
              {
5
                 addr = ((uint16_t) cmdbuffer[3]) << 10;
6
                 i    = 4;
7
                 do
8
                 {
9
                    result = WriteCodeFlash(addr ,0xFFFF);
10
                    addr  += 2;
11
                    if (!(addr & 0x3FF)) i--;
12
                 } while(i);
13
                 bWrProtect = 0;
14
              } 
15
              /* the original broken one
16
              if (cmdbuffer[3] < 8) 
17
              {
18
                 cmdbuffer[3]=4;
19
                 addr        =0;  //bugbug just page 0
20
                 do
21
                 {
22
                    result= WriteCodeFlash(addr ,0xFFFF);
23
                    addr+=4;  // bugbug should be 2
24
                    if (!(addr & 0x3FF)) cmdbuffer[3]--;
25
                 } while(cmdbuffer[3]);
26
                 bWrProtect = 0;
27
              } 
28
              */
29
           }
30
           break;

von Peter W. (pe_wi)


Angehängte Dateien:

Lesenswert?

Bei meinen ersten Progammierversuchen mit dem CH554 (mit WCHISPTool - 
V2.60) über USB, wurde vermutlich der Bootloader überschrieben. Leider 
gibt es zum Programm (WCHISPTool) keine englische Beschreibung!
Der CH554 ist über USB nicht mehr ansprechbar. Ein anderer CH554 
funktioniert noch. Aber an den trau ich mich im Moment gar nicht mehr 
ran.
Wie kann ich den Bootloader wieder herstellen - mit ISP, aber wie?
Hat jemand eine Idee?


mit freundlichen Grüßen

Peter Winges

von GBert (Gast)


Lesenswert?

Hallo Peter,

Peter W. schrieb:
> Bei meinen ersten Progammierversuchen mit dem CH554 (mit
> WCHISPTool -
> V2.60) über USB, wurde vermutlich der Bootloader überschrieben. Leider
> gibt es zum Programm (WCHISPTool) keine englische Beschreibung!
> Der CH554 ist über USB nicht mehr ansprechbar. Ein anderer CH554
> funktioniert noch. Aber an den trau ich mich im Moment gar nicht mehr
> ran.
> Wie kann ich den Bootloader wieder herstellen - mit ISP, aber wie?
> Hat jemand eine Idee?
>
> mit freundlichen Grüßen
>
> Peter Winges

ich denke, Du musst einfach nur Prog brücken. Dann solltest Du flashen 
können.

Gruß

Gerd

von Thomas (Gast)


Lesenswert?

Es ist nach meinem Verständniss, solange du nur mit dem ISP tool 
arbeitest, technisch nicht möglich den Bootloader zu überschreiben. 
Anders sieht es aus wenn du selbst eine Flasher App programmierst und im 
Bereich 0x3800 ohne Sicherheitsabfragen programmierst. Siehe auch das 
Bootloader.a51
Wenn der Bootloader wirklich weg ist funktioniert das ISP Tool sowieso 
nicht mehr da dann das USB Device nicht mehr kommt.
Du must dich durch die chin. Webside wühlen. Es gibt wohl einen SPI 
Flasher inc. Schaltpläne.

Thomas

von Peter W. (pe_wi)


Lesenswert?

Also das Modul ist erst mal gerettet!
Die USB Schnittstelle ist zwar defekt (warum auch immer), aber die 
serielle Übertragung hab ich jetzt zum Laufen gebracht. Vom MAX_232 auf 
Modul Stift RxD_(P12) und TxD_(P13) geschaltet. Zum Test habe ich das 
Blinkprogramm übertragen und es funktioniert!
Also ist der Bootloader, zumindest die serielle Funktion i.O. Vielleicht 
sind ja die Ports USB - µC defekt. Das muß ich noch testen.

@Thomas
Ich habe auch versucht den Bootloader zu überschreiben und deine 
"bootloader.hex" übertragen. Das hat leider nicht funktioniert. Bei 25% 
kam Fehler! Also scheint der Bootloader wirklich geschützt zu sein.

mit freundlichen Grüßen

Peter

von Thomas (Gast)


Lesenswert?

Peter W. schrieb:
> Ich habe auch versucht den Bootloader zu überschreiben und deine
> "bootloader.hex" übertragen. Das hat leider nicht funktioniert. Bei 25%
> kam Fehler! Also scheint der Bootloader wirklich geschützt zu sein.

Wenn du versucht hast den Bootloader mit dem WCH ISP Tool zu 
überschreiben, das geht nicht. Erstens kann kein Programm sich selbst 
überschreiben und zweitens ist der Bereich ab 0x3800 bis 0x3ff0 in der 
Flashroutine durch Range Checks geschützt.
Ich bin aber mit meinen tools so gut wie fertig da sollte das dann gehen

Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

hier nun das erste vollständige App. Das Teil ist im Prinzip eine 
modifizierte Version des Bootloaders. Bitte die Kommentare im File 
beachten.
Im Moment Keil only wobei SDCC sowieso nicht in der Lage ist den code 
klein genug zu bekommen dass der in 2k ab 0x3800 passt.

Falls Ihr den Bootloader überschreiben wollt, das geht da alle 
Sicherheitsabfragen abgeschaltet sind.

Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

shit man sollte immer noch mal compilieren bevor man veröffentlicht ...

hier die die lauffähige Version

Thomas

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


Lesenswert?

Thomas schrieb:
> shit man sollte immer noch mal compilieren bevor man veröffentlicht ...
>
> hier die die lauffähige Version
>
> Thomas

Vielen Dank werde das später einmal testen.

Eine Möglichkeit das zu Flashen hast du noch nicht gefunden oder?

Grüße Aaron

von Thomas (Gast)


Lesenswert?

Aaron C. schrieb:
> Eine Möglichkeit das zu Flashen hast du noch nicht gefunden oder?

Was meinst du? Den code hab ich auf deinem Stick ab 0x000 laufen. Genau 
so wie er da steht. Bootloader=0 with_serial=1 arons_stick=1

Thomas

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


Lesenswert?

Ahhh entschuldige, es ist ja wirklich alles schon drin...


Ich sollte aufhören bei der Arbeit neben bei zu schreiben.

Habe es mal grob in keil versucht er meckert jedoch das er die stdint.h 
nicht findet, hast du vielleicht ein ganzes keil Projekt welches du hier 
hochladen kannst?

Grüße

von Thomas (Gast)


Lesenswert?

Aaron C. schrieb:
> Habe es mal grob in keil versucht er meckert jedoch das er die stdint.h
> nicht findet, hast du vielleicht ein ganzes keil Projekt welches du hier
> hochladen kannst?

Stimmt hab ich vergessen Keil hat den ja nicht. Kannst du einfach selbst 
schreiben ich benutze ja nur die Grundtypen uint8_t uint16_t uint_32_t.
Alternativ geht auch die vom SDCC.
Ein komplettes Projekt will ich noch nicht hochladen gerade am Anfang 
finde ich es besser wenn man sich mal mit den Einstellungen auseinander 
setzt. Zusätzlich gibts in meinen Projekten noch ein paar Einstellungen 
die ohne das grundsätzliche Verständnis der Projektioonen nur für 
Verwirrung sorgen.
u.A Simulator Dateien Debug Optionen und ähnliches.

Meine Projekte haben auch eine feste Ordnerstruktur damit das alles 
funktioniert müstest du diese Ordnerstruktur ebenfalls abbilden.

Zum Projekt
Einfach in einem Ordner ein Projekt anlegen bei der Frage nach der 
Startupkopie ja drücken das Startupfile würdest du brauchen wenn du nach 
0x3800 linken willst ansonsten bleibt es wie es ist.
Alle C und H Files in entsprechende Ordner kopieren. Ich hab hier immer 
\src und \inc. C Files ins Projekt aufnehmen und den Haken setzen create 
hexfile.

Ich hab übrigens gerade festgestellt dass die WCH App den stick nicht 
findet,die Ursache ist mir noch nicht ganz klar. Der code hat also noch 
keine richtige Funktion.

Thomas

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



Lesenswert?

Soo, vorweg vielen dank für das nicht bereitstellen des Projekten, Also 
im ernst, sonst hätte ich wirklich nichts gelernt!

Es funktioniert nun wie gewünscht und das HEX file lässt sich flashen.
wie auch bei dir wird der Bootloader nicht bon WCHISP erkannt, anbei als 
vergleich die beiden USB Devices mit den Unterschieden.
Mal etwas rumprobieren ab wann dein Bootloader erkannt wird.

soweit einen schönen abend.

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



Lesenswert?

Ich denke das der neue Bootloader nicht erkannt wird liegt an dem 
Copyright String, wenn man diese abfrage beim öffnen vom ISP Tool 
vergleicht gibt der Neue Bootloader eine andere antwort als der 
Originale.

Dazu anbei noch ein Paar screenshots.

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



Lesenswert?

Sorry für noch einen Extra Post ist sonst aber etwas unübersichtlich.

Also wenn man der A1 anfrage mit festen werten "FE 00" anwtorten geht 
die Abfrage vom ISPtool weiter mit der A2 abfrage auch dort antwortet 
dein Bootlaoder anders als das Original, wenn man dort auch wieder fixe 
werte vorgibt wird der Neue Bootloader endlich erfolgreich vom ISP tool 
erkannt und man kann ihn Programmieren.

Leider bricht das ISP tool aber die Programmierung ab. bin da aber noch 
nicht weiter.


Um die Fixen werte vorzugeben habe ich im case 0xA1 und 0xA2 von der 
FunctionDispatcher function alles augeklammert und jeweils folgendes 
eingefügt:


rLen        = 2;
Response[0] = 0xFE; //bei A2 = 0x52;
Response[1] = 0x00;
return;

: Bearbeitet durch User
von Thomas (Gast)


Lesenswert?

Danke für deine Tests ich schau mir das morgen genauer an scheint so als 
ob ich den Dispatcher noch nicht so ganz verstanden habe.

Thomas

von Thomas (Gast)


Lesenswert?

Im USB code stekt auch noch ein bug. Ich hatte versuchsweise mal den 
serial String um die chip ID verlängert dann bleibt der core stehen 
vermutlich weil dann die String Länge ein vielfaches von EP0SIZE ist da 
fehlt wohl noch ein ZLP.

Die Änderungen im Device Deskriptoren sind bewusst so damit man erkennen 
kann was gerade aktiv ist.

Thomas

von Thomas (Gast)


Lesenswert?

mm es sieht so aus dass sich auf den ch552 ein anderer Bootloader 
befindet als die Version von sigint. Das muss ich noch genauer 
anschauen.

Thomas

von Andreas B. (andreasb)


Lesenswert?

Aaron C. schrieb:
> Leider ist bei so wenig Interesse anderer die Lust weniger geworden.
Schade ;-)

Danke für die Info, hab dein Thread erst vor kurzem entdeckt. Nicht nur 
der Preis ist interessant, sondern auch die Gehäuseform: der ist recht 
einfach von Hand zu löten ;-)


mfg Andreas

von Thomas (Gast)


Lesenswert?

Ich hab den Bootloader der ch552 devices mal ausgelesen der ist 
definitiv anders.
Wenn ich was vernünftiges habe werde ich das hier einstellen. Es ist mir 
zwar noch nicht ganz wie die App zwischen den verschiedenen Bootloadern 
unterscheiden kann.
Die App kann das auf jedenfall.

Thomas

von Thomas (Gast)


Lesenswert?

Andreas B. schrieb:
> Danke für die Info, hab dein Thread erst vor kurzem entdeckt. Nicht nur
> der Preis ist interessant, sondern auch die Gehäuseform: der ist recht
> einfach von Hand zu löten ;-)

Andreas du bist gerne eingeladen hier mitzumachen

Thomas

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


Lesenswert?

Thomas schrieb:
> Andreas B. schrieb:
>> Danke für die Info, hab dein Thread erst vor kurzem entdeckt. Nicht nur
>> der Preis ist interessant, sondern auch die Gehäuseform: der ist recht
>> einfach von Hand zu löten ;-)
>
> Andreas du bist gerne eingeladen hier mitzumachen
>
> Thomas

Ja ganz klar :)

Bin ja nun auch wieder mehr eingestiegen.



@Thomas. Es soll ja auch einen neueren bootloader geben, vielleicht hat 
ja der ch552 den alten und der ch554 den neueren bekommen.

Magst du vielleicht dein auslese programm hier hochladen? Hatte da 
vorhin etwas rumprobiert bin aber nicht ganz durchgekommen.

von Thomas (Gast)


Lesenswert?

Aaron C. schrieb:
> Magst du vielleicht dein auslese programm hier hochladen? Hatte da
> vorhin etwas rumprobiert bin aber nicht ganz durchgekommen.

Das werden ich .. Ist im Moment noch ein schneller Hack ich hab einfach 
meinen Bootloader um Vendor Requests erweitert und dann mit einer neuen 
ID den Thesycon Treiber aktiviert. Mit dem Thesycon Treiber hab ich mir 
dann den kompletten RomInhalt runtergezogen. Da der UsbCode noch eine 
Macke hat geht das immer nur einmal, dann muss man den stick neu 
anstecken. Ist also noch nicht wirklich praxistauglich.

von Andreas B. (andreasb)


Lesenswert?

Thomas schrieb:
> Andreas du bist gerne eingeladen hier mitzumachen
>
> Thomas

Bestellung ist raus - werde ich, sobald die Controller angekommen sind.

Ich habe mir ein USB to WS2812b Converter vorgenommen.
Mal schauen, dafür müsste man wahrscheinlich USB mit Polling machen, 
denn ein Interrupt geht ja eher nicht...

Mal schauen ;-)


mfg Andreas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

hier de neue (alte) bootloader als asm file. Neben einem komplett 
anderen Satz von dispatcher Funktionen is auch die Erzeugung des 
Vershlüsselungskeys anders gelößt. Wie die WCH App zwischen beiden 
Versionen unterscheidet kann ich noch nicht abschliesend beantworten. 
Ich hab den Bereich ab 0x3FF8 mal mit aufgenommen obwohl die SN nicht 
zum Bootcode gehört.
Referenzen sind aufgelöst. Einige Vars im Idata sind noch unklar.

Thomas

von Thomas (Gast)


Lesenswert?

Mir ist gerade eine Idee gekommen, wie man den Bootloader und auch alle 
anderen Inhalte zurück lesen könnte.
Es gibt ja dieses verify cmd 0xa7 beim V1
Mit brute force kann man das benutzen um einen bytewert von einer 
bestimmten Adresse zu bekommen. Einfach 0xa7 0x01 addrl addrh byte 
schicken.
Dann schauen ob OK zurück kommt. Wenn ja ist das Byte gefunden und man 
kann mit der nächsten Adresse weitermachen wenn nein byte++ und noch mal 
probieren.
Ich hab hier immer noch Probleme mit libusb und meinem Compiler.
Kann das also nicht verifizieren.
Vorher sollte man noch die Verschlüsselung ausschalten mit
0xa6 0x04 0x00 0x00 0x00 0x00

Thomas

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


Lesenswert?

Vielen dank für die Idee, versuche das gerade mal.


Zudem hier noch 2 infos falss du es noch nicht kennst:

Der Chip selber vom vom ISPtool mittels des kommandos:

0xa2, 0x13, 0x55, 0x53, 0x42, 0x20, 0x44, 0x42, 0x47, 0x20, 0x43, 0x48, 
0x35, 0x35, 0x39, 0x20, 0x26, 0x20, 0x49, 0x53, 0x50, 0x00

identifiziert und gibt dann 2 Bytes zurück, das erste ist die Chip 
version, 0x51 für CH551, 0x52 für CH552 usw.


Die Bootloader version wird mittels dem Kommando:

0xbb, 0x00

identifiziert, der chip sendet auch dort 2 Bytes zurück,

Das erste byte ist die version des Bootloaders, 0x11 für Bootloader 
version 1.1



Spiele nun mal etwas mit der Bruteforce auslese methode rum.

von Thomas (Gast)


Lesenswert?

Thomas schrieb:
> Einfach 0xa7 0x01 addrl addrh byte schicken.

Es könnte auch 0xa7 0x03 addrl addrh byte sein je nach dem ob die 
Adresse zu len dazu kommt oder nicht.
Thomas

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


Lesenswert?

Thomas schrieb:
> Thomas schrieb:
>> Einfach 0xa7 0x01 addrl addrh byte schicken.
>
> Es könnte auch 0xa7 0x03 addrl addrh byte sein je nach dem ob die
> Adresse zu len dazu kommt oder nicht.
> Thomas

Kommt soweit ich weiß nicht dazu, also einfach die Länge der Bytes ohne 
Adresse.

Das maximum der Verify bytes ist wohl 60.

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


Lesenswert?

So, bin nun zu einem ersten erfolg mit dem Bruteforce auslesen gekommen.
War leider doch nicht so einfach.

Man muss mindestens 0x10 byte als len angeben und natürlich alle richtig 
senden um eine positive Rückmeldung zu erhalten.

Wenn man nun aber am ende des flashes beginnt auszulesen ist die 
Wahrscheinlichkeit hoch das dort nichts gespeichert ist, also alles 
0xFF.

Dort kann man dann rückwärts den Sketch auslesen indem man immer die 9 
schon bekannten und den einen unbekannten byte "bruteforced". oder dann 
Richtung bootloader auslesen.

Bastel da gerade weiter.

von Thomas (Gast)


Lesenswert?

tricky die Chinesen das würde auch erklären warum die beim anderen 
Bootloader jedes 2. word beim Page Delete auslassen. Also kein bug dort 
sondern ein Sicherheitsfeature. Ziemlich cool die Jungs.

Thomas

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


Lesenswert?

Thomas schrieb:
> tricky die Chinesen das würde auch erklären warum die beim anderen
> Bootloader jedes 2. word beim Page Delete auslassen. Also kein bug dort
> sondern ein Sicherheitsfeature. Ziemlich cool die Jungs.
>
> Thomas

Ahh stimt, dadurch ist es ja wie ein passwort.
Gut gemacht, aber dauert dann ja nur etwas länger also nicht suuuper 
sicher :D

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



Lesenswert?

Bin nun etwas weiter, könnte auch erfolgreich Richtung Bootloader 
bereich auslesen anbei ein paar Bilder dazu.

Das letzte Bild ist der Anfang vom Bootloader das passt mit deiner 
Datei.

von Andreas B. (andreasb)


Angehängte Dateien:

Lesenswert?

ICs sind angekommen. Habe mal ein PCB designt (mit KiCad), aber noch 
nicht bestellt. Wer will kann ein Review machen, habs noch nicht 
überprüft, und der erste Wurf hat oftmals noch Fehler drin... Wer will 
kanns auch selbst verwenden, dann aber auf eigene Haftung ;-)

Ich werde mich nochmals melden, wenn ichs bestellt habe, und das ganze 
hoffentlich läuft...

mfg Andreas

von Thomas (Gast)


Lesenswert?

Andreas B. schrieb:
> und der erste Wurf hat oftmals noch Fehler

hat er....
1. ich würde den Chip mit Vusb versorgen. Mit 3.3V kannst du nicht 
flashen.
2. LEDs macht man bei einem 51 immer gegen + nie gegen GND.

Punkt 2 ist optional da man das Port Verhalten programmieren kann. Ich 
würde trotzdem immer nach Vcc schalten. Ich denke Aaron wird das 
bestätigen.

Thomas

von Thomas (Gast)


Lesenswert?

Ich hab übrigens jetzt endlich libusb am laufen. Das war ein echter 
Krampf im A.... Ich wusste ja von früher dass libusb unter Win, im 
Gegensatz zu Linux, nicht so der Bringer ist. Trotzdem habe ich 
eigentlich mehr erwartet. Meine Vorurteile haben sich mal wieder 
bestätigt. Wie auch immer jetzt läuft.
Mehr dazu morgen.

Thomas

von Thomas (Gast)


Lesenswert?

Thomas schrieb:
> 1. ich würde den Chip mit Vusb versorgen.

Vergiss das hast du ja schon gemacht

Thomas

von Andreas B. (andreasb)


Lesenswert?

Thomas schrieb:
> Andreas B. schrieb:
> flashen.
> 2. LEDs macht man bei einem 51 immer gegen + nie gegen GND.
>
> Punkt 2 ist optional da man das Port Verhalten programmieren kann. Ich
> würde trotzdem immer nach Vcc schalten. Ich denke Aaron wird das
> bestätigen.
Stimmt, die Konvention kenne ich eigentlich, ich habe aber bald keine 
GND Fläche mehr ;-)

Danke fürs drauf schauen, ich werds heute Abend nochmals anschauen, und 
dann etwas bestellen, wahrscheinlich mehr als eine Variante.


mfg Andreas

von Thomas (Gast)


Lesenswert?

Wenn die LEDs gegen Vcc gehen hast du den Vorteil dass Sie nach einem 
Reset erst mal aus sind. Zusätzlich musst du nicht den Port auf Ausgabe 
umprogrammieren was ev Probleme bereitet, wenn alternate Pin Functions 
benutzt werden.

Ich würde auf der Oberseite einen Jumper für den ProgMode vorsehen, das 
ist bequemer. Den Taster würde ich auf einen anderen Portpin legen.

Thomas

von Andreas B. (andreasb)


Lesenswert?

Thomas schrieb:
> Wenn die LEDs gegen Vcc gehen hast du den Vorteil dass Sie nach einem
> Reset erst mal aus sind.
Ok, ich habe zwar im Studium einen 8051 programmiert, aber nie "im 
wirklichen Leben", daran hatte ich überhaupt nicht gedacht. Habe mit 
hochohmigen Ausgängen gerechnet...

Die LEDs müssen aber auch nicht unbedingt aufgelötet werden, das ist ist 
jetzt vor allem mal für den ersten Test.

> Ich würde auf der Oberseite einen Jumper für den ProgMode vorsehen, das
> ist bequemer. Den Taster würde ich auf einen anderen Portpin legen.

Danke für den Tipp, man kann den also gedrück lassen ohne Probleme?

Ich glaube ich löte ein Chip kurz auf ein Breadboard...


mfg Andreas

von Thomas (Gast)


Lesenswert?

Andreas B. schrieb:
> Habe mit hochohmigen Ausgängen gerechnet...

nein x51 Port Pins sind anders konstruiert. Die können bei LOW 
ordentlich Strom aufnehmen sind bei HIGH aber ziemlich hochohmig. Damit 
kann man den Port Pin
Ohne Umschaltung der Richtung als Eingang verwenden er muss lediglich 
vorher auf 1 gesetzt sein. Das ist ein wesentlicher Unterschied zu 
andern MCU Familien.

Beim CH552 hast du nicht zusätzlich die Möglichkeit das Port Verhalten 
umzustellen nach einem Reset sind die Ports aber erst mal  mit Ausnahme 
der USB pins x51 kompatibel.
Glaub mir die LEDs willst du unbedingt und sei es nur um mal eine Debug 
Info auszugeben.

Den Jumper für den ProgMode musst du nachdem Anstecken wieder entfernen 
weil sonst der USB mode vermutlich nicht in die Gänge kommt. Ich hab das 
aber nie probiert. Ich starte den Bootloader per direct Call mit einem 
Taster am P3.2 Pin. Damit so ein Direct Call geht muss das aber auch in 
der FW drin sein.
Beispiel in Bootloader.c  weiter oben sich dort nach Aarons_Stick.

Thomas

von Andreas B. (andreasb)


Lesenswert?

Ich habe einen CH551G auf ein Breadboard gelötet, wird per USB erkannt, 
aber lässt sich nicht mit 
https://github.com/rgwan/librech551/tree/master/usbisp flashen.

Offenbar hat das Device die ID 0x60, welches nicht supported ist.
Ich habe kurz den loader angepasst:
1
if(inbuffer[0] == 0x51 || inbuffer[0] == 0x60)

Flashen klappte aber nicht, und ich glaube jetzt ist der Chip hin... 
Naja, kann passieren...

Wahrscheinlich das Thema oben, Diskussion über den Bootlader.
Ich habe auch CH552G und CH554G bestellt, aber keine Lust jetzt noch 
einen von Hand aufzulöten, muss daher mal noch mein Board fertig machen 
und bestellen...


mfg Andreas

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


Lesenswert?

Habe bissher leider noch keinen CH551 hier kann das mit der ID soweit 
also nicht nachvollziehen oder prüfen.

Aber wegen dem bootloader, hast du auch probiert USB Pin D+ über einen 
20Kohm widerstand an 3.3V zu hängen und dann erneut zu starten?
Im leeren zustand starten sie immer direkt in den Bootloader ohne 
widerstand.


P.s. wegen der LED beschaltung bei dem Board bin ich geteilter meinung. 
Einerseits ist es sinnvoll die Leds auf 5V zu legen weil sie dann aus 
sind, andererseits finde ich es nicht schlecht das man dadurch sehen 
kann was das board macht und weis das spannung da ist. Gerade wenn man 
den bootloader aktiviert hat.

: Bearbeitet durch User
von Andreas B. (andreasb)


Lesenswert?

Aaron C. schrieb:
> Aber wegen dem bootloader, hast du auch probiert USB Pin D+ über einen
> 20Kohm widerstand an 3.3V zu hängen und dann erneut zu starten?

Ich habe einen 10kΩ Widerstand genommen, war doch in deinem Youtube 
Video so?

Wie auch immer, ich habe das D- Kabel abgerissen. Ist jetzt wieder 
angelötet, und läuft wieder...
Ich brauche eine Platine, so Handverdratungen sind nicht so toll...

> P.s. wegen der LED beschaltung bei dem Board bin ich geteilter meinung.
Aktuell mache ich mir ein Breakout Board, daher ist es eigentlich 
egal...
Die LEDs brauche ich voraussichtlich nur zum testen, ich kann die auch 
ganz weglassen...

Ich werde mir ein Board bestellen, und dann auch ein CH552 bzw. CH554 
auflöten, und mich melden, wenn ich neue Erkenntnisse habe...

mfg Andreas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Hier mein Downloader. Die Vorgehensweise ist im cpp file dokumentiert.
Im wesentlichen muss boot1.hex aufgespielt werden. Das ist der leicht 
modifizierte Bootloader. Ich bin diesen Weg gegangen, weil man dann den 
Originaltreiber erst mal nicht abschießen kann. Dann muss mit zadig der 
libusb Treiber installiert werden.

Thomas

von Thomas (Gast)


Lesenswert?

Ich habe heute versucht den eingebauten Bootloader durch eine 
modifizierte Version zu ersetzen. Das ist mir allerdings nur teilweise 
gelungen.
Ich konnte veränderte Bootloader an verschiedenen Adressen flashen und 
auch starten. Bei der Adresse 0x3800 ist es mir jedoch nicht gelungen. 
Ein Download des Speichers bestätigt dann auch dass dieser Bereich 
unverändert den Original Loader enthält. Die Bereichchecks waren dabei 
abgeschaltet.
Das lässt eigentlich nur folgenden Schluss zu. Es gibt einen 
undokumentierten Parameter, denn man setzen muss um den Bootloader 
Bereich zu beschreiben.
Fehler in den Routinen schließe ich momentan aus da der Loader zB nach 
0x2000 oder 0x3000 problemlos geladen werden kann und dort auch 
gestartet wird.

@Aaron
Gibt einen Weg bei deinem Stick Led2 zu programmieren? Alle Versuche 
diese Led auszuschalten waren bisher erfolglos.

Thomas

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


Lesenswert?

Thomas schrieb:
> Das lässt eigentlich nur folgenden Schluss zu. Es gibt einen
> undokumentierten Parameter, denn man setzen muss um den Bootloader
> Bereich zu beschreiben.
> Fehler in den Routinen schließe ich momentan aus da der Loader zB nach
> 0x2000 oder 0x3000 problemlos geladen werden kann und dort auch
> gestartet wird.

Kann es denn auch sein das der bootloader bereich komplett gesperrt 
ist?! weil es ja auch nur beim CH554 die offizielle möglichkeit gibt 
diesen zu ändern.

> @Aaron
> Gibt einen Weg bei deinem Stick Led2 zu programmieren? Alle Versuche
> diese Led auszuschalten waren bisher erfolglos.
>
> Thomas

Du meinst die Mittlere LED? diese ist bei der Version 1 leider nicht 
schaltbar, habe nun neue PCB's hier wo sich alle LEDS's schalten lassen.

von Thomas (Gast)


Lesenswert?

Aaron C. schrieb:
> Kann es denn auch sein das der bootloader bereich komplett gesperrt
> ist?! weil es ja auch nur beim CH554 die offizielle möglichkeit gibt
> diesen zu ändern.

das wäre zwar auch möglich aber irgendwie bekommen die den Loader ja 
auch auf den Chip. Warum sollte sich bei diesem Bereich auf eimal die 
Technik ändern? Ich tippe eher auf ein anderes Flash command oder 
vielleicht ein anderer enable.

Weist du woran es liegt dass die )LED sich nicht schalten lässt? Ist es 
nur der Portpin oder ein anderer Fehler?

Thomas

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


Lesenswert?

Thomas schrieb:
> Aaron C. schrieb:
>> Kann es denn auch sein das der bootloader bereich komplett gesperrt
>> ist?! weil es ja auch nur beim CH554 die offizielle möglichkeit gibt
>> diesen zu ändern.
>
> das wäre zwar auch möglich aber irgendwie bekommen die den Loader ja
> auch auf den Chip. Warum sollte sich bei diesem Bereich auf eimal die
> Technik ändern? Ich tippe eher auf ein anderes Flash command oder
> vielleicht ein anderer enable.

Das stimmt wohl, wird ja überall ein flash sein.


> Weist du woran es liegt dass die )LED sich nicht schalten lässt? Ist es
> nur der Portpin oder ein anderer Fehler?
>
> Thomas


Also wie gesagt die mittlere led ist garnicht schaltbar. Die ist direkt 
mit 5V u d GND verbunden.
War als power led gedacht da die pins nun ja aber eh high side schalten 
oder wie man das nennt habe ich in der 2. Version alle 3 leds schaltbar 
gemacht.

von Thomas (Gast)


Lesenswert?

Ich bin mir sicher dass irgendwas übersehe. Schließlich kann der 
Bootloader ja auch config Infos in den Bereich ab 0x3ff0 schreiben.
Die Idee dahinter war eigentlich später mal den Bootloader relocatible 
zu machen.
ACALL/AJMP.Von der RTL her sollte nur die cc_case ein Problem sein. Den 
Müll mit der initialisieren Konstante hab ich sowieso schon ersetzt. 
Zusätzlich wollte ich den Bugfix unterbringen das nach dem Empfang des 
USB Setup erst mal eine eventuell vorhandene STALL condition gelöscht 
wird.
Vielleicht werde ich dazu morgen mal WCH anschreiben.

Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

auch wenn ich den Bootloader im original nicht getauscht bekomme hier 
das Projekt um einen modifizierten Loader nach 0x3000 zu schreiben und 
zu starten.
Dieses mal als komplettes Keil Projekt.

Vielleicht kann ja jemand was damit anfangen.

Thomas

von Thomas (Gast)


Lesenswert?

WCH hat mir geschrieben dass der Bootloader beim CH552 fix ist. 
Zumindest gibt es keinen dokumentierten Weg das zu ändern. Die waren 
dieses mal aber ziemlich kurz angebunden. Ich hab das Gefühl dass sie 
einfach nicht wollen. Auch zum STALL bug habe ich außer einer falschen 
Antwort keine Rückmeldung erhalten.

Thomas

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


Lesenswert?

Ok schnelle wenn auch blöde antwort.

Vielleicht muss man dann doch Richtung ch 554 gehen

von Thomas (Gast)


Lesenswert?

Ich werde die Arbeiten am Bootloader erst mal auf Eis legen. Im Prinzip 
brauch ich den ja später eher weniger. Funktionell habe ich den Chip 
soweit im Griff dass ich Anwendungen schreiben kann.
Wenn ich die usblib fertig habe werde ich sie einstellen.

Thomas

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


Angehängte Dateien:

Lesenswert?

Anbei einmal zur Vereinfachung anbei eine Pinbelegung meines "CH552 USB 
Stick"

Zudem habe ich gestern endlich mal etwas sinnvolles mit dem CH552 Chip 
gebastelt.

Ich habe mir ein Pedelec gekauft, diese sind jedoch nach dem Gesetz 
nicht selbstfahrend und man muss treten damit der Motor unterstützt.

Damit ich nun aber auf meinem Großen Grundstück nicht immer treten muss 
habe ich einen CH552 chip zwischen Hall Sensor am Fahrrad und dem 
Motortreiber gebaut, der CH552 hat aber auch nicht zuviel zu tun, wenn 
ein Button gedrückt wird gibt er an den Motortreiber ein 10mS 
Wechselndes Signal aus um das treten zu Simulieren, wenn der Button 
nicht gedrückt wird dann Schaltet er den Ausgang zum Motortreiber gleich 
dem Eingang vom Hall sensor.

Dazu hier noch ein Video Auf Youtube.
https://youtu.be/k1LjTlEypsA

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Hier mal eine CDC Implementierung abgeleitet vom original WCH CDC sample 
aber mit einigen Änderungen von mir. Der code ist noch nicht ganz 
optimal kompiliert aber im Gegensatz zum Original ohne warnings ist 
kleiner und startet auf dem CH552.
Das ganze als Projekt für Keil

Thomas

von Thomas T. (knibbel)


Angehängte Dateien:

Lesenswert?

Hallo,

dann möchte ich auch mal meinen (ersten) Beitrag hier zu den sehr 
interessanten CH552's liefern:

Ich wollte mich zuerst mal darauf konzentrieren, den Programmiermodus 
nicht über den Pin 3.6 zu initiieren, sondern (wie im WCHISPTool 
anklickbar) über den Pin 1.5. Erstens mag ich nicht, wenn die 
USB-Leitungen auf der Platine nicht sauber ohne Abzweigungen zu der 
USB-Buchse gehen, und zweitens könnte ich dadurch noch ein Bauteil (den 
20k-Widerstand vom Pin 20 (3.3V) zum Pin 3.6) sparen...

Also begann ich den zuerst geposteten Bootloader-Quelltext zu 
kommentieren. Dort werden so ziemlich gleich nach einem Reset die Ports 
abgefragt, abhängig von einem "Config-Byte" an der Adresse 3FF4h. Dann 
bin ich aber über die zweite Version eines Bootloaders ein paar Postings 
weiter gestolpert (28.03.2019) und nun wollte ich erstmal wissen, 
welchen Bootloader ich selbst denn nun wirklich in meinen CH552's habe.

Ich habe mir daraufhin ein kleines "Memory Dump"-Programm geschrieben 
(in MCS51-Assembler), welches den Bootloader von 3800h bis 3FFFh 
ausliest und über die serielle Schnittstelle ausgibt. Ich habe im 
Quelltext eine kleine Tabelle eingefügt, in der Registerwerte für 
unterschiedliche Baudraten stehen... (weil hier ja schonmal die Frage 
nach der Registerbelegung für eine (stabile) serielle Ausgabe aufkam...)

Damit kann man sich mittels eines kleinen Terminal-Programms den 
Bootloader ausgeben lassen. Ein Vergleich mit dem zweiten Bootloader 
zeigt, dass ich ebenfalls diesen Bootloader habe...

Habt ihr euch diesen zweiten Bootloader schonmal näher angeschaut? Die 
disassemblierte Ausgabe ist ja nicht sooo toll... Gibt es hier auch die 
Wahl zwischen P3.6 und P1.5, um in den Bootloader-Modus wechseln zu 
können? Oder ist er hier fest auf auf P3.6 eingestellt... Ich werde 
ansonsten wohl oder übel damit beginnen müssen, auch diesen Bootloader 
zu kommentieren... (wenigstens den Anfang).

Als nächsten Schritt werde ich auch mal versuchen im Bereich des 
Bootloaders ein paar Bytes zu ändern...

Gruß
Thomas

von Thomas (Gast)


Lesenswert?

Thomas T. schrieb:
> Habt ihr euch diesen zweiten Bootloader schonmal näher angeschaut? Die
> disassemblierte Ausgabe ist ja nicht sooo toll... Gibt es hier auch die
> Wahl zwischen P3.6 und P1.5, um in den Bootloader-Modus wechseln zu
> können? Oder ist er hier fest auf auf P3.6 eingestellt..

Hallo Thomas,
lade dir mein changebootloader.zip dort findest du die letzte Version 
des Loader von mir. Allerdings schon verändert. Die Änderungen die ich 
gemacht habe sind dort dokumentiert. Der V1 Loader fragt nur die USB 
Leitung ab die Main ist wesentlich einfacher gestrickt. Natürlich ist 
die Disassemble Ausgabe nicht so der Hit keineswegs vergleichbar mit 
handgeschriebenem Code. Das zu ändern ist aber höllisch viel Arbeit.

Ich habe es übrigens nicht hinbekommen den Loader beim CH552 
auszutauschen.

Thomas

von Andreas B. (andreasb)


Lesenswert?

Hallo zusammen

Ich habe jetzt meine Boards erhalten, und auch eins Bestückt.

Benutzt jemand wchisptool https://github.com/rgwan/librech551 ?

Funktioniert bei mir definitiv nicht, getestet unter Linux.
Der Original Loader unter Windows funktioniert, ist aber nicht unbedingt 
so mein Ding...

Mein Test ergab, das ich nach jedem versuch den Controller ein- / 
ausstecken muss (Reset ginge wahrscheinlich auch, habe aber kein 
Resetschalter aufgelötet).
1
Error while bulking in: LIBUSB_ERROR_OVERFLOW
2
Libre CH551 Flasher 2018
3
The chip id 0x50 is currently not support in this program
4
5
...
6
The chip id 0x00 is currently not support in this program
7
The chip id 0xFFFFFFF0 is currently not support in this program
8
The chip id 0x10 is currently not support in this program
9
The chip id 0xFFFFFF80 is currently not support in this program
10
The chip id 0xFFFFFFC0 is currently not support in this program

Etwas gekürzt, von mehreren Versuchen, aber ich stelle fest die ID wird 
jedes mal anders gelesen.
Der Chip ist aber in Ordnung, liess sich beim ersten Versuch mit dem 
WCHISPTool(V2.70) beschreiben...

ps. meine Projekte werde ich auf Github stellen, sobald etwas wirklich 
funktioniert...


mfg Andreas

: Bearbeitet durch User
von Thomas (Gast)


Lesenswert?

Was für ein Chip verwendst du? Welcher Bootloader ist da drauf? Das WCH 
tool sollte die Loader Version anzeigen. Beim librech551 tool sind 
einige Optionen experimental. Je nach Chip musst du selbst Hand anlegen.

Thomas

von Andreas B. (andreasb)


Angehängte Dateien:

Lesenswert?

Ich habe jetzt einen CH552 verlötet, habe aber auch 551 und ein paar 554 
hier.

Version sehe ich nirgends, habe dir den Screenshot angehängt.

@Thomas, bist du der Entwickler vom librech551 tool, oder kennst du den 
Entwickler?
Wenn ichs dann geschnallt habe, würde ich gerne das Tool oder das README 
updaten...



mfg Andreas

von Thomas (Gast)


Lesenswert?

Andreas B. schrieb:
> @Thomas, bist du der Entwickler vom librech551 tool, oder kennst du den
> Entwickler?
> Wenn ichs dann geschnallt habe, würde ich gerne das Tool oder das README
> updaten...

Nein bin ich nicht und kenn den auch nicht.
Es ist aber ziemlich sicher ein Chinese weil die Kommentare auf 
chinesisch sind.
Wenn von mir wäre würdest du englische Kommentare lesen.

Wenn du den WCH Flasher startest sollte beim Flashen eine Meldung im 
Messagefenster kommen sowas wie Bootload ver 1.10 beim CH552.

Ich hab mir das librech551 tool zwar näher angeschaut aber deine 
Meldungen deuten eher auf eine fehlerhafte Installation von Libusb hin. 
Ich bin aber etwas voreingenommen was Libusb angeht und bin auch kein 
Linux Profi.

Thomas

von Andreas B. (andreasb)


Lesenswert?

Thomas schrieb:
> Andreas B. schrieb:
>> @Thomas, bist du der Entwickler vom librech551 tool, oder kennst du den
>> Entwickler?
>> Wenn ichs dann geschnallt habe, würde ich gerne das Tool oder das README
>> updaten...
>
> Nein bin ich nicht und kenn den auch nicht.
> Es ist aber ziemlich sicher ein Chinese weil die Kommentare auf
> chinesisch sind.
Ja, das habe ich gesehen...

> Wenn von mir wäre würdest du englische Kommentare lesen.
Ich kenne deine Sprachkenntnisse nicht :-) Aber du hast recht ;-)

> Wenn du den WCH Flasher startest sollte beim Flashen eine Meldung im
> Messagefenster kommen sowas wie Bootload ver 1.10 beim CH552.
Diese habe ich nie gesehen...

> Ich hab mir das librech551 tool zwar näher angeschaut aber deine
> Meldungen deuten eher auf eine fehlerhafte Installation von Libusb hin.
Nein, ich verwende LibUsb Selbst für andere Projekte, und kenne so ein 
Problem bisher nicht... Von daher denke ich eher nicht - ich werde das 
aber noch mit einem anderen System (frisch installiert) gegenchecken, 
nur zur Sicherheit. Es könnte auch der USB Hub im Monitor, das Kabel 
oder sonst was sein...

> Ich bin aber etwas voreingenommen was Libusb angeht und bin auch kein
> Linux Profi.
OK


> Thomas
Danke für die Antwort!

Ich bin gerade an meinem ersten Projekt mit den CH55xg dran....


mfg Andreas

von Andreas B. (andreasb)



Lesenswert?

Flashen geht auch mit der Android App von Aaron C. nicht.

Ich blicke immer noch nicht ganz durch...
Ich habe selbst den Bootloader nicht überschrieben, müsste also noch 
immer der originale sein.


mfg Andreas

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


Lesenswert?

Andreas B. schrieb:
> Flashen geht auch mit der Android App von Aaron C. nicht.
>
> Ich blicke immer noch nicht ganz durch...
> Ich habe selbst den Bootloader nicht überschrieben, müsste also noch
> immer der originale sein.
>
>
> mfg Andreas

Moin, mit welchem chip war das? sieht ja so aus als wäre das der neue 
Bootloader, der ist wohl von librech551 als auch von meiner app noch 
nicht unterstützt.

das ist hier kurz angeschprochen: 
https://github.com/rgwan/librech551#todo


Funktioniert dies beim WCHISPTool einwandfrei oder geht dort auch 
nichts?
man kann beim WCHISPTool auf Function und dann ganz unten auf Bootloader 
V2.30 Previous gehen und die funktion zu aktivieren oder zu 
deaktivieren, probiere da mal bitte beide varianten.

Wenn man beim WCHISPTool auf Function geht und dann auf Verify wird im 
download Record bereich ja das verify aufgelistet und dort steht dann am 
anfang auch in Grün "Bootloader ver:x.xx


vielleicht hilft das ja.

mfg Aaron

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


Lesenswert?

Achso der Neue Bootlaoder funktioniert insgesammt ganz anders, deswegen 
kann librech551 und meine App auch nicht das richtige an versionen 
anzeigen und spielt deshalb komplett verrückt.


Ich habe leider selber keinen Chip mit dem Neuen Bootloader hier dann 
könnte man da die Kommunikation mit einbauen in die App.

: Bearbeitet durch User
von Thomas (Gast)


Lesenswert?

Aaron wenn du willst baue ich dir den neuen Bootloader so zusammen dass 
er nach 0x3000 linkt dann kannst du den Loader starten und die 
Kommunikation auf einem Chip mit v1.1 Bootloader testen. Im Prinzip 
genauso wie die changebootloader.zip nur halt mit dem anderen Loader.

Thomas

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


Lesenswert?

Thomas schrieb:
> Aaron wenn du willst baue ich dir den neuen Bootloader so zusammen dass
> er nach 0x3000 linkt dann kannst du den Loader starten und die
> Kommunikation auf einem Chip mit v1.1 Bootloader testen. Im Prinzip
> genauso wie die changebootloader.zip nur halt mit dem anderen Loader.
>
> Thomas


Ja sehr gerne dann schaue ich mir das heute Abend einmal an. Nun 
Richtung einem Geburtstag unterwegs.

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

Hier das neue Projekt um den  den v2 Loader nach 0x3000 zu flashen und 
zu starten. Das ganze als Keil Projekt für Aarons Stick. Es reicht das 
ChangeBoot.hex aus dem Out Ordner zu flashen. Da die Software die LEDs 
und SW1 von Aarons Stick benutzt ist es ohne Änderungen nicht möglich 
die FW auf einer anderen HW zu benutzen.
Weitere Infos im readme.txt

Thomas

von Andreas B. (andreasb)


Lesenswert?

Aaron C. schrieb:
> Andreas B. schrieb:
> Moin, mit welchem chip war das? sieht ja so aus als wäre das der neue
> Bootloader, der ist wohl von librech551 als auch von meiner app noch
> nicht unterstützt.

CH551g auf dem Screenshot, aber CH552g verhält sich genau gleich.

> Funktioniert dies beim WCHISPTool einwandfrei oder geht dort auch
> nichts?
Einwandfrei (Version 2.7)

> man kann beim WCHISPTool auf Function und dann ganz unten auf Bootloader
> V2.30 Previous gehen und die funktion zu aktivieren oder zu
> deaktivieren, probiere da mal bitte beide varianten.
Ich habe mein Projektcode gerade so halb am laufen - das verschiebe ich 
somit auf später, sonst gehts wieder nicht mehr ;-)

> Wenn man beim WCHISPTool auf Function geht und dann auf Verify wird im
> download Record bereich ja das verify aufgelistet und dort steht dann am
> anfang auch in Grün "Bootloader ver:x.xx
Nein.
Es steht keine Bootloader Version oder so. Das einzige was so ähnlich 
aussieht, ist
BITVER:02.31

Ich habe jetzt CDC und WS2812b am laufen. Bin mich da aber noch ziemlich 
am einarbeiten.

Ich werde mich aber sicher nochmals melden, wenn ich weiter bin... Wann 
auch immer das dann ist ;-)

mfg Andreas

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


Lesenswert?

Andreas B. schrieb:
> Es steht keine Bootloader Version oder so. Das einzige was so ähnlich
> aussieht, ist
> BITVER:02.31

Ok würde ja hinkommen. Denn ab 2.30 ist wohl neuer bootloader.



@Thomas. Vielen sehe heute abend mehr und melde mich :)

von Thomas (Gast)


Lesenswert?

Andreas B. schrieb:
> Es steht keine Bootloader Version oder so. Das einzige was so ähnlich
> aussieht, ist
> BITVER:02.31

Hehehe du bist der erste der den neuen Bootloader auf einem ch552 Chip 
hat.
Wir haben hier alle noch den v1.1

Andreas B. schrieb:
> Ich habe jetzt CDC und WS2812b am laufen. Bin mich da aber noch ziemlich
> am einarbeiten.

Ich arbeite gerade an dual CDC mit IRQ gesteuerten Fifo Buffer. Das 
sollte bald fertig sein. Es fehlt noch die Implementierung von RTS/CTS.

Thomas

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


Lesenswert?

Habe gerade mit dem einarbeiten begonnen und da ist mir eine änderung im 
librewch code aufgefallen, scheinbar macht der entwickler derzeit auch 
ein update auf bootloader 2.30 hier mehr 
https://github.com/rgwan/librech551/commit/9ad2cd7d32b0fc1c4a5ad4a1d1684a6f50ed17e9

um diesen zu nutzen beim librech commando ein "n" mit dranhängen und er 
sollte die neue version probieren.


@Thomas das aufspielen des neuen bootloaders hat einwandfrei 
funktioniert, damit kann ich arbeiten :)

von Andreas B. (andreasb)


Angehängte Dateien:

Lesenswert?

Hallo zusammen

Mein Board läuft!
Bilder im Anhang. Sollte ein "availability light" werden (einfach 
googlen für Beispiele)

Die Option für den neuen Bootloader habe ich gesehen - funktioniert aber 
(noch) nicht.

Github Link mit allen Sourcen (aber wenig Doku, ich weiss...)
PC Software fehlt noch komplett...

https://github.com/andreasb242/CH55xG-StateLight


mfg Andreas

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



Lesenswert?

Andreas die platine sieht echt gut aus :)


Habe nun schon fortschritte machen können :) kann mit der app die 
version auslesen, den flash löschen und wohl auch schreiben. Da ich aber 
nun den fake v2.30 loader habe geht das schreiben noch nicht richtig.

@Andreas würdest du mal mit beiden chips also ch552 und ch551 eine neue 
version der app probieren? Nur um zu sehen ob das lesen der versionen so 
ist wie es sein sollte.
Bzw. Kannst du mir vielleicht jeweils 2 chips zukommen lassen?

von Thomas (Gast)


Lesenswert?

Aaron mit der WCH App geht das flashen problemlos. Ich denke du hast ein 
Problem mit dem Security Key. Die Erzeugung des keys ist anders gelöst.
Der Bootkey wird in Main initialisiert es ist ein 8byte array mit 
folgendem Inhalt:

0xA5,0xF6,0x7F,0x23,0x1D,0xC1,0xD3,0x43 gespeichert in Data ab 0x22
Variable bootkey. Lass dich durch die seltsame Initialisierung nicht 
verwirren. Das Array ist konstant. Ein neuer Key wird wohl mit 0xa3 
geschrieben.
Wie das aber benutzt wird kann ich dir nicht sagen. Dazu musst du dir 
wohl die Quellen anschauen. Es wird wohl auch die Chip serial zusätzlich 
verwurstelt.

Thomas

von Andreas B. (andreasb)


Lesenswert?

Aaron C. schrieb:
> Andreas die platine sieht echt gut aus :)
Danke

> @Andreas würdest du mal mit beiden chips also ch552 und ch551 eine neue
> version der app probieren?
Wo finde ich diese?

> Bzw. Kannst du mir vielleicht jeweils 2 chips zukommen lassen?
Ich habe dir ein Mail gesendet (Mail von deiner Webseite).

Antworte doch mal kurz...


mfg Andreas

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


Angehängte Dateien:

Lesenswert?

Soooo.. gerade das erste mal erfolgreich geflasht mit bootloader 2.31 
und Android app, jetzt fehlt noch das verify(sollte laufen aber ist 
nicht prüfbar, schlägt am pc aber auch fehl) und ein bisschen aufräumen. 
Das war ne lange nacht/tag.

Habe die anderen Funktionen wie Dataflash lesen, schreiben und löschen 
sowie Reboot auch mit am laufen, eine automatische Erkennung des 
bootloaders funktioniert zumindest auf dem CH552, die anderen kann ich 
ja nicht testen :D

Achso, beim Verfiy ist alles erfolgreich nur das letzte stück wird als 
falsch gemeldet, mal sehen.



Thomas schrieb:
> Aaron mit der WCH App geht das flashen problemlos. Ich denke du hast ein
> Problem mit dem Security Key.

Den Security teil hatte ich bereit mit eingebaut, zur Vereinfachung wird 
einfach der key 0x00 genommen.

Dann wird nur die Chip id gebraucht, dann ist:
bootkey[0-6] = 0x00 und
bootkey[7] = chip_id

Das Problem wo ich nun länger dran hing war der letzte teil des bootkey 
also bootkey[7] das wird beim flashcommando über jedes achte byte 
geXort.

Nu kenne ich es aber etwas besser, im Originalen programm wird scheinbar 
ein random setkey commando generiert also cmd 0xA3, und damit einmal am 
pc der bootkey errechnet und auf dem chip ja sowieso, dann wird beim 
flashen, verify und dataflash rei um der bootkey auf dem pc gexort und 
danach wieder auf dem chip.

Schwer zu beschreiben :D

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


Lesenswert?

Ach ja klar, jetzt weis ich wieso das verify zum Schluss nicht 
funktioniert. wenn der letzte teil verify teil kleiner 0x07 gibt er ja 
automatisch nen fail zurück.

Dann muss man das letzte abfragen nochmal künstlich vergrößern.

mhh ne doch nicht ^^ auch wenn der letzte teil größer ist als 0x07 kommt 
nen fail, aber komischerweise nur beim letzten.


EDIT: Soo scheinbar ist das problem eher wenn die länge beim verfiy 
ungerade ist. und auch das schreiben des letzten teils hat dieses 
problem, baue da nochmal was ein.

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


Lesenswert?

Dank Andreas konnte die neue App nun auch mit einem echten ch551 und 
ch552 getestet werden.


Der ch552 verhällt sich scheinbar gleich dem newBootloader von Thomas 
und lässt sich flashen.

Der ch551 wird gut und automatisch erkannt jedoch lässt sich dieser 
nicht flashen. Der ch551 sendet nach einem 0xA5 schreibbefehl als status 
0xFE zurück.

Also beim ch551 scheint etwas anders im bootloader zu sein.

von Thomas (Gast)


Lesenswert?

Was meldet denn die WCH App als Bootloader Version beim 551? Ein 
einzelnes 0xFE würde ja auf V1.1 hindeuten.
Ansonsten hat der 551 ja weniger Flash die Konstanten dürften dann bei 
0x27Fx liegen. Der Bootloader muss in jedem Fall etwas anders sein schon 
alleine wegen der Range Checks in den Flashroutinen.

Thomas

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


Lesenswert?

Thomas schrieb:
> Was meldet denn die WCH App als Bootloader Version beim 551? Ein
> einzelnes 0xFE würde ja auf V1.1 hindeuten.
> Ansonsten hat der 551 ja weniger Flash die Konstanten dürften dann bei
> 0x27Fx liegen. Der Bootloader muss in jedem Fall etwas anders sein schon
> alleine wegen der Range Checks in den Flashroutinen.
>
> Thomas

Die Bootloader version wird richtig als 2.31 erkannt. Das status byte 
ist bei v2.31 das 4. Von den 6 die zurückkommen.
Die ganze antwort ist:
0xA4 0xFF 0x02 0x00 0xFE 0x00

Ich kann mir vorstellen das der ch551 ein anderes kommando für das 
flashen hat. Also byte 0 vom flashcommando.

von Thomas (Gast)


Lesenswert?

Nun dann bleibt nur die USB Kommunikation mal mit wireshark für die WCH 
App mitzuschneiden. Die App kann ja mit dem Teil umgehen. Ich gehe mal 
davon aus dass die Bruteforce Methode zum Auslesen des Loaders nicht so 
ohne weiters funktioniert.

Nachdem ich mir auch die verschieden Beispiele von WCH angeschaut habe, 
bin ich immer mehr der Ansicht dass die Programmierer dort zwar ihre 
chips beherrschen, aber nicht so viel Ahnung haben wie man auf einem 
51er mit Keil effektiven code schreibt. Das original CDC sample ist da 
so ein Beispiel dafür.

Thomas

von Andreas B. (andreasb)


Lesenswert?

Thomas schrieb:
> Nun dann bleibt nur die USB Kommunikation mal mit wireshark für die WCH
> App mitzuschneiden.

Ich hab mich grad kurz eingelesen:
https://wiki.wireshark.org/CaptureSetup/USB

>You can also capture and debug USB traffic on a virtual Windows machine under 
VirtualBox. In some ways this is more convenient than working with a separate 
Windows box.

Ich habe 4 Root interfaces, welche mir angezeigt werden, ich habe aber 
keine Aktivität gesehen beim Flashen, und ich habe alles über Hubs in 
den Bildschirmen angeschlossen...

Also für den Moment lege ich das nochmals auf die Seite...

Sonst muss ich dann doch mal noch schauen, ob ich das unter Windows 
hinkriege, ich habe aber etwas Respekt vor den Problemen, und nur dieses 
eine Windows Notebook, und keine Lust zum frisch installieren ;-)

----

Ich habe die Firmware grösstenteils mal aufgeräumt, soweit es ging. 
Damit habe ich eine halbwegs dokumentierte und wiederverwendbare CDC 
Klasse.
https://github.com/andreasb242/CH55xG-StateLight

Sicher gibt es noch das eine oder andere zu verbessern, für den Moment 
reicht es aber für mich, und ich verstehe das ganze auch mehr oder 
weniger...


mfg Andreas

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


Lesenswert?

Ich nutze dieses analyzer https://freeusbanalyzer.com ist aber leider 
auch nur windows kompatibel, sieht etwas unseriös auf den ersten blick 
aus. Hat sich aber echt bewährt und läuft auch in der kostenlosen 
version ausreichend.


Würde ja vielleicht sogar reichen einen mitschnitt zu haben oder auch 
nur einmal das senden eines flash befehles.


Theoretisch müsste aber auch das auslesen über den verify bug 
funktionieren.
@andreas magst du nochmal einen ch551 mit der zu letzt gesanten app 
flashen und ein screenshot von den letzten commandos schicken?

Dann könnte man den bootloader aus dem chip auslesen.

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


Lesenswert?

Das auslesen des Bootloader funktioniert nun halbwegs zuverlässig auf 
Version 1 des Bootloaders, die Version 2.30 kann ich leider nicht 
ausgiebig testen aber ansatzweise funktioniert diese auch.

Ich habe nun noch ein Python upload tool gefunden, 
https://github.com/juliuswwj/wchprog dieses funktioniert soweit zwar 
auch nur mit der V1 aber es könnte gut bearbeitet werden um auch V2 zu 
unterstützen.

Auf Windows läuft es auch, dafür muss mit dem Programm Zadig, 
https://zadig.akeo.ie/ der Treiber com CH55x auf libusb-win32 geändert 
werden.


Es wäre nun die frage was eher gewollt ist, ist die App schon so ok, 
soll ich lieber erstmal nur die Python variante umschreiben oder 
vielleicht beides ^^.

Wenn Jemand lust hat kann er sich natürlich auch mit der Python variante 
rumschlagen.

von Andreas B. (andreasb)


Angehängte Dateien:

Lesenswert?

Hallo zusammen

Ich habe alles vorbereitet, neues (altes...) Notebook, frisch 
installiert mit Windows 10 und Wireshark. Das Notebook ist zum Glück so 
alt, dass das Touchpad noch über PS/2 anschlossen ist, somit konnte ich 
alles sauber aufzeichnen, ohne anderen Devices.

Ich hoffe das bringt euch weiter - ich habe mich bisher nicht mit dem 
Protokoll auseinander gesetzt.

Ich persönlich würde die Python Lösung bevorzugen, denn eigentlich würde 
ich gerne direkt unter Linux flashen ;-)


mfg Andreas

von Thomas (Gast)


Lesenswert?

Ich arbeite im Moment an einer alternativen Lösung um das komplette CMEM 
von 0x0000 bis 0xFFFF zu dumpen. Ich hab den Verdacht dass die Speicher 
ev. gespiegelt sind. Das Programm wird einfach über einen Bulk EP immer 
32bytes am Stück lesen und als Hex speichern. Das Programm wird mit 
libusb funktionieren. Protokoll ziemlich ähnlich zum Loader. Wenn das so 
funktioniert wie ich mir das vorstellen kann man damit dann von jedem 
Chip in CodeImage ziehen.
Das wird aber noch etwas dauern. Die FW steht arbeite gerade an einer 
App dazu.

Thomas

von Thomas T. (knibbel)


Lesenswert?

Thomas schrieb:
> Ich arbeite im Moment an einer alternativen Lösung um das komplette CMEM
> von 0x0000 bis 0xFFFF zu dumpen. Ich hab den Verdacht dass die Speicher
> ev. gespiegelt sind. Das Programm wird einfach über einen Bulk EP immer
> 32bytes am Stück lesen und als Hex speichern.

Da bin ich ja mal gespannt... :-)

Ich habe ja weiter oben mein MemDump-Programm gepostet, welches ich 
gerade auf den gesammten Bereich von 0000h bis FFFFh erweitert habe. 
Einfach ein FT232RL-USB2Serial-Adapter an die TXD-Leitung und dann mit 
einem Terminalprogramm die Ausgabe mitschneiden.

So stellte ich es mir zumindest vor.

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

Vielleicht kannst Du das ja bestätigen?

Gruß
Thomas

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


Angehängte Dateien:

Lesenswert?

Auslesen des Bootloader's über den Verify Bug geht nun auch mit 
Bootloader V2.30

@thomas nur um es zu verstehen, du würdest dann eine Firmware flashen 
die über USB die Flash Inhalte ausgibt und diese dann in einem Programm 
annehmen und speichern?



An der Verify Bug variante finde ich sehr gut, dass wenn man nun in 
freier Wildbahn ein Produkt mit dem CH55x Chip hätte, diesen einfach 
Dumpen könnte und so an die Firmware kommt, wenn man vorher etwas flasht 
ist der chip ja gelöscht ?!

von Thomas (Gast)


Lesenswert?

Aaron C. schrieb:
> @thomas nur um es zu verstehen, du würdest dann eine Firmware flashen
> die über USB die Flash Inhalte ausgibt und diese dann in einem Programm
> annehmen und speichern?

Ja so hab ich mir das vorgestellt. Ich habe Z.B die Vermutung dass das 
Flash gespiegelt wird. Es ist nicht dazu gedacht eine Firmware 
auszulesen, da ist deine Lösung sicher geeigneter.
Ich suche  ja immer noch nach einer Möglichkeit den Original Bootloader 
zu verändern. Die Idee ist dass ev das Flash gespiegelt ist und man zum 
tauschen ev ganz andere Addressen flashen muss. Das will ich damit 
überprüfen.
Wenn Ihr den Bootloader vom ch551 gelesen habt könnte ihr in ja 
einstellen und ich checke welche Differenzen es gibt.

Thomas

von Andreas B. (andreasb)


Lesenswert?

Thomas schrieb:
> Ich habe Z.B die Vermutung dass das Flash gespiegelt wird.

Dies ist oft so, aber meist nur, weil die Unnötigen Adressleitungen 
einfach weggelassen werden.
In diesem Fall bringt dich das dann nicht weiter...
(Das würdest du feststellen, wenn die vordersten Bytes einfach egal 
sind)



mfg Andreas

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


Angehängte Dateien:

Lesenswert?

Anbei der ausgelesense Bootloader vom CH551 mit V2.31

So wie es aussieht in dem usb mitschnitt sendet das WCHISPtool ein 
WriteCfg befehl bevor das file dann eigentlich genau wie beim ch552 
geflasht wird.

von Thomas (Gast)


Lesenswert?

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

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

Thomas

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


Lesenswert?

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



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

von Thomas (Gast)


Lesenswert?

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

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

Vermutlich macht es keinen Sinn da weiter zuschauen.

Thomas

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


Lesenswert?

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

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

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

er schreibt vor dem Flashen das als config bytes cmd:

a80e000700ffffffff03000000ff520000

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

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


hilft so erstmal nicht aber ist ein kleiner überblick

von Thomas T. (knibbel)


Lesenswert?

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

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

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

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

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

Das Bit 5 im CLOBAL_CFG-Register ist leider ReadOnly.

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

Gruß
Thomas

von Thomas (Gast)


Lesenswert?

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

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

Ich werde da mal was programmieren.
Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

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

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

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

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

Thomas

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


Lesenswert?

@Thomas,
 ich habe leider keinen Mac Sry.


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

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

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



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

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

: Bearbeitet durch User
von Thomas (Gast)


Lesenswert?

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

Thomas

von Andreas B. (andreasb)


Lesenswert?

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


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

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

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

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


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

Gerne.

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

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



mfg Andreas

von Thomas (Gast)


Lesenswert?

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

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

Vielen Dank schon mal.

Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

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

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

Thomas

von Thomas T. (knibbel)


Lesenswert?

Hallo zusammen,

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

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

Folgendes habe ich versucht:

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

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

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



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

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

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




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

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

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

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

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


Gruß
Thomas

von Thomas (Gast)


Lesenswert?

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

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

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

xx durch cn ersetzen

Thomas

von Thomas T. (knibbel)


Lesenswert?

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

Danke für den Link.

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

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

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

Gruß
Thomas

von Harald (Gast)


Lesenswert?

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

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


Lesenswert?

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

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

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

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

von Thomas (Gast)


Lesenswert?

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

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

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

Thomas

von spess53 (Gast)


Lesenswert?

Hi

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

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

MfG Spess

von Stephan (Gast)


Angehängte Dateien:

Lesenswert?

Ist Protel.

von Thomas (Gast)


Lesenswert?

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

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

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

Thomas

von Harald (Gast)


Lesenswert?

Aaron C. schrieb:

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


Danke!

von K. L. (Gast)


Lesenswert?

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

von Thomas (Gast)


Lesenswert?

Ich hab dieses Wochenende Mal etwas weitergeforscht...

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

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

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

Mehr dazu in Kürze.

Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

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

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

Thomas

von Thomas (Gast)


Lesenswert?

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

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

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

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


Lesenswert?

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


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

von Thomas (Gast)


Lesenswert?

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

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

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

Du kannst das gleiche auch in deine App einbauen.

Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

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

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

Thomas

von Thomas (Gast)


Angehängte Dateien:

Lesenswert?

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

Thomas

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


Angehängte Dateien:

Lesenswert?

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


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

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

Sehr gut :)

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

: Bearbeitet durch User
von Thomas (Gast)


Lesenswert?

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

Thomas

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


Lesenswert?

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

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


Lesenswert?

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

: Bearbeitet durch User
von Thomas (Gast)


Lesenswert?

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

Thomas

von Cory (Gast)


Lesenswert?

Hi Thomas,

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

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

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

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

von Thomas Z. (usbman)


Lesenswert?

Hello Cory

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

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

Thomas

: Bearbeitet durch User
von Cory (Gast)


Lesenswert?

Hi Thomas,

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

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

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

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

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

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

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

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

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

I look forward to testing the new version.
Cory

von Thomas Z. (usbman)


Lesenswert?

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

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

Hope this hlps
Thomas

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



Lesenswert?

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

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

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

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

Die Erste version ist ja leider nicht mehr Aktualisierbar.

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

: Bearbeitet durch User
von Cory C. (corentin_c)


Lesenswert?

Hello,

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

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

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

Cory

von Thomas T. (knibbel)


Lesenswert?

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

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

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

Wenn allerdings ab 3FF4h folgendes steht:

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

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

Möglichkeit zum Testen:

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

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

Dann sollte das schnelle LED-Blinken aufgerufen werden.

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


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

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

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

Gruß
Thomas

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

von Thomas Z. (usbman)


Lesenswert?

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

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

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

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


Thomas

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

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

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

Thomas

von Peter W. (pe_wi)


Lesenswert?

Hallo

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


Viele Grüße

Peter

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


Lesenswert?

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

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

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

: Bearbeitet durch User
von Peter W. (pe_wi)


Lesenswert?

Hallo

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

Viele Grüße

Peter

von Thomas Z. (usbman)


Lesenswert?

Mir ist bis jetzt nur ein Weg bekannt den