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.
Angehängte Dateien:
-
2018-11-10_18.47.18.jpg
240 KB -
2018-11-10_18.47.27.jpg
240 KB -
2018-11-10_18.47.31.jpg
240 KB
Das klingt interessant. Danke für den Hinweis!
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.
Was ist denn der Unterschied zwischen dem 551 und 554? Letzterer ist deutlich teurer.
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.
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.
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.
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.
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
>-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€.
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
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.
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.
Hallo Aaron, gibt es hier noch neue Erkenntnisse? Hast du das Projekt weiter verfolgt? Dem Foto nach hast du davon ja einige verarbeitet.
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
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!
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
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.
Der 559 sieht auch sehr interessant aus. Mit integriertem RootHub. Entweder 2 Hosts hat man dann oder 1 Host und 1 Slave.
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.
Angehängte Dateien:
-
2019-02-14_12.06.33.jpg
210 KB
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
Ich habe die Links nicht alle durchgearbeitet, könntest du mir kurz sagen, ob das alles mit SDCC kompiliert wurde?
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
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
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.
Angehängte Dateien:
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
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.
@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
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.
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
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.
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
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
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
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
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?
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
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
>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.
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.
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
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.
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 :)
@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
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
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
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?
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.
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.
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
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?
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
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ß.
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
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.
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.
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
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
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.
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
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
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
Angehängte Dateien:
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.
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.
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.
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
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.
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
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
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
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
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.
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
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
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
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
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.
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
Verwendetes System war übrigens: Version Linux Mint 19 Tara 64-bit Kernel Linux 4.15.0-43-generic x86_64
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.
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 | }
|
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. :-(
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
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
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
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. :-(
Dann zeig mal ein vollständiges Programm so mit Clocks, kommentierte T2Initialsierung Interrupt Aktivierung.... Thomas
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
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.
Warum SP= 0xFE. Das ist hoffentlich nicht der Stackpointer... Üblicherweise macht der Compiler das selbst. Thomas
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.
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
Hier die Bin. Der Bootloader steht bei 0x3800
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
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.
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
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 | }
|
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
Angehängte Dateien:
-
2019-03-15_16.05.52.jpg
240 KB
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.
Okay, Keil hat den Bootloader nun erfolgreich Kompiliert, mann muss auch den/das richtige target auswählen :D
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
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
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.
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
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; |
Angehängte Dateien:
-
CH554.jpg
130 KB
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
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
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
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
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
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
shit man sollte immer noch mal compilieren bevor man veröffentlicht ... hier die die lauffähige Version Thomas
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
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
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
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
Angehängte Dateien:
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.
Angehängte Dateien:
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.
Angehängte Dateien:
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;
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
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
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
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
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
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
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.
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.
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
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
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
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.
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
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.
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.
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
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
Angehängte Dateien:
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.
Angehängte Dateien:
-
3D.png
170 KB -
Schema.png
14 KB
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
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
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
Thomas schrieb: > 1. ich würde den Chip mit Vusb versorgen. Vergiss das hast du ja schon gemacht Thomas
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
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
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
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
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
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.
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
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
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
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.
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
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.
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
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
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
Ok schnelle wenn auch blöde antwort. Vielleicht muss man dann doch Richtung ch 554 gehen
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
Angehängte Dateien:
-
2019-04-20_13.26.00.jpg
230 KB
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
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
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
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
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
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
Angehängte Dateien:
-
552-loader.png
31 KB
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
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
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
Angehängte Dateien:
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
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
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.
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
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.
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
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
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 :)
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
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 :)
Angehängte Dateien:
-
IMG_5617.jpg
90 KB -
IMG_5618.jpg
91 KB -
IMG_5623.jpg
53 KB -
IMG_5626.jpg
50 KB -
IMG_5632.jpg
66 KB
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
Angehängte Dateien:
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?
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
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
Angehängte Dateien:
-
2019-05-03_16.03.37.jpg
240 KB
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
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.
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.
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
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.
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
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
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.
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.
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
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
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
Angehängte Dateien:
-
2019-05-05_17.06.11.jpg
380 KB
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 ?!
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
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
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.
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
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.
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
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
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
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
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
Mist falsche Datei ausgewählt. Hier die richtige... Thomas
@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 :)
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
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
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
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
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
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
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
@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!
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.
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
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
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
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!
Hab mich hier jetzt duchgewühlt. Gibt es eine Projektseite?
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
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
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
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?
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
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
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
Angehängte Dateien:
-
CH552_V1.png
5,8 KB -
CH551_V2.png
7,4 KB -
CH551_V2.png
7,9 KB -
CH552_V2.png
5,8 KB
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!!!
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
Das erstme mal war noch ohne chip. Also das war korrekt mit no device. Soweit funktionierte es immer ohne probleme.
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
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
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.
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
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
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
Angehängte Dateien:
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.
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
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?
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
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
Hallo Ist es auf einfache Weise möglich über USB "Text" auszugeben? Viele Grüße Peter
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
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
Mir ist bis jetzt nur ein Weg bekannt den Loader dauerhaft zu deaktivieren. Dazu muss das Bit 14 im Configword geändert werden was zwar möglich ist aber nicht einfach so zu realisieren ist. Ich glaube auch nicht dass die Überschreitung der Prg Zyklen sowas bewirken kann. Das würde wohl eher zu einzelnen kaputten Zellen führen. Wie programierte du den Chip seriell? Welche Baudrate benutzt du? Thomas
Da ich mich schon länger Mal mit dem Config Wizard von Keil beschäftigen wollte hab ich mir Mal das ISD51 cfg File vorgenommen um einen Einstieg zu wagen. Der Wizard ist leider nur sehr oberflächlich in der Hilfe beschrieben. Es war also Trial and Error angesagt. Wenn man dann Mal kapiert hat wie das Teil funktioniert kann man schöne config Menüs generieren. Im Anhang das Ergebnis für die ISD51 Configuration. Der Config Editor geht natürlich nur in uVision sonst sind das einfach Kommentare. Thomas
Hallo So nachdem beide CH554_Module den Bootloader nicht mehr gestartet haben, dachte ich mir, dann kann ich denen auch noch den Rest geben, bevor ich sie entsorge... Ich habe dann von meinem selbstgebautem ISP_Tool GND, RESET, SCK, MOSI und MISO an das CH554_Modul angeschlossen. Dann mit COM1 verbunden............ Und auf einmal meldet sich der Bootlader wieder - ich kann es kaum fassen! Haben da irgendwelche Pegel an den PIN's den Bootloader wieder auf Linie gebracht? Das 2. Modul ist damit auch gerettet. Die serielle Übertragung geht jetzt auch wieder. Ich habe die chinesische Beschreibung des Moduls bemüht und habe festgestellt, daß meine Dokumentation falsch war. Die Pins für die serielle Programmierung sind: TXD1 (P1.7) und RXD1 (P1.6). Das sind gleichzeitig die Anschlüsse für SCK und MISO. Vielleicht ist das auch der Grund, daß bei meinen Spielereien mit dem ISP_Tool, der Bootloader wieder auf die Reihe gekommen ist. @ Aaron C Ich meinte "einfach". Netter Quelltext, aber ich glaube kaum, daß ich die 2 Meter Programmcode zum laufen bringe, und vom verstehen bin ich da auch weit weg - trotzdem danke. @ Thomas (Gast) Ich habe mal "freader-2" laufen lassen. Leider läuft das Programm nicht richtig. Irgenwann hängt es, und die files werden nicht erzeugt. Ich starte natürlich den Bootloader neu, aber der letzte code ist ja noch im Speicher. Viele Grüße Peter
Peter W. schrieb: > @ Thomas (Gast) Ich habe mal "freader-2" laufen lassen. Leider läuft das > Programm nicht richtig. Irgenwann hängt es, und die files werden nicht > erzeugt. mm sollte eigendlich so nicht passieren die Files werden immer erzeugt nur halt eventuell mit Unsinn. Welcher Bootloader ist bei dir installiert? Was ich mir vorstellen könnte: wenn aus irgendeinem Grund der Dptr 0x4000 erreicht bleibt der Usbcore stehen und gibt keine Antworten mehr raus. Was passiert wenn du das dumpen mit ESC irgendwann abbrichst? Alle Chips mit geraden Nummern verwenden UART 1 Txt1 und Rxt1 für den Bootloader, das war schon immer so. Solange du nicht mit der Port cfg rumspielst ist das auch der default an den entsprechenden Pins. Thomas
Firmware ist 2.31 Mit ESC bricht das Programm ab. Die Daten werden per USB übertragen? Wo wird das file abgelegt? Peter
Ja die Daten werden per USB übertragen. Die Files werden im gleichen Ordner abgelegt wo sich auch freader2 sich befindet. Beachte die beiden Bugs zum einen sind die Quersummen im Intel Hex File falsch und das 1.byte an Addresse 0 ist immer FF. Das sollte im Normalfall 0x02 für LJMP sein. Ich hab zwar beides schon gefixt will aber noch warten bis ich auch die Einschränkung mit dem Key für v2,.31 gefixt habe. Das Tool ist allerdings meines Wissens noch nie auf einem ch554 mit v2.31 getestet worden. Solltest du das irgendwie seriell probieren dürfte das nicht funktionieren Thomas
Hi Peter, I just pushed a python version of the flash dumper that should support the bootloader v2.31. The program can flash and dump the memory. Check it out here: https://github.com/sgryco/wchprog/tree/blv2 It is still work in progress and I will continue working on it to merge it with v1 support. Cory
Thomas Z. schrieb: > Alle Chips mit geraden Nummern verwenden UART 1 Txt1 und Rxt1 für den > Bootloader, das war schon immer so. Solange du nicht mit der Port cfg > rumspielst ist das auch der default an den entsprechenden Pins. Wie kann ich den Bootloader auf auf UART (TxD/RxD) ändern, und was hat es auf sich mit den Pin Bezeichnungen: TxD_/RxD_ und TxD1_/RxD1_ ? Peter
Peter W. schrieb: > Wie kann ich den Bootloader auf auf UART (TxD/RxD) ändern Kannst du nicht das ist fest verdrahtet. Vermutlich auch deshalb weil bei der 10 Pin Version des ch554 die Portpins für TxT und RxT gar nicht rausgeführt sind. Lediglich Ch551 und ch553 benutzen Uart0 weshalb die auch den V2 loader brauchen. Beim V1 loader wird immer Uart1 verwendet. Die xx_ Bezeichnungen sind für alternative Mappings da, die du über PINF einstellen kannst. Kapitel 10 im Datenblatt beschreibt das. Die Übersetzung ist aber nicht so dolle. Thomas
Peter W. schrieb: > @ Thomas (Gast) Ich habe mal "freader-2" laufen lassen. Leider läuft das > Programm nicht richtig. Irgenwann hängt es, und die files werden nicht > erzeugt. Ich habe das gestern nachstellen können nachdem ich mit dem Serial Mode etwas rumgespielt hatte. Der Reader läuft dann in einen Timeout und bricht ab. Ein Neustart des Loaders behebt das dann. Es ist wohl so, dass ab dem Zeitpunkt wenn die ersten Bytes seriell Eintreffen der USB Mode nicht mehr funktioniert. Den Reader um einen serial Mode zu erweitern macht aber nicht so viel Sinn. Bei 57k6 würde das Auslesen sehr viel länger dauern. Da meine 2 Projekte jetzt in der Testphase sind werde ich mich wohl nochmal mit den beiden Loader beschäftigen. Ich will nochmal probieren ob ich den V1 loader überschrieben bekomme, wenn ich die Params für den ICALL setze. Thomas
@Thomas, Da ich glücklicherweise einen CH559 ausleihen konnte habe ich dort auch mal den Bootloader Ausgelesen. Vielleicht liest du ja noch mit und kannst reinschauen. Geflasht wird genauso wie beim CH552 und CH551 aber er ist trotzdem anders. Konnte mit minimalen änderungen auch mit der Android App Flashen und Dumpen. Der CH559 hat 2 USB Anschlüße und Host funktion, das konnte ich mittlweile schon erfolgreich austesten bissher aber nur mit Keil und nicht SDCC. Grüße
Schau ich mir mal an. Ich hab's inzwischen übrigens geschaft in den V1 Bootloader zu schreiben. Beim V2 loader sehe ich immer noch keinen Weg. So wie ich die Sache sehe gibt es ohne custom Erweiterung keinen Weg in den V2 loader zu schreiben. Ich arbeite im Moment an einem Konzept den Loader auszutauschen. Dazu gehört im Endausbau dann auch den Loader zu deaktivieren so dass er nicht mehr per HW contition aktiviert werden kann. Die Software Aktivierung wird aber weiterhin funktionieren. Thomas
Bist du sicher dass das binary vollständig ist? Der Code ergibt Sinn wenn man nach 0xF400 disassembliert. Dann entspricht er in der Grndstruktur dem v2.31 loader. Allerdings ist das Ende etwas seltsam. Zusätzlich geht der SerialHandler wohl nur auf uart0. Alles weitere muss sich wohl zeigen Thomas
Das Ging ja fix, Finde gut das du noch immer dabei bist :D Der CH559 hat ja 0xFFFF Flash size und der Bootloader geht von 0xF400 bis 0XFFFD also das könnte schon hinkommen, ich hatte mal den gesamten bereich ausgelesen da kommt aber nicht mehr. Sollte also komplett sein garantieren kann ich es aber nicht. Soweit ich es verstanden habe ist der serialHandler auf Uart0 und den Alternativen Pins P0.2 und P0.3
Aaron C. schrieb: > Das Ging ja fix, > Finde gut das du noch immer dabei bist :D Mit dem IDA geht es recht schnell einen ersten Disassemblerlauf zu machen. Auch weil wir mittlerweile genügend Referenzen haben. Für mich sieht es so aus, dass dieser Loader eine alte Version des v2.31 Loaders ist. Es gibt beispielsweise noch den I_CALL aus dem V1 loader. Es dürfte nicht allzu kompliziert werden den in vernünftiges Format zu bringen. Thomas
Habs nun auch mal richtig in IDA einladen können, hatte vorher noch nicht die Loading Adresse hinbekommen. Man kanns aufjedenfall erkennen, aber denke da bist du besser drin. Leider geht mit der Datei ja Kein Pseudocode, das wäre einfacher. Es scheint soweit auch vieles gleich wie bei den CH552 zu funktionieren, Also Dataflash Lesen, Key setzen und Flashen etc.
Ja die Chinesen halt.... Auch wenn sich das Ding als v2.31 meldet ich werde es V2.30 nennen schon alleine deshalb weil eine Dispatcher Funktion fehlt. Nicht Mal die API ist 100% identisch. Ich frage mich wie die das mit der Versionskontrolle hinbekommen. Wahrscheinlich wissen die selbst nicht so genau welcher Chip mit welchem Loader ausgeliefert wird. Thomas
Ich muss mich korrigieren die API ist identisch. Allerdings ist der CH559 deutlich komplexer. Auch ist die SFR Belegung an einigen Stellen abweichend. Zusätzlich gibt es einige Register im XData Bereich z.b Led und USB. Aaron kennst du ein englisches Datenblatt zum CH559? Thomas
Thomas Z. schrieb: > Ich muss mich korrigieren die API ist identisch. Allerdings ist der > CH559 deutlich komplexer. Auch ist die SFR Belegung an einigen Stellen > abweichend. Zusätzlich gibt es einige Register im XData Bereich z.b Led > und USB. > Aaron kennst du ein englisches Datenblatt zum CH559? > > Thomas Kenne da leider kein englishes Datenblatt zu, nur das chinesische. werde mich aber für die nächsten 1-2 wochen nicht mit dem Thema beschäftigen können da im verdienten Urlaub :D
Thomas Z. schrieb: > Ich frage mich wie die das mit der Versionskontrolle hinbekommen. Nach Bauchgefühl und (ein klein wenig) Erfahrung... kann es durchaus sein, dass die schlicht pro Chip einen eigenen Branch von einem eigenen Team pflegen lassen. Es stammt also von einer Codebasis ab, neue Features werden aber möglicherweise pro Chip neu entwickelt (natürlich mit Inspiration vom existierenden Code). Sowas habe ich bei unseren chinesischen Firmenteilen öfter gesehen.
Hier die v2.31 loader version vom CH559. Der Code erzeugt ein zum binär file von Aaron identisches Image. Bis auf die XSFR Referenzen sind alle magic numbers aufgelöst. Im groben entspricht die Functionalität dem was wir vom v2.31 loadern der anderen Chips wissen. Es gibt aber ein paar Unterschiede im Detail. Interessant ist, dass diese v2.31 Version noch den I_CALL enthält. Thomas
um die Sache mit den Bootloadern abzuschliesen hier noch mal die bearbeiteten Loader. bootloaderV1.a51 ist der V1.1 loader aus meinen CH552. bootloaderV2.a51 ist ein V2.31 loader und stammt von sigint aus einem CH554. Der Vollständigkeit hab ich auch nochmal das h File dazu gepackt, das hat sich aber nicht geändert. Beide Loader verfügen über identische Optionen zum Einschalten verschiedener Features. Solange die Optionen auf 0 stehen und Startaddress auf 0x3800 steht wird der Code identisch zu den Originalen sein. Bis auf die Serial Option bleibt die Funktionalität mit dem Original identisch. Die Optionen lassen sich auch bequem mit dem Config Editor von µVision ändern. Als Bespiel für eine neue Funktion hab ich ein neues cmd 0xAC definiert was so ähnlich wie der I_CALL aus V1.1 arbeitet. Die Call addresse wird dabei einfach auf den Stack gelegt und mit ret gestartet. Dies dient nur als Demo um z.b ein C Programm zu starten. Die Optionen beeinflussen sich gegenseitig nicht, man kann die je nach Bedarf nutzen. Thomas
Moin zusammen, ich melde mich nach langer Pause zurück. Ich habe leider schon seit einiger Zeit nicht mehr verstanden, was ihr so macht. ;-) Das ist weit über meinem Wissensniveau. Ich habe allerdings mal etwas mit dem Python Flash-dumper rumgespielt und ihn auf Seriell umgebastelt. https://github.com/SIGINT112/wchprog By the way: Ich hab den V2.31 Bootloader aus einem CH552G nicht dem CH554... sollte aber keinen großen Unterschied machen. Ich möchte auch noch meine Hochachtung vor allen Leuten aussprechen, die am Entschlüsseln des Chips beteiligt sind. Ihr hat echt unglaubliche Skills... ich wünschte, ich könnte ansatzweise verstehen, was ihr macht. Gruß, SIGINT
Hallo Sigint, wie lange dauert es bei dir den chip seriel zu dumpen? Im Gegensatz zu dir komme ich mit Phyton nicht gut recht. Ich überlege mir dass vieleicht doch in meinen Dumper einzubauen. Du brauchst dein Licht nicht unter den Scheffel zu stellen, immerhin war es deine Loaderversion die für mich der Einstieg war. Thomas
Hallo Thomas, die Zeit ist ein Problem. Der Dump liest leider Byte für Byte. Ich muss da immer auf das Timeout von der seriellen Schnittstelle warten. Das addiert sich. Das kann man definitiv noch verbessern, wenn man die Datenlänge beim lesen kennt. Das werd ich vielleicht am Wochenende mal einbauen. Flashen geht deutlich schneller. Mit Python bin ich erst durch den dumper in Kontakt gekommen... ich kenn mich da auch nicht aus. ;-) Mein Ziel ist es für den Dumper eine schöne GUI zu basteln... entweder direkt in Python, oder ich portiere das auf Java. Gruß, SIGINT P.S.: Ich musste überigens ein paar Bootloader Kommandos anpassen, damit der Dumper mit der seriellen Schnittstelle funktioniert. Ich hab aber nicht die geringste Ahnung, was die bewirken... ich muss mir den Bootloader mal genauer anschauen. Im Moment fehlt mir leider die Zeit, da ich Spätschicht habe. :-|
Ich habe am WE eine App gebastelt die für V1.1 den Bootloader tauschen kann. Der zu flaschende Bootloader befindet sich in Image.c. Image.c wird aus dem Hex des bootloaders gebaut. Hier die V1.1 mit allen Optionen außer serial ein. in \out gibt es auch noch test_with_loaders.hex. Das ist ein Dummy Prog mit v2.3 loader ab 0x2800 und v1.1 ab 0x3000. Der Dummy kann natürlich später mit irgendwas überschrieben werden. In\tools befinden sich exe Files u.A. eine bereinigte Version des freaders sowie ein Tool um den IAP Mode einzuschalten. Die App ist relativ einfach gestrickt und auf Aarons Stick optimiert (LEDs,Taster) Eine kurze Beschreibung findet sich in den Kommentaren. Das ganze als Keil uVision Projekt. Wie gesagt V1.1 only Thomas
Thomas Z. schrieb: > Ich habe am WE eine App gebastelt die für V1.1 den Bootloader tauschen > kann WOW das ist super cool, werde es heute abend mal austesten und rumspielen. bin gespannt! Habe nun auch rausgefunden wie WCH selber es gemeint hat mit eigenem bootloader brennen, im WCHispTool kann man eine iap datei auswählen und die position derer bestimmen, das wäre dann in diesem falle der bootloader, in dem eigenen programm springt man dann einfach dort hin um den bootloader zu starten. Es wird aber nicht der pin deaktiviert und man kommt immernoch in den echten bootloader, also die verify lücke bleibt immernoch. Hatte da ein beispiel von WCH gefunden wo auch gezeigt wird was man wie in keil einstellen muss um es zum laufen zu bekommen. Aaron.
Aaron C. schrieb: > Hatte da ein beispiel von WCH gefunden wo auch gezeigt wird was man wie > in keil einstellen muss um es zum laufen zu bekommen. Ja das Beispiel kenn ich auch, das ist ursprünglich für den CH559 geschrieben worden. Ich hab das aber nie mit dem WCHIsptool auf dem CH552 zum Laufen gebracht. Das WCHIsptool steckt voller Bugs. Es ist beispielsweise auch nicht möglich ein Hex zu flaschen was nicht bei 0x0000 startet. Hier noch ein paar Infos zum IAP Konzept: IAP muss eingeschaltet werden und danach das Run Bit gesetzt werden. 0xBA, 0x04, 0x57 0xA8 0x00 0x00 schaltet die IAP Funktion ein. 0xA5, 0x02, 0x01, 0x00 setzt das Run Bit. Danach startet das Programm automatisch ab Addresse 0x0000. Das Programm lauft dann mit gesetztem bBootLoad und erlaubt so das Schreiben im Loaderbereich. Das funktioniert so nur mit V1.1 da bei V2.31 der I_CALL in main fehlt. Das ist im wesentlichen das was Thomas T und ich weiter oben diskutiert hatten. Die Quellen des V1.1 loaders hab ich noch mal etwas modifiziert Im wesentlichen ist jetzt am Ende ein Macro drinn was bis 0x7F0 den rest mit 0xFF auffüllt. Das dient hauptsächlich zum binär Vergleich. Funktionell hat sich nichts mehr geändert. Thomas
Thomas Z. schrieb: > sowie ein Tool um den IAP Mode einzuschalten Beim Testen ist mir gestern aufgefallen dass ich den Bootloader zwar mit CALL starten kann, dieser aber sofort wieder beendet wird weil die IAP Kennung noch im Flash steht. Der Start per HW contition funktioniert jedoch problemlos. Man muss also in einem 2. Schritt die IAP Kennung wieder löschen. Schade ich hatte gehofft dass es ohne geht. Da werde ich ev den Bootloader noch anpassen, da ich diesen 2.Schritt einsparen möchte. Thomas
Thomas Z. schrieb: > Schade ich hatte gehofft dass es ohne geht. Da werde ich ev den > Bootloader noch anpassen, da ich diesen 2.Schritt einsparen möchte. um mir selbst zu antworten: Das war natürlich vollkommen um die Ecke gedacht.... Es reicht schon wenn man nach dem Verify einfach die IAP Kennung mit 0xffff,0xxffff überschreibt. Thomas
Thomas Z. schrieb: > Thomas Z. schrieb: >> Schade ich hatte gehofft dass es ohne geht. Da werde ich ev den >> Bootloader noch anpassen, da ich diesen 2.Schritt einsparen möchte. > > um mir selbst zu antworten: > Das war natürlich vollkommen um die Ecke gedacht.... > Es reicht schon wenn man nach dem Verify einfach die IAP Kennung mit > 0xffff,0xxffff überschreibt. > > Thomas Klingt gut den Programmer hat man ja eh gerade dran ohne geht's ja nicht. Was ich mich noch immer Frage ist ob man den USB Host Mode auch beim ch55 2 aktivieren kann müsste mal ch 554 Chips bestellen und sehen was für Config Bytes geschrieben werden oder hat jemand vielleicht einen ch 554?.
ich hab das Programm nochmal etwas umgestellt und lösche jetzt die IAP Kennung sofort nachdem das Programm ein gesetztes bBootLoad erkannt hat. Jetzt funktioniert alles wie ich mir das vorstelle. Im Anhang das geänderte file. @Aaron Die Bits zum aktivieren des HOST modes gibts beim CH552 nicht. Es wird also nicht funktionieren. Thomas
ich hab gestern Nacht mit den beiden Bootloadern rumgespielt. Insbesondere wollte ich meine Loader Extension testen, die hatte ich bisher nur simuliert aber noch nie auf dem Controller getestet. Funktioniert einwandfrei. Bei v2.31 kann man das als Ersatz für den fehlenden I_CALL benutzen. Ich habe mehrmals abwechselnd die Loader auf meinen CH552 geflashed. So weit so gut.... Dann bin ich auf die Idee gekommen das NOP an offset 0x3803 dazu zu verwenden die gesetztn Optionen zu codieren. Die Idee war einen einfachen Weg zu schaffen, die gesetzten Optionen per Softare auslesen zu können. Hat auch funktioniert .... Ich habe jetzt allerdings einen Controller mit deaktiviertem HW Bootloader. Per Software komm ich immer noch rein. Das NOP darf also nicht gelöscht oder verändert werden. Ich habe damit einen zusätzlichen Weg gefunden die HW Aktivierung des Loaders zu deaktivieren. Ich hätte mir das eigendlich denken können, da der Keil von sich aus keinen NOP an der Stelle plazieren würde. Der wurde absichtlich von WCH in den Startup Code plaziert. Thomas
Dies klingt stark nach debugging peripherial wobei der debuggingvector als bootloader genutzt wird. Würde bei otp Sinn ergeben da dann ein patching einfach möglichlççggx wäre. Dies ist bei otp besonders hilfreich.
Angehängte Dateien:
-
rand.png
13 KB
Einen kleinen Hinweis hab ich noch zum V2.31 Loader. Dort wird ja in main der Bootkey mit etwas seltsamen Werten initialisiert. Es ist einfach so, dass dazu die Keil rand () Funktionen genutzt wird.
1 | char Bootkey[8]; |
2 | ...
|
3 | for (i=0;l<8;i++) Bootkey[i] = rand (); |
Thomas
Moin diese Werte sind dann jedesmal gleich? Weil alles an der gleichen Stelle ist? hast du vielleicht den Source Code für dein changer_iap programm für alle ? Hatte das letztens mal ausprobiert aber nicht hundertprozentig verstanden was dort passiert Habe auch ein mehr oder weniger nützliches Projekt mit dem Chip gemacht. Eine Propeller clock die über USB programmierbar ist ist aber eher ein joke project. https://youtu.be/38hobZsm4nM minute 26:00 viele Grüße Aaron
Aaron C. schrieb: > diese Werte sind dann jedesmal gleich? ja rand() erzeugt bei jedem Start die gleiche Folge von Zufallszahlen. Das machen eigentlich alle C Compiler so. Das ist auch der Grund warum man das einfach durch eine fixe Folge ersetzen kann. Aaron C. schrieb: > hast du vielleicht den Source Code für dein changer_iap programm welchen source meinst du? Im zip sollte alles drinn sein. Lediglich compare.c solltest du im Projekt aktualisieren. Oder meinst du was ganz anderes? Thomas
Achso, sorry meite die v1_tools.exe aus dem zip file. Übrigends hatte ich auch noch die idee fals der complete flash beschrieben sein sollte das man dann ja theoretisch nicht die dump variante nutzen kann. dadurch das man aber den dataflash nach belieben schreiben kann kann man auch vorher einen bekanten werd reinschreiben und von da dumpen, auch wenn man es eigentlich eh nicht braucht weil man ja auch den bootloader kennt.
Und noch eine kleine story, es gibt den chip CH9350L von WCH der genutzt wird um usb geräte über eine serielle verbindung miteinander zuverbinden oder seriell zugänglich zu machen. https://lcsc.com/product-detail/USB_CH9350L_C109472.html Dieser kahm mir verdächtig gleich dem CH559, habe vom CH9350L welche bestellt und konnte diesen erfolgreich in Bootlaoder modus setzen und mit der App auslesen, die daraus entstandene HEX datei konnte erfolgreich auf einen CH559 geflasht werden. Auch konnte ich den CH9350L einfach umflashen ^^ Der Dump hat ca. 35Minuten gedauert bei einer dateigröße von ca.45Kb
Aaron C. schrieb: > Übrigends hatte ich auch noch die idee fals der complete flash > beschrieben sein sollte das man dann ja theoretisch nicht die dump > variante nutzen kann. nun ich kann dir versichern, das es mit Versionen die ich kommerziell benutzen werde nichts mehr wird mit dem dumpen. Zum einen benutze ich eine spezielle Version des Verify cmds das im Bootloader Bereich nur noch Error meldet, zusätzlich ist der unbenutzte Bereich im Flash mit Zufallszahlen gefüllt. Der einzige Nachteil ist dass ich zwingend auf Chips angewiesen bin die Initial den den V1.1 loader drauf haben. Es sei denn ich finde doch noch einen Weg in den Original v2.31 loader zu schreiben. Mir ist nicht klar wie du das mit dem Dataflash umgehen willst. Den source der v1_tools lade ich später hoch. Thomas
Ja das war auch eher auf den originalen Bootloader bezogen, wenn man diesen zb. nicht mehr ändern könnte ab v2.31 währe dieser wahrscheinlich auch auf Chips in freier Laufbahn. Bei einem eigenen Bootloader hat man natürlich mehr Möglichkeiten zum Schutz, man könnte bei einem fehlgeschlagenen verify den Chip bis zu einem Reboot z.b. sperren oder ähnlich. Vielen dank aber aufjedenfall!
Anbei die v1_tools. Da sind nicht so viele Komentare drin, das Prinzip sollte aber klar werden. Zusätzlich nochmal compare.c Da hab ich die Entscheidung ob tatsächlich geflashed werden muss in die Flash Routine verlegt und prüfe ab ob es sich um einen CH551 .. CH554 handelt. Thomas
Cool vielen dank! Habs nun auch endlich verstanden, du hattest es ja eigentlich schon etwas weiter oben erwähnt aber ich habe es einfach nicht gecheckt :D
Es wurde ein Test für einen Mikroe-Pascal-Compiler durchgeführt, und bei LED-Blinken und Serien-Comination wird bereits gearbeitet
Aaron C. schrieb: > Dieser kahm mir verdächtig gleich dem CH559, habe vom CH9350L welche > bestellt und konnte diesen erfolgreich in Bootlaoder modus setzen und > mit der App auslesen, die daraus entstandene HEX datei konnte > erfolgreich auf einen CH559 geflasht werden. Ja solche Applikationsprozessoren sind üblich, allerdings wird sowas normalerweise besser geschützt. Ich wette mal, dass der CH340 in Wirklichkeit auch nur ein CH55x ist. Kannst du den Code aus dem CH9350 hier einstellen? Thomas
@Thomas, Ja kann mir das beim CH340 auch vorstellen, habe da auch mal in die richtung versucht was zu finden aber die beschreibung des EEPROM im CH340, das benötigte Hühnerfutter und das Pinout spricht nicht für einen Bekannten chip. Lade die Binary vom CH9350 hier mal hoch auch wenn ich nicht weiß wie das rechtlich aussieht! Auf Hackaday war heute ein Projekt gepostet: https://hackaday.com/2019/10/10/the-next-generation-arduino-nano/ dort wird der CH551 als ISP Programmer mit Serial converter genutzt, bin da auf den Code gespannt, habe den ersteller mal angeschrieben.
Danke ich wollte eigentlich nur mal ausprobieren wie gut das Erkennen von Keil Libs in IDA funktioniert... Funktioniert gut IDA hat auf Anhieb 15 lib Funktionen (small) gefunden. Mal schauen ob's mehr werden wenn ich large wähle. Dieses Flirt ist schon eine feine Sache. Thomas
Hatte das BIN natürlich auch mal in IDA geworfen aber nicht viel gemacht, da ich das was anderes schon in arbeit habe was sehr gut funktioniert. kannst ja gerne, falls du das Programm etwas entschlüsselt hast, hier was zu posten, bin daran trotzdem sehr interessiert.
Angehängte Dateien:
-
flirt.png
110 KB
Hier ein Bildschirmfoto was Flirt auf Anhieb gefunden hat. Zumindest Teile der App sind im large Mode übersetzt. Thomas
@Max, bei welcher application meinst du das? Wenn du ein eigenes programm schreibst ist es möglich ja.
@Aaron: Der Chip wäre an einer USB Port angeschlossen der immer Strom hat. Der Chip würde dann dazu dienen um zu sehen wann das angeschl. Gerät (Notebook) an und wann aus ist (Suspend mode). . LG!
Max M. schrieb: > Der Chip wäre an einer USB Port angeschlossen der immer Strom hat. Der > Chip würde dann dazu dienen um zu sehen wann das angeschl. Gerät > (Notebook) an und wann aus ist (Suspend mode). Ja so ein Device kann man relativ einfach bauen. Es würde aber die USB Spec verletzen da ein USB Device was einen Suspend Befehl bekommt so gut wie keinen Strom mehr aufnehmen darf. Wenn ich mich richtig errinnere ist der zulässige Strom bei Suspend 500uA, zuwenig für eine LED. Thomas
Aaron C. schrieb: > kannst ja gerne, falls du das Programm etwas entschlüsselt hast, hier > was zu posten, bin daran trotzdem sehr interessiert. Ich hab mal etwas in den Code geschaut. Leider haben die Jungs bei WCH das Teil im large Mode übersetzt was die Sache ziemlich unübersichtlich macht. Man kann aber gut die Lücke erkennen, die durch einen Bug im WCH Isptool verursacht wird. Speicher der im Hex undefined ist wird vom Tool mit 0x00 initialisiert. Besser wäre 0xFF damit keine Flashzyklen verschwendet werden Ab 0x8C00 beginnt das IAP Device. Man muss den Code also aufteilen in Normaldevice und IAP device Die Descriptoren werden ins xram kopiert und dort je nach Mode gepatched. So richtig interessant ist der Chip für mich nicht. Der tunnelt einfach HID Tastatur und Maus über eine serielle Schnittstelle. Auf dem Debug Pin werden seriell mit printf ein paar Status Daten ausgegeben Thomas
Der CH559 ist leider etwas sperrig, nicht so übersichtlich wie ein CH552. Das liegt vermutlich daran dass das Teil auch Hub und Host kann. Im Ergebnis ist es so dass die gleichen SFRs unterschiedliche Namen und Bedeutungen bekommen wenn der Host Mode aktiviert wird. Das kann man auch schön im h File erkennen. Ein Beispiel: Im Device Mode gibt es UEP3_CTRL (sfr 0xD3) das gleiche Register heißt im Host Mode UH_TX_CTRL natürlich auch mit anderen bits. Ziemlich hässlich... Ich habe damit begonnen mir den Code ab 0x8c00 anzusehen (IAP im Host Mode) weil mich der Host Mode prinzipiell interessiert. Dabei sind mir ein paar böse Fallen aufgefallen. Im h.file werden die DMA Buffer Addresse explizit nach unint16_t gecastet was bei Keil in Big Endian funktioniert. Wenn ich mich richtig errinnere, ist der SDCC little endian, dort geht das schief. Das h File braucht in jedem Fall einige Anpassungen für den SDC. Zusätzlich hat WCH sehr oft long und int verwendet auch wenn das gar nicht notwendig ist. Der code ist dadurch ziemlich aufgeblasen. Thomas
Cool danke fürs genauer hinschauen. Habe mir eine platine für den CH3950 angefertigt und nutze darauf einen CH559 mit dem code und ein Funk Uart module, dadurch hat man quasi funk usb wenn auch nur HID devices also etwas lächerlich. Aber genau das sollte es auch werden, nen video darüber folgt noch. Ich habe den CH559 unter SDCC am laufen, werde dazu auch noch was veröffentlichen, aber erst später.
Du hast also eine Funk Tastatur/Maus gebaut... Hihi Thomas
Korrekt. Soll eigentlich nur nen joke fürs video sein... also das war beabsichtigt^^ Muss aber sagen, das ganze läuft ohne lags und einwandfrei von anfang an.
Ich werde wohl am Wochenende etwas Code posten. Muss mir erst Mal noch ein paar Makros schreiben damit der Umgang mit den longs übersichtlicher wird. Das ist im Moment eine einzige mov Orgie. Da kann man nichts erkennen. Thomas
Ein kleines Update zu diesem IAP Mode des CH559: Der IAP Mode enumeriert als Host ein abgeschlossenes USB Device (am Port0). Ich habe Hinweise gefunden dass es dabei um ein Diskdevice handeln muss. Class=0x08 Bei WCH heißt das wohl UDISK. Allerdings finde ich dafür keine Descriptoren, es ist also möglich dass diese dynamisch erzeugt werden. Teile des Codes entsprechen im wesentlichen dem was WCH unter usbhost.c in diversen Beispielen zeigt. Wenn ich das richtig interpretiere benutzt der PC folgenden Request um ein Byte an den IAP Host zu senden: 0xA1 0xFE 0x00 0x00 0x00 0x00 0x01 0x00 Das ist ein Class Request mit bRequest 0xFE und einem Byte Daten. Ev ist das ein Verschlüsselungskey da der Request 10 mal ausgeführt wird. Diese Daten werden jedenfalls kräftig durchgeführt. Was danach passiert ist mir noch nicht entgültig klar. Es sind 2 ziemlich lange Funktionen im Code die permanent longs schieben, addieren vergleiche, subtrahieren.... Zusätzlich ist mir aufgefallen dass UH_TX_CTRL bzw UH_RX_CTRL mit Werten beschrieben werden die nicht definierte Bits enthalten. Das halte ich für Fehler die aber wohl keine Rolle spielen. Thomas
Moin, Muss zugeben das ich dir da leider nicht ganz folgen kann. Welchen IAP mode meinst du genau? Als info falls du es noch nicht weißt der CH559 kann ja auch UDISK im Host mode ansprechen, also daten vom usb stick lesen und schreiben. Das aber nur mit einer precompilierten Library, denke aber das du das schon gesehen hast. Grüße
Aaron C. schrieb: > Welchen IAP mode meinst du genau? Der Code den du aus dem CH3950 gepostet hast besteht aus 3 Teilen HID Host Mode, HID Device Mode und eben dem IAP Mode. Ich habe mich auf den IAP Mode konzentriert ab 0x8C00. Der Code ist wohl dazu gedacht die FW zu aktualisieren. Das mit precompiled Libs ist kein Problem die kann ich konvertieren und dann in IDA mit Flirt laden. Dann habe ich die Funktionsnamen und auch Variablen drinn. Thomas
Ahhh nun wird es mir klar!. Ich hatte den Code ja über den ganz normalen Bootloader ausgelesen. Bis du dem IAP teil hatte ich mich nicht vorgewühlt. Komisch das die es dann nicht einfach mit dem Normalen Bootloader nutzen, wo es insgesammt ja nicht so auf security gebaut ist.
Naja dass der Bootloader derart einfach zu hacken ist, war den Jungs bei WCH sicher nicht klar sonst hätten sie kaum den Aufwand mit den Bootkeys getrieben. Ich habe ein PDF gefunden was von IAP Security Keys spricht und es gibt auch spezielle Update Tools. Thomas
Aaron C. schrieb: > Das aber nur mit einer precompilierten Library, Example 12 deckt sich weitgehend mit dem IAP Code und ist im Source verfügbar. Da kann man auch gut erkennen dass die Jungs den Large Mode verwenden. Thomas
Ich hab mich jetzt durch den IAP Code gewühlt und denke dass ich das auch soweit verstanden habe... Der Beispielcode von WCH war da eine große Hilfe. Das Ding funktioniert so dass der Chip im Host Mode initialisiert wird und dann einfach gewartet wird bis ein MemoryStick angesteckt wird. Dieser wird dann enumeriert und im Rootverzeichnis nach einer Datei CH9350_LE.IN oder CH9350L_KM gesucht. Diese wird gelesen und geflashed anschließend macht das Ding einen Softreset. Der Stick muss FAT32 formatiert sein. Die Auswertung des MBR ist ziemlich ineffizient gelöst die Konvertierung Von LSB zu MSB First viel zu umständlich. Gut die Hälfte des Codes macht nichts anderes als ein paar longs aus einem Diskpuffer zu lesen etwas rumzurechnen und die Ergebnisse zu speichern. Ich werde heute Abend zwei Funktionen in Assembler einstellen die Long oder Word Variablen mit Offset aus einem Buffer lesen und die Daten dann MSB First zurück liefern. Damit sollte das Auswerten von MBR und FAT wesentlich einfacher gehen. Benutzer des SDCC brauchen das nicht da der auch LSB first macht. Thomas
@thomas Schade dass die nicht dann gleich uDisk über Seriel mit einprogrammiert haben, aber ich denke das ist deutlich aufwendiger. Habe heute morgen gemerkt( anhand des Schaltplanes) das bei meinem USB-Stick scheinbar USB Plus und USB Minus vertauscht sind. Habe bisher keine Probleme damit gehabt aber musst mal ausprobieren wie es sich verhält wenn man sie vertauscht bzw richtig polt. Wenn ich in meinem autoladeadapter den USB-Stick eingesteckt habe und das Auto starte ist dieser immer in den Bootloader Modus gegangen vielleicht liegt es ja an der Verpolung. Werde es heute Abend mal ausprobieren.
Ok, da muss ich mich selber korrigieren :D Es ist ein fehler in dem Schaltplan, aber nicht auf dem Fertigen PCB. Also Auf dem "USB-Stick" ist nicht plus und minus vertauscht, aber auf dem EasyEda Schaltplan ist wohl das Bauteil nicht ganz richtig. weiß nicht genau was dort schief, bzw, richtig gelaufen ist :D, scheinbar habe ich den USB Connector gespiegelt https://easyeda.com/lolerino/ch552g
Wenn du wirklich USB+ und USB- vertauscht hättest, wäre der Stick nie gelaufen. Vermutlich das übliche Stecker Buchse Problem. Das der Stick im Auto in den Loader Mode geht, liegt vermutlich daran, dass im Ladegerät Widerstände verbaut sind um ein Ladegerät zu melden. Ich habe übrigens angefangen UDisk zu überarbeiten. Ich bin überzeugt dass man das wesentlich kürzer hinbekommt. Das Original belegt immerhin ohne Debug 6KByte Rom und sehr viel XRam. Warum der Bootloader bei 0xF400 startet und nicht bei 0xF800 hab inzwischen auch verstanden. Das liegt ganz einfach daran, dass der CH559 gelöscht werden muss (1k Blöcke) und da die ans Ende Config Infos schreiben, mussder letzte Block vorher gelöscht werden. Es stehen für den Loader also praktisch auch nur 4k zur Verfügung die restlichen 2k kann man nicht nutzen. Thomas
hier erst mal ein Assembler modul für Keil, was in der Lage ist longs / und Words in LSB first auzulesen und in MSB first zurück zu liefern. WCH macht das folgendermasen:
1 | ...
|
2 | CH559vSecMBR = ((uint32_t)UDiskTmp[offset+11]<<24) |
3 | |((uint32_t)UDiskTmp[offset+10]<<16) |
4 | |((uint16_t)UDiskTmp[offset+9]<<8) |
5 | | UDiskTmp[offset+8]; |
6 | ...
|
mit dem Asm Modul wird das wesentlich efektiver. Beim SDCC geht das ganze natürlich direkt.
1 | ...
|
2 | CH559vSecMBR = SwapReadLong(UDiskTmp,offset+8); |
3 | ...
|
Thomas
Da mir der UDisk Code von WCH dann doch etwas zu undurchsichtig war habe ich die relevanten Funktionen für den PC portiert und damit einen MemoryStick angesprochen. Funktioniert soweit ganz gut lediglich an den MBR komme ich nicht ran, da ich Fehlermeldungen erhalte wenn ich den Stick als PhysicalDrive öffnen will. Auf drive no Ebene kann ich Sektor für Sektor lesen und finde auch das File bezogen auf den Partition Start. Soweit so gut nun zu den Problemen. Die Flashfunktion IAP_PROM() ist m.M. nach Buggy. Die schreibt jeden Sektor des Fileinhalts an die gleiche Addresse. Prog_Word() ermittelt die Startadresse von Prog_Word() und justiert den Flashbefehl so dass dieser immer an einer ungeraden Adresse steht. Welchen Sinn das genau hat habe ich noch nicht rausgefunden. Mehr dazu wenn ich den Code vollständig habe. Thomas
Hier nun der Code für den PC um lowlevel auf einen Memory stick zuzugreifen. Der source ist ausführlich kommentiert, die Funktion sollte also klar sein. Der Code besteht aus 2 Teilen: Teil 1 dient der Simulation und emuliert einige Funktionen. Teil 2 enthält den Code der auch auf dem CH559 zum Einsatz kommt. Diser Teil enthält einige Optimierungen für 8 Bit Compiler. Einige dieser Stellen sind durch Kommentare gekennzeichnet. Auf einem PC würde man einiges wohl anders lösen. Alle globalen Variablen enthalten keil spezifische Modifier die auf einem PC Compiler in nichts umdefiniert werden. Die FAT32 spezifischen Buffer Offsets sind in fat32.h definiert Thomas
Das ist ziemlich cool ! Finde ich gut :) Habe es mir gerade mal grob angesehen, versucht mit mingw zu kompilieren aber das funktioniert nicht so richtig, werde es nochmal mit Borland probieren.
Du hast gesehen dass fat32.h in einem \inc directory liegen muss? Das ist Teil meiner Keil Folder Struktur. Was für Fehler bekommst du unter mingw? Der Code sollte sich übersetzen lassen solange eine windows.h existiert. Das ist notwendig damit Createfile() und SetFilePointer() funktionieren. Thomas
Noch ein Nachtrag: Wenn man den Stick an Libusb oder WinUsb bindet kann man sehr wahrscheinlich alle Funktionen Low Level abbilden. Der Stick wird sich dann aber vermutlich nicht mehr als Memory Device am PC anmelden lassen. Auf diese Art der Emulation habe ich bisher bewusst verzichtet. Das schien mir dann doch etwas zu aufwendig zumal dann auch das Installationsproblem hinzukommt. Thomas
Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller (Musikinstrument) anzuschließen und auszuwerten?
Audiomann schrieb: > Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller > (Musikinstrument) anzuschließen und auszuwerten? Ja, wenn du den Code dazu selbst schreibst. :) Aber USB-MIDI ist ein sehr einfaches Protokoll: es gibt einen Bulk-Endpoint, über den die MIDI-Nachrichten gesendet werden, verpackt in 32-Bit "USB-MIDI Event Packets" (siehe Kapitel 4 der USB-MIDI-Spezifikation).
Audiomann schrieb: > Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller > (Musikinstrument) anzuschließen und auszuwerten? Sich mit diesem Chips zu beschäftigen ist rausgeworfene Zeit. Hast du Zeit zu verplempern?
Audiomann schrieb: > Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller > (Musikinstrument) anzuschließen und auszuwerten? Das hängt davon ab ob du ein UsbMidiDevice oder einen UsbMidiHost bauen willst. Device geht auf jedem der CH5xx Controller. Host theoretisch auf dem CH554 der aber vermutlich zuwenig RAM und Flash hat. Da ist der CH559 besser geeignet. Ein Beispiel für ein UsbMidiDevice habe ich weiter oben gezeigt.
Ehrlich gesagt kann ich nicht ganz nachvollziehen warum man sich die Informationsschwierigkeiten mit einem ganz fern hergestellten Produkt antun will. Da hat man es mit Produkten westlicher Hersteller wesentlich besser. Bei uns gibt es Datenblätter, App. Notes und Debug/Programmier Tools in Hülle und Fülle. Auch besteht oft eine nützliche große User Community. Hat das wirklich sinn, oder ist das ähnlich wie "Ich habe Mt. Everest erstmal bestiegen" wo halt der Weg das eigentliche Ziel und Spass an der Freude die Hauptmotivation ist? Irgendwie will mir der Sinn des Ganzen nicht ganz in den Kopf.
Der Gespensterreiter schrieb: > Irgendwie will mir der Sinn des Ganzen > nicht ganz in den Kopf. Das wurde ganz oben im Thread schon ausgiebig diskutiert. Im Grunde hast Du Dir die Antwort aber schon selber gegeben.
Ein kleines Update zu UDisk Emulation: Ich habe heute einen alten 1GB Stick, den ich sowieso nicht mehr benutze, genommen und mal probehalber mit zadig an libusb gebunden. Wie erwartet taucht der Stick dann nicht mehr als Laufwerk auf und ich konnte LL die ersten Kommandos absetzen. Auf diese Weise kann man den kompletten Host Mode abbilden und die Firmware auf dem PC emulieren. Mal schauen was daraus wird. Thomas
@thomas. Ja die .h datei habe ich im code geändert aber trotzdem wollte es nicht. Eine richtige fehlermeldung gibt es leider nicht. GCC gibt 2 minuten lang den inhalt diverser dateien aus. Weiß noch nicht richtig was da schief läuft
Aaron C. schrieb: > GCC gibt 2 minuten lang den inhalt diverser dateien aus. Weiß noch nicht > richtig was da schief läuft Das kann eigendlich nur eine Ursache haben: CreateFile() oder SetFilePointer() macht bei dir was falsch. Bau ans Ende von UDisk_ReadOneSector() mal ein Exit() ein. Und gibt ein paar zusätzliche Statusmeldungen aus. Den Code hab ich StackOverflow geklaut. Dann sollte schnell Klarwerden was da nicht so richtig will. Alternativ kannst du die Ausgaben auch in ein Log umleiten und dann die ersten Zeilen genauer betrachten. Thomas
Götz schrieb: > Sich mit diesem Chips zu beschäftigen ist rausgeworfene Zeit. Hast du > Zeit zu verplempern? Ganz sicher nicht, daher hatte ich ja die USB-Fachmänner kurz befragt, ob sich ein Befassen mit diesem Chip lohnen könnte. Thomas Z. schrieb: > Audiomann schrieb: >> Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller >> (Musikinstrument) anzuschließen und auszuwerten? > Das hängt davon ab ob du ein UsbMidiDevice oder einen UsbMidiHost bauen > willst. Wenn schon, dann host! Der Chip muss den Musik-Controller ja erkennen und bedienen, also anfragen, Daten holen und zwischenspeichern und gfs auch welche senden. Einige haben LEDs, welche Zustände zeigen. Der Gespensterreiter schrieb: > Da hat man es mit Produkten westlicher Hersteller wesentlich > besser. Beispiel?
@thomas Hatte auch an die ersten zeilen geschaut aber selbst da war keine fehlermeldung. Nun wollte ich davon ein screenshot erstellen und siehe da, es compilliert ohne probleme. und auch das programm läuft, nun muss ich mir auch einen usb stick raussuchen. Witziger weise habe ich nähmlich genau vor einer woche damit angefangen auf dem pc gcc zu testen und dann kommst du :D @Audiomann Ein Midi Host ist machbar mit dem CH559 (wohl auch CH554, wie thomas aber schon sagte etwas wenig ram und der Preisunterschied ist nicht groß) Und der Einwand von Götz ist komisch, man hat wenn man bei einem Bare Chip anfängt die gleiche arbeit vor sich ob nun dieser oder ein anderer USB host Chip, wenn man eine Komplett Lösung kauft ist es natürlich was anderes.
@Aaron freut mich dass es jetzt bei dir tut. Ich bekomme mittlerweile meinen Stick mit libusb genauso enumeriert wie das UDisk macht. Die MaxLun Geschichte geht auch schon, ich verstehe allerdings nicht warum WCH das Kommando 10 mal absetzt. Heute habe ich das BulkOnly Cmdset implementiert das hat aber noch Fehler. @audioman Lad mal diese zip von WCH da ist auch was für Midi dabei. http://wch.**/download/CH559EVT_ZIP.html und http://www.wch.**/public/uploads/file/20180207/1517992523119473.rar **durch cn ersetzen Thomas
Eine neue Version der UDisk Emulation dieses mal für libusb Thomas
Ich habe jetzt die IAP Firmware von WCH basierend auf den Simulationsergebnissen in 5 Files aufgeteilt. Dies vor allem vor dem Hintergrund dass ich daraus auch eine Lib bauen will und Host Code vom UDisk Code trennen will. Damit sollte es dann möglich werden mit wenigen Änderungen auch etwas andere als einen Stick zu enumerieren. Speziell wenn man eine Lib bauen will ist es sinnvoll Funktionen in seperaten Files zu legen, damit später der Linker nicht unbenutzte Funktionen zum Programm linkt. Jede einzelne Funktion in ein separates File zu legen ist dann aber etwas zuviel des guten. Das klappt schon ganz gut der Code belegt im Moment um die 4Kbyte. Variablen passen gerade so ins data Segment. Das idata Segment ist noch komplett frei. Im xdata sind 2x64 Byte für USB und 512 Byte für den Sectorbuffer belegt. Wenn es bei den 4k bleibt kann also das zu flashende File max 56kbyte haben. Es würde sich folgende Memory Map ergeben: 0x0000 .. 0xDFFF Anwender Code 0xE000 .. 0xF3FF UDisk/IAP 0xF400 .. 0xFFFF Bootloader Thomas
folgender Code (Keil C51)
1 | uint8_t IAP_ProgWord(uint16_t Addr,uint16_t Data) |
2 | {
|
3 | ROM_ADDR = Addr; |
4 | ROM_DATA = Data; |
5 | if (ROM_STATUS & bROM_ADDR_OK) |
6 | {
|
7 | if ((uint8_t) &IAP_ProgWord & 0x01) |
8 | {
|
9 | ROM_CTRL = ROM_CMD_PROG; |
10 | _nop_(); |
11 | }
|
12 | else
|
13 | {
|
14 | _nop_(); |
15 | ROM_CTRL = ROM_CMD_PROG; |
16 | }
|
17 | return((ROM_STATUS ^ bROM_ADDR_OK) & 0x7F); |
18 | }
|
19 | else return(bROM_ADDR_OK); |
20 | }
|
was der Code macht ist soweit klar. Er sorgt dafür, dass ROM_CTRL = ROM_CMD_PROG; immer an einer ungeraden Addresse steht auch wenn die Funktion durch den Linker auf eine ungerade Addresse plaziert wird. Das kann man sehr gut im lst file sehen. Im Original von WCH gibts an der Stelle natürlich auch keinen Kommentar(auch keinen chinesischen). Meine Frage ist jetzt eher: Wie kommt man auf die Idee sowas zu programmieren? Kann sich jemand einen Grund vorstellen warum das Komando an einer ungeraden Addresse stehen muss? Bei allem was ich über den Chip weiss, könnte ich mir eher vorstellen dass es eine gerade Addresse sein muss. Dann wäre die Logik aber genau falsch rum. Ich habe natürlich bei WCH auch angefragt aber keine sinnvolle Antwort erhalten. Meiner Meinung nach ist es kompletter Mist sowas zu programmieren. Ohne Blick ins Assembler File kann man nicht sagen wie das übersetzt wird und bei der kleinsten Anderung der Funktion muss man wieder neu nachschauen. Ich habe keine Option gefunden dem Linker mitzuteilen eine Funktion an eine gerade Addresse zu linken. Kann sich jemand einen Reim daruf machen? Thomas
An Aaron C., bin sptiz drauf die Teile auch mal zu testen. Jetzt meine Frage: musstest du um die dinger anzuholen zum Zoll? Hätte keine wirklcihe lust da meinen Tag zu verschwenden. Es dauert immer ewig und ist echt nervtötend. Man wartet ne halbe ewigkeit und dann nervt der Zoll wegen irgendetwas rum. Grüße Frank
Frank Gießner schrieb: > Jetzt meine Frage: musstest du um die dinger anzuholen zum Zoll? Moin, ich habe sie bei lcsc per express bestellt, vor nem jahr oder so gab es mal eine änderung bei DHL das die dass für dich verzollen, wenn rechnungsbetrag größer 22€. Dieser servie kostet 12€ + mwst. Mit LCSC hatte ich noch keinerlei problem mit zoll und vorgeladen werden. Wenn du nur ein paar bestellt bist du ja eh unter der zollgrenze und raus. Wenn du aber willst kann ich dir für einen obulus welche per brief senden, habe noch ca. 370 Stück der CH552G Bootloader Version 1.1 @Thomas, bist du eigentlich auch mal Thomas(Gast) gewesen? oder irre ich mich da? etwas verwirrent :D Es wurde die Tage das M5Stack II und der M5StickC mit CH552T als USB to Seriall converter ausgemacht. https://m5stack.com/products/stick-c auf beiden Läuft dieser code: https://github.com/diodep/ch55x_esp
Nö du irrst dich nicht, ich war lange Zeit auf mc net nur als Gast unterwegs. Es gibt zwar auch noch andere Thomas Gäste aber in diesem Thread ist das nur von mir. Seit etwa einem halben Jahr poste ich fast nur noch von meinem Tablet und deshalb auch angemeldet. Thomas
Ok danke, wollte nur komische Situationen vermeiden :D
Aaron C. schrieb: > Wenn du nur ein paar bestellt bist du ja eh unter der zollgrenze und > raus. > > Wenn du aber willst kann ich dir für einen obulus welche per brief > senden, habe noch ca. 370 Stück der CH552G Bootloader Version 1.1 Hallo, danke für die schnelle Antwort! Wollte aber noch etwas anderen krimms kramms von der Seite kaufen. Also besten dank für das Angebot! Ich denke ich versuchs einmal mit ner Bestellung dort. Hab die erfahrung gemacht das zumindest hier in Bayern alles was als Päckchen aus dem Ausland ankommt - das man dann zum Zoll muss. Musste schon mal wegen einem 5 Euro (5,99 Versand) Teil zum Zoll nur weil es als Paket verschickt wurde mit "echter" Seundungsnummer. Haßt du auch erfahrung mit anderen MCs von der Seite? Grüße Frank
Hab ich gerade gefunden. Da übersetzt wohl jemand das Datenblatt zum CH559. Die Qualität scheint gut zu sein, es sind aber erst die ersten 7 Kapitel online. https://github.com/kprasadvnsi/CH559_Doc_English Thomas
Hallo Thomas, cool, aber ich Frag mich sowieso wieso die Datenblätter nur auf Chinesisch und nicht auf Englisch erhältlich sind. So als ob die Chinesen die diesen Chip entwickelten kein Englisch können. Was ich ja überhaupst nicht glaube. Grüße Frank
Du bist halt nicht die Zielgruppe. Das sind asiatische Firmen, die so Sachen für 2$ entwickeln wollen.
Hier nun meine Interpretation der UDisk sourcen von WCH. Das ganze ist noch nicht perfekt und für Keil only. Im zip befinden sich insgesamt 3 Projekte: - disk_iap was die Integration der Lib zeigt und nach 0xE000 linkt. - disk_test was alle Module include und nach 0x0000 linkt - udisklib zum compilieren der Lib. Im udisk_test ist ein globales define TESTCODE gesetzt was an alle Module weiter geleitet wird. Damit wird printf gesteuert und in IAP das flashen gesperrt. disk_Iap benutzt modifizierten startupcode und der Linker platziert den Code ab 0xE000 Es sind noch etwa 400 Bytes unbelegt. Thomas
Angehängte Dateien:
-
ch559_brkout.png
140 KB
Mein Testboard ist angekommen und ich hab gleich mal bestückt. 0.5mm Pitch ist nichts mehr für meine Augen. Einen Fehler hab ich auch gleich gefunden: Entgegen dem Datenblatt ist Der RST Anschluss high (ohne Pulldown) zumindest solange keine FW auf dem Chip ist ist also P5.7 kein frei benutzbarer Portpin sondern mit RST belegt. Der fehlende Pulldown verhindert zuverlässig das Anlaufen des Bootloaders. Abhilfe 10k gegen Gnd. Leider hab ich auch S2 an dem Port Pin hängen den kann man also nicht benutzen. Wenn das Ding getestet ist werde ich Eagle Files einstellen Thomas
ich hab mich mal etwas mit der Seriennummer des CH559 beschäftigt. Der Zugriff auf diese Nummer ist etwas seltsam. Man muss E_DIS = 1 setzen und dann 8 bytes mit MOVC ab 0x020 lesen. Das ist zumindest der von WCH dokumentierte Weg. Tatsachlich ist aber so, dass die SN über den gesammten Flashrombreich gelesen werden kann. Sie wiederholt sich alle 256 Bytes. Es sind zusätzlich auch noch ein paar undokumentierte Bytes definiert.
1 | c:0000 FF FF FF FF 0A FA 93 FF FF FF FF FF FF FF FF FF |
2 | c:0010 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
3 | c:0020 05 5A A3 54 00 00 A8 AE FF FF FF FF FF FF FF FF |
4 | c:0030 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
5 | c:0040 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
6 | ... |
7 | c:0100 FF FF FF FF 0A FA 93 FF FF FF FF FF FF FF FF FF |
8 | c:0110 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
9 | c:0120 05 5A A3 54 00 00 A8 AE FF FF FF FF FF FF FF FF |
10 | c:0130 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
11 | c:0140 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
12 | ... |
13 | ... |
Man kann z.B auch sehen das zumindest bei mir nur 32Bit der SN definiert sind und nicht 48 Bit wie im Datenblatt beschrieben. Das ist vermutlich auch der Grund warum WCH schreibt man soll nur die ersten 32bit benutzen. Thomas
Mit Bitluni von Bitlunislab ist nun das folgende projekt rausgekommen. Mittels des CH559 ist ein uart interface entstanden an dem diverse andere controller angeschlossen werden können, im beuspiel ein esp32 und Arduino. Auch ist eine verarbeitung auf dem CH559 möglich dazu kann man den source code nach seinen bedürfnissen ändern. https://youtu.be/Th88RiSmj2w
Ich hab den Bootloader des CH559 jetzt an die anderen Loader angeglichen. Wieder lassen sich verschiedene Optionen ein und ausschalten. Der Code ist ausführlich kommentiert. Ohne Optionen entspricht der Code dem Original sofern die Startaddresse auf 0xF400 steht. Dieser Loader ist geeignet für CH558/CH559. Es gibt in main eine Abfrage auf ID 0x57 keine Ahnung was für ein CHip das ist. Ich hab bei WCH jedenfalls keinen CH557 gefunden. Das Header File ist gleich geblieben und weiter oben zu finden. Thomas
Ich find das ganz spannend was ihr hier macht. Bin nach dem heutigen Video von bitluni auf diesen Thread gestoßen. Ich hab ehrlich gesagt nur die Hälfte alle Beiträge gelesen da es inzwischen echt viele sind. Trotzdem würde ich gerne 3 Fragen stellen: 1. Welchen Vorteil hat euer eigene Bootloader? Benötigt er weniger Flash-Speicher? Funktioniert er ohne das WCHISP-Tool? 2. Kann man sich den USB-Bootloader sparen und so den freigewordenen Flash nutzen indem man die CH55x stattdessen mit einem "echten Programmiergerät" programmiert? Gibt es Informationen dazu, wie das funktioniert? Hat es schon jemand getestet? 3. Was ist der Unterschied zwischen XRAM und iRAM? Grüße
Ich antworte mal: Der Bootloader hat mmer noch die Original Funktionalität. Er wurde nur optimiert um Platz für zusätzliche (andere) Funktionen zu schaffen. Das WCHIsptool war schon immer nur eine von mehreren Möglichkeiten. So hat Aaron zB. einen Flasher für Android geschrieben. Da die API unverändert ist, kann man auch Erweiterungen realisieren. So habe ich zB ein Tool geschrieben was auch ab einer Startadresse<>0 flashen kann. Ja man könnte den Controller extern per SPI flashen. Das geht aber nur in der Theorie. WCH hat das SPI Verfahren nicht offengelegt. Praktisch existiert diese Möglichkeit also nicht. XMEM und IMEM sind Begriffe aus der x51 Welt. Etwas vereinfacht: IMEM ist der interne Controller Speicher (max 256 Bytes).XMEM ist externer Speicher. Beide Speicher existieren parallel, da sie unterschiedlich angesprochen werden. Thomas
Vielen Dank für deine Antwort Thomas! Thomas Z. schrieb: > XMEM und IMEM sind Begriffe aus der x51 Welt. Etwas vereinfacht: IMEM > ist der interne Controller Speicher (max 256 Bytes).XMEM ist externer > Speicher. Beide Speicher existieren parallel, da sie unterschiedlich > angesprochen werden. Macht das einen Unterschied für den C-Entwickler? Oder handelt das der Compiler und man hat dann insgesamt 1.25kByte?
Max M. schrieb: > Vielen Dank für deine Antwort Thomas! > > Thomas Z. schrieb: >> XMEM und IMEM sind Begriffe aus der x51 Welt. Etwas vereinfacht: IMEM >> ist der interne Controller Speicher (max 256 Bytes).XMEM ist externer >> Speicher. Beide Speicher existieren parallel, da sie unterschiedlich >> angesprochen werden. > > Macht das einen Unterschied für den C-Entwickler? Oder handelt das der > Compiler und man hat dann insgesamt 1.25kByte? Man muss schon beim Programmieren angeben welche Daten man in welchen RAM haben möchte. Man hat am Ende aber trotzdem 1,25kByte. Soweit ich das verstanden habe wird alles was nicht extra benannt wird in den internen RAM gespeichert und dort wo man __xdata mit angebt wird es im externen RAM gespeichert. So ist es zumindest bei SDCC
Max M. schrieb: > Macht das einen Unterschied für den C-Entwickler? Oder handelt das der > Compiler und man hat dann insgesamt 1.25kByte? Der C Compiler kennt erst mal nur den internen Speicher. Dieser ist noch weiter aufesplittet. Es gibt da noch mehr Segmente. In diesem Speicher liegt der Stack und die Variablen. Wenn man im Large Mode übersetzt platziert der Linker die Variablen im XMEM. Das ist aber wesentlich langsamer. Zusätzlich kann jeder Var per modifierer auch die Platzierung mitgegeben werden. Das funktioniert unabhängig vom Memory Model. Bedenke der core stammt aus den 80er Jahren. Damals hat man sich noch nicht so viele Gedanken um C gemacht. Wenn du also keine Erfahrung mit einem 8051 hast würde ich dir nicht empfehlen jetzt noch damit anzufangen. Die cores sind zwar immer noch weit verbreitet, heutzutage gibt es aber wesentlich bessere Designs. Eine der Stärken würde ich beim x51 im boolean Prozessor sehen. Es gibt Befehle um direkt mit bits zu arbeiten. Das bietet in dieser Form m. Wissens keine andere MCU. Thomas
Anbei die Eagle Files meines CH559 Breakout Boards. Das Design ist generell auf .2mm Abstand geroutet. Es gibt aber einige Engstellen wo der DRC nur mit .15mm durchläuft. USB Buchse und Taster gibt's bei Reichelt. Die Platine hab ich bei Aisler machen lassen. Das funktionierte in 2 Tagen völlig problemlos. Das nächste Mal würde ich allerdings ENIC wählen und lieber 7 Tage warten. Die gezeigte Version hat schon die korrigierte Resetbeschaltung beim Flashen muss man darauf achten, dass D+ als Bootpin eingestellt ist weil ich an P4.6 keinen Taster dran habe. Falls man das nicht umstellt muss man hinterher seriell flashen Thomas
Aaron C. schrieb: > Mit Bitluni von Bitlunislab ist nun das folgende projekt rausgekommen. > ... > Youtube-Video "Usb mouse and keyboard on Arduino, CH559 cheap usb host > chip" Danke für das Video. Woher und zu welchem Preis hast du die Controller im Tray bezogen? Ich kann nur einen einzigen Anbieter bei Ali finden, nirgendwo sonst.
Prima, vielen Dank!
Das Ganze erinnert mich übrigens an die Hacks der digitalen Bilderrahmen mit dem "AppoTech AX206" mit ähnlicher Ausstattung. http://openschemes.com/wp-content/uploads/2011/08/X206spec.pdf Es sind auch schon einige Threads hier im Forum. Vielleicht kann man auch was von den Codes in den diversen Repos wiederverwenden oder wenn es auch nur die Idee eines externen Displays für irgendeine headless black box ist.
Habe mich die tage nochmal hingesetzt und ein flashing script in Python für die CH55x Familie geschrieben. https://youtu.be/uhSHcyjUaic Dieses kann Bootlaoder version 1.11 und 2.31 Da beim entwickeln immer zwischen VirsualStudio und dem WCHISPTOOL gewechselt werden musste ist es mit dem tool nun eine ein click lösung, also compile.bat aus dem ch559 code ausführen der code wird compiliert und gleich auf den CH micros geflasht.
Sehr cool! Eine Frage von mir: Lustigerweise kostet der CH552 genauso viel wie der CH340G, der oft als USB/UART-Bridge verwendet wird. Kann man den CH552 so programmieren, dass er auch als USB/UART-Bridge fungiert und damit z.B. einen ESP8266 flashen? Dan hat man quasi immer einen kleinen uC mit an Board, USB<->UART braucht man beim ESP ja sowieso.
Max M. schrieb: > Kann man den CH552 so programmieren, dass er auch als USB/UART-Bridge > fungiert und damit z.B. einen ESP8266 flashen? Dan hat man quasi immer > einen kleinen uC mit an Board, USB<->UART braucht man beim ESP ja > sowieso. Moin, ja das funktioniert genau so. es wird auch schon bei dem M5Stack in massenproduktion eingesetzt. Eine opensource firmware gibt es hier: https://github.com/diodep/ch55x_esp
Vielen Dank für die schnelle Antwort! Sehr schön, dass es da schon was fertiges gibt. So ganz verständlich ist der Code allerdings meiner Meinung nach nicht (vor allem die Funktion "Device-Interrupt"). Ist auch mehr Code als ich ursprünglich dachte. Scheint also doch mehr Arbeit gewesen zu sein, das zu reverse engineeren.
Ja es ist wirklich schwer leserlich, der code ist aber auch sehr unordentlich und vom original WCH example nur verändert. Ich habe mich da langsam rangetastet und stückchenweise den code angepasst, also nicht diesesn speziellen code sonder grundsätzlich. Was ich gerade für die ESPs interessant finde ist die "integrierte" Reset und GPIO0(bootloader) funktion die ein paar teile einsparen kann wenn man das implementiert. Auch gibt es dieses projekt: https://hackaday.io/project/167339-a-new-nano Dort wurde eine ISP Programmer für AVR micros auf dem CH552 Gebastelt, inklusive USB zu Seriell Converter, der Code vom dem Projekt ist deutlich aufgeräumter da von null selber geschrieben.
Aaron C. schrieb: > Ich habe mich da langsam rangetastet und stückchenweise den code > angepasst, also nicht diesesn speziellen code sonder grundsätzlich. Ich denke, dass ist die beste Vorgehensweise. Bringt ja nix, wenn ich meine Features einbauen möchte, aber den restlichen Code nicht verstehe. Macht Sinn, den IC von Grund auf verstehen zu wollen. Aaron C. schrieb: > Was ich gerade für die ESPs interessant finde ist die "integrierte" > Reset und GPIO0(bootloader) funktion die ein paar teile einsparen kann > wenn man das implementiert. Das stimmt, soweit ich weiß wurde das auf den Wemos D1 Mini mit zwei Transistoren gelöst. Findet man via Google "Wemos Reset Circuit". Edit: Etwas Off-Topic, aber vielleicht interessant für die USB-Begeisterten: Von Nordic Semi gibt es einen IC, der einen 8051 uC (16MHz, 16kByte Flash 2kByte SRAM) mit einem USB-Device Controller und einem 2.4GHz RF Transceiver Modul (weder WLAN noch Bluetooth) vereint: https://www.rcscomponents.kiev.ua/datasheets/nrf24lu1-f16q32-t.pdf Programmiert werden kann der laut Datenblatt auch über einen vorprogrammierten USB-Bootloader (der ist futsch sobald das User-Program in den Bootloader-Adressbereich hineinwächst). Ansonsten wird ein PROGEN-Pin high gezogen und über ein Slave-SPI der interne Flash programmiert. Damit kann man z.B. sowas lustiges machen: https://www.bartslinger.com/electronics/nrf24lu1-usb-dongle/ Die Keil µVision IDE kennt den Chip bereits und bietet dafür eine Header-Datei an. Kostet auf Taobao 0.50€ / Stück. Gibts leider nur im QFN32-Package mit maximal 6 nutzbaren GPIOs.
Aaron C. (atc1441) hat mir ein paar CH55x zukommen lassen und ich habe mal einen Blick auf die Dies des CH551 und des CH552 geworfen: https://richis-lab.de/CH55x.htm Es scheint sich um die gleichen Dies zu handeln. Wahrscheinlich werden beim CH551 schlicht gewisse Funktionen deaktiviert. Mal sehen was in den anderen Varianten noch steckt. Grüße, Richard
Vielen vielen dank!!!
Danke! Richard K. schrieb: > Es scheint sich um die gleichen Dies zu handeln. Wahrscheinlich werden > beim CH551 schlicht gewisse Funktionen deaktiviert. Jetzt stellt sich die Frage: Sind diese Funktionen deaktiviert, und können theoretisch aktiviert werden, oder sind da Teile der Chips Produktionsbedingt bereits kaputt, und werden deaktiviert? Ich meine die Preise sind extrem tief, da könnte es doch auch sein, dass da die Fertigungsqualität schlechter ist. Da wird getestet, und wenn etwas nicht geht, wird alles deaktiviert, und als CH551 verkauft?
Andreas B. schrieb: > Danke! > > Richard K. schrieb: >> Es scheint sich um die gleichen Dies zu handeln. Wahrscheinlich werden >> beim CH551 schlicht gewisse Funktionen deaktiviert. > > Jetzt stellt sich die Frage: Sind diese Funktionen deaktiviert, und > können theoretisch aktiviert werden, oder sind da Teile der Chips > Produktionsbedingt bereits kaputt, und werden deaktiviert? > > Ich meine die Preise sind extrem tief, da könnte es doch auch sein, dass > da die Fertigungsqualität schlechter ist. Da wird getestet, und wenn > etwas nicht geht, wird alles deaktiviert, und als CH551 verkauft? Das ist die Frage... Ich vermute, dass die Prozesse mittlerweile so gut sind, dass bei so relativ kleinen Controllern der Ausschuss sehr gering ist und entsprechend schlicht verworfen wird. Hat man Ausschuss, so müsste man da ja erst mal testen was genau kaputt ist und ob sich das Die noch als CH551 eignet. Das wird sich nicht rentieren. Dann bleibt noch die Frage ob die Funktionen über HW oder SW deaktiviert wurden. Bei gröberen Strukturen hat man oftmals Fusible Links verwendet. Bei einem Mikrocontroller würde ich eher vermuten, dass es SW-Fuses, also Speicherzellen sind, die konfiguriert werden. Ob man an diese Speicherzellen noch einmal ran kommt und wie man da hin kommt müssen die SW-Cracks herausfinden... :) ...hilfreich wäre es wahrscheinlich die Metalllagen zu entfernen und das ganze Die zu analysieren. Das übersteigt aber meine Fähigkeiten...
Ich denke es währe vor allem die frage ob der CH554 auch das gleiche DIE hat, die funktionen von CH551 und CH552 unterscheiden sich ja nur minimal, beim CH554 kommt ja noch USB Host hinzu. Ich denke nur dann lohnt es sich dahinter zu schauen. P.s. Richard, du hast ein paar mal im text auf deiner website die Zahlen vertauscht wollte es nur einmal erwähnt haben
Der CH554 ist schon durch den Ofen gegangen. Fotos muss ich noch machen. :) Danke für den Hinweis zu den Schreibfehlern. Zweimal "511", richtig? Habe ich korrigiert.
Ich hab mal wieder etwas programmiert... rausgekommen ist ein kleines Konverter Tool um Intel Hex Dateien zu konvertieren. Das besondere ist, dass der Speicher mit Zufallsdaten initialisiert werden kann. Das Tool kennt alle WCH CPUs und erzeugt per Default ein Abbild des kompletten Userflashs. Das ist insbesondere dann hilfreich wenn ein modifizierter Bootloader mit abgeschaltetem Verify im Loaderbereich verwendet wird. Damit ist ein zurücklesen der Daten unmöglich Vorbereitet aber noch nicht implementiert ist das encrypting des Files(speziel für uDisk) sowie das automatische flashen. Die Größe der Ausgabedateien kann optional auch limitiert werden. Beispiel: wch_tools -iBlablub.hex -f+ -c0x52 -l0x2000 erzeugt firmware.hex und firmware.bin mit limitiert auf 8kB. Wenn euch noch was ein oder auffällt schreibt einfach. Thomas
Guten Morgen! Jetzt habe ich auch den CH554 und den CH559 online: https://www.richis-lab.de/CH55x.htm Der CH554 mit seiner USB-Host-Funktionalität nutzt tatsächlich das gleiche Die wie der CH551 und der CH552. Das bedeutet, dass höchstwahrscheinlich auch die USB-Host-Funktion bei allen Varianten grundsätzlich vorhanden ist. Der CH559 ist gänzlich anders aufgebaut. Grüße, Richard
Richard K. schrieb: > Jetzt habe ich auch den CH554 und den CH559 online: Die Bilder sind echt cool danke dafür. Bezüglich der Konfiguration: Es gibt ein Byte im Config Bereich was nicht dokumentiert ist, es ist das Byte an der Addresse 0x3FFA. Das ist bei mir (CH552) immer 0x65 und gehört nicht zur Seriennummer. Lt Doku kann der Bereich nur per SPI programmer beschrieben werden was ich persönlich nicht glaube. Es wäre interessant was dort bei einem CH551 oder beim CH554 steht. Thomas
Thomas Z. schrieb: > Richard K. schrieb: >> Jetzt habe ich auch den CH554 und den CH559 online: > > Die Bilder sind echt cool danke dafür. Gerne! Wenn ihr noch was in die Richtung braucht, dann sagt Bescheid! Von den Software-Themen halte ich lieber Abstand... :)
@Richi Vielen dank nochmals, finde deinen röhren ofen übrigends sehr interessant.
Aaron C. schrieb: > @Richi > > Vielen dank nochmals, finde deinen röhren ofen übrigends sehr > interessant. Der Ofen ist sehr hilfreich. Zwar sind die Dies überraschend robust gegenüber Hitze, aber mit einem Gasbrenner kann man sie dann doch beschädigen. Gleichzeitig brauchen aber vor allem große Packages eine ordentliche Wärmemenge und alle gängigen Produkte wie zum Beispiel Pizza- oder Reflowöfen sind zu kalt. Ein richtiger Muffelofen war mir zu teuer. So kam ich auf den Eigenbau. Damit ist der Vorgang jetzt auch einigermaßen reproduzierbar. 400°C (am Sensor), 1min und die kleinen SMD-Packages sind durch. :) Und bei problematischen Fällen (anhaftende Reste) einfach das Die noch einmal ein bisschen braten, evtl. 50°C mehr und es gibt meist immernoch keine Schäden. (Ausnahmen bestätigen die Regel...)
Ein kleines Update: zusätzlich zu einigen Bugfixes ist jetzt die Verschlüsselung mit TEA oder XTEA möglich. Beide Funktionen sind einfach genug um auch auf einem x51 annehmbare Resultate zu liefern. Bei der Verschlüsselung hat man die Wahl zwischen strong und fast. Strong braucht aber auch die 8 fache Zeit was auf einem x51 schon eine Rolle spielt. Man kann aber auch gut erkennen, dass die fast Option viel schlechter verschlüsselt, speziell wenn viele gleiche Bytes kommen. Außerdem können nun bis zu 4 Intel Hex Files, durch Komma getrennt, geladen werden (merge) und die Extension kann auch weggelassen werden. Im Archiv ist jetzt auch der Sourcecode enthalten. Thomas
Ich habe gestern mal Versuche zur Entschlüsselung gemacht. Mit XTEA strong komme ich auf ca 500 ms pro 512 Byte Block. Den Core Clock schalte ich zum dekotieren auf 48 MHz. Das ist ok für mich. Zusätzlich habe ich in UDisk-Mini eine Erkennung eingebaut ob die Firmware verschlüsselt ist. Mein Ziel UDisk im Bereich 0xE000-0xEFFF unterzubringen werde ich vermutlich nicht erreichen. Ob ich den EEProm Bereich als Code benutzen kann muss ich noch testen, das Datenblatt ist nicht ganz eindeutig. Falls das funktioniert kann die zu flashende Firmware auf dem Stick max 56kB sein. Den Stick habe ich einfach mit einem simplen OTG Adapter angeschlossen. Thomas
@Thomas Das klingt ja ziemlich vielversprechend auch von der Geschwindigkeit her geht das ja, bin gespannt.
naja noch ist das alles im Test. Ich arbeite im Moment mit einer debug Version die alles mögliche auf einem kleinen TFT mit einem umgeleiteten printf ausgibt. Später werde ich wieder auf die serial Debug Ausgabe umschalten. Der oben gezeigte UDisk Code hatte auch noch ein paar kleine Bugs. Außerdem bin ich wieder über einige seltsame Konstrukte im WCH Code gestolpert die ich mir nicht erklären kann. Hab's halt einfach mal übernommen. Die entgültige Version wird dann allerdings keine Ausgaben enthalten sondern sollte einfach funktionieren. Noch bin ich mir auch nicht sicher ob mein ENum Code nicht zu strikt ist, da muss ich mal mit modernen Sticks das Verhalten prüfen. Meine alten Gurken gehen alle. Hast du schon mal einen der CH54x in den Fingern gehabt? Thomas
Mit den CH54X hatte ich noch nichts zutun und auch nicht wirklich angeschaut, sieht aber ja sehr ähnlich aus von den Features. Das wirklich spannende für mich war ja der Preis de CH551 und CH552 dann kahmen die USB und Host funktionen des CH559 dazu.
Auch wenns es noch alles andere als fertig und perfekt ist möchte ich dennoch meinen heutigen erfolg kurz vorstellen. https://youtu.be/EMDJe7JQ76g Ich konnte erfolgreich den SDCC in der Arduino ide zum laufen bringen und das python flasher tool mit als programmer nutzen um nun aus der Arduino ide herraus zu programmieren und es auch neuligen deutlich einfacher zu gestallten. Vielen dank hierbei and Sduino( Beitrag "SDuino: Beinahe-Arduino für STM8S" ) ohne das währe es nicht so einfach geworden.
coole Sache den c51 mit dem Arduino zu verheiraten, ich verstehe allerdings nicht so recht, wie du das c++ da reinfrickelst. Mein UDisk nimmt so langsam Formen an. Nach einigen Aufräumarbeiten bekomme ich das nun in 4kb unter. Von der strong crypt Funktion hab ich mich allerdings verabschiedet. Da ich den Code diesesmal auch zu SDCC kompatibel machen will überlege ich mir auch die MSB Option zu streichen. Ich denke bis Ende der Woche steht das. Der UDisk Code kommt mit allen mir zur Verfügung stehenden Sticks klar. Thomas
Ein kleines update... Ich habe UDisk jetzt soweit fertig und auch für SDCC umgebaut. Wie erwartet ist der Code mit SDCC größer passt also nicht mehr nach 0xE000, statt 4kb sind es etwas mehr als 5kb. Ob der SDCC Code auch funktioniert muss ich noch testen. Wie schon angekündigt ist sowohl die fast Option als auch die MSB Option beim Konverter weggefallen. Die notwendigen Konvertierungen macht UDisk direkt. Die korrigierte Version werde ich morgen zusammen mit dem Projekt zeigen. Thomas
Hier nun UDisk. Es hat etwas gedauert bis mein Code auch für SDCC fehlerfrei compiliert. Im Doc Ordner gibt's ein ausführliches readme. Der debug target flashed einen Hexdumper ab 0x8000 welcher einfach per movc den Codespeicher auf TxT0 schickt. Interessant dabei ist das movc im Bootloader Bereich nur 0xFF liefert. Das unterscheidet den CH559 wesentlich vom CH552. Zum ausprobieren reicht es eines der test_udisk.hex Files auf den Controller zu flashen und FIRMWARE.BIN aus dem dumper Ordner auf den Stick zu ziehen. Dann einfach die der. Schnittstelle mit 57k6 8N1 beobachten. Der Keil Release target braucht 4032 Byte, mit LX51 und LinkerCode Packing lässt sich das auf 3800 Bytes drücken. SDCC braucht deutlich mehr, da hab ich mich aber nicht so intensiv mit dem Optimizer beschäftigt. Im Tools Ordner befindet sich der modifizierte Konverter. Achtung das Format der Kommandozeile ist etwas anders und es gibt eine neue Option für den Key. Thomas
Habe deinen code einmal überflogen, das ist ja ein ganz schöner aufwand der dort drinsteckt! Zu der CH55x Arduino C++ geschichte, es werden vor dem compilieren einfach alle cpp dateien in c umbenannt und als nur c kompiliert.
Der wirkliche Aufwand steckt darin, den Code sowohl für Keil als auch SDCC übersetzbar zu machen. Die Compiler unterscheiden sich doch etwas, viele meiner Makros die ich seit Urzeiten bei Keil verwende, musste ich erst mal anpassen. Der Hintergrund ist dass der Preprozessor im SDCC im Gegensatz zu Keil strikt std konform ist. Einige Makros hab ich immer noch nicht korrekt hinbekommen. Leider machen die ganzen Fallunterscheidungen den Code nicht übersichtlicher. Du kannst das ganze ja mal mit der ersten Version vergleichen die weiter oben gezeigte ist. Alles in allem war es mir das aber wert um etwas tiefer beim SDCC einzusteigen. SDCC ist wesentlich strikter was Warnungen angeht. Wenn jetzt noch die Code Größe vergleichbar wäre, gäbe es für Keil eigendlich keinen Grund mehr. Thomas
Ich habe gerade gemerkt dass im Keil Projekt noch meine TFT lib drin ist. uVision wird sich also beim Start über die fehlende Lib beschweren. Die kann gefahrlos entfernt werden da nicht mehr referenziert. Das ist noch ein Rest als ich printf auf ein TFT umgelenkt hatte. Thomas
Gut gemacht! Vielen Dank
Ich hatte eigentlich vor den UDisk Code auch für den Wickenhäuser Compiler und den MicroE Compiler vorzubereiten. Das wird leider nichts. Der Wickenhäuser beherrscht kein #elif und ich will da nichts mehr umstellen. Beim MicroE ist es so das MCUs nicht so ohne weiteres dazugebaut werden können. Es werden nur MCUs unterstützt die in der Liste auftauchen. Ich hätte mich also drum rum frickeln müssen, was wegen der mangelhaften Doc ziemlich aufwändig wäre. Eigentlich unbrauchbar in meinen Augen und keines wegs das Geld wert was Sie verlangen. Zusätzlich hat sich wohl seit 2013 nichts mehr getan.
Aaron C. schrieb: > Zu der CH55x Arduino C++ geschichte, es werden vor dem compilieren > einfach alle cpp dateien in c umbenannt und als nur c kompiliert. Es gibt noch eine Arduino Implementierung https://embdev.net/topic/498403#new
Angehängte Dateien:
-
YoutubeKommentar.jpg
91 KB
Danke für den Hinweis, Deqing hatte bereits Kontakt mit mir über YouTube Kommentare... Bin etwas verwirrt das die Kommentare gelöscht sind deshalb diese einmal als Anhang hier. Nicht cool soweit, weiß aber auch nicht ob ich da was falsch verstehe, hatte ihm darum gebeten wenn er was aus meinem Code nutzt dieses in der BoardManager.json Datei mit meinem Namen zu erwähnen, was mehr als fair ist.
Ich würde dem nicht so viel Bedeutung beimessen. YouTube ist in China nicht so ohne weiteres verfügbar wie ich aus eigener Erfahrung weiss. Das geht nur über Anonymisierungsdienste. Vielleicht hat dir die große Firewall einen Streich gespielt.
Scheinbar ist es tatsächlich geblockt, komisches YouTube.
Eine Frage: Kann man mit einem WCH-Controller der nur als Device fungieren kann (z.B. CH552) beim Einstecken einen USB-Stick "vorgaukeln" und sobald ein Benutzer eine Datei dahinkopiert, diese über den CH552 auf einen externen SPI-Flash schreiben? Kann man als CH552 die Geschwindigkeit auch limitieren in der Windows / Linux die Datei überträgt? Ich vermute, die SPI-Schnittstelle läuft nicht schneller als vllt. halber CPU Takt? Das reicht nicht um mit USB 2.0 mithalten zu können und der interne RAM wäre dafür zu klein.
Max M. schrieb: > Eine Frage: > > Kann man mit einem WCH-Controller der nur als Device fungieren kann > (z.B. CH552) beim Einstecken einen USB-Stick "vorgaukeln" und sobald ein > Benutzer eine Datei dahinkopiert, diese über den CH552 auf einen > externen SPI-Flash schreiben? Moin, ja das geht und gibt es auch schon als fertiges beispiel. habe es auch einmal ausgetestet mit einem spi flash und es funktionierte wie du beschreibst. versuche das zu finden
Max M. schrieb: > Kann man mit einem WCH-Controller der nur als Device fungieren kann > (z.B. CH552) beim Einstecken einen USB-Stick "vorgaukeln" und sobald ein > Benutzer eine Datei dahinkopiert, diese über den CH552 auf einen > externen SPI-Flash schreiben? Nein das geht nicht es sei denn du findest eine Möglichkeit irgendwie den Hostmode zu aktivieren indem du aus dem CH552 einen CH554 machst. Wie Richie ja gezeigt hat benutzen beide das gleiche Die. Ansonsten brauchst du zwingend einen CH554. Dann ist es kein Problem. Irgendwann werde ich meinen UDisk Code auf den CH554 portieren. Max M. schrieb: > Kann man als CH552 die Geschwindigkeit auch limitieren in der Windows / > Linux die Datei überträgt? Ich vermute, die SPI-Schnittstelle läuft > nicht schneller als vllt. halber CPU Takt? Das reicht nicht um mit USB > 2.0 mithalten zu können und der interne RAM wäre dafür zu klein. versteh ich nicht. Wenn der CH55x MSD Host spielt hast du doch gar keine Verbindung zu Windows. Der Host bestimmt die Geschwindigkeit. Thomas
@Thomas Z. ich denke er meint den CH552 als slave zu einem PC als USB Stick
Danke euch! Aaron C. schrieb: > ich denke er meint den CH552 als slave zu einem PC als USB > Stick Ja genau, so meinte ich das. Sorry, war anscheinend etwas unverständlich ausgedrückt.
Ja das hab ich wohl falsch verstanden. Ein MSD Device geht problemlos. Dazu muss auf dem SPI Flash ein MBR drauf sein und eine Partition. Dann kann man darauf schreiben und der Speicher sollte auch als Memory Stick erkannt werden. Es braucht dann zumindest ein rudimentäres Filesystem mit Support für del, write und dir Support.
Angehängte Dateien:
-
2018-12-21_104519.png
7,8 KB -
2018-12-27_213758.png
9,1 KB
Anbei das Beispiel. Schaltplan ist quasi mit dabei.
Empfehlenswert ist ev ein Fat16 system ev sogar FAT12. Die Frage ist für was? Der CH552 hat nur 14k Code Speicher. Mehr als ein digitaler Bilderrahmen der Bilder aus dem SPI Flash auf ein Display bringt wird wohl nicht drin sein. Der offline programmer von WCH benutzt glaube ich sowas um das zu flashende File in einem SPI Flash bereitzustellen.
Thomas Z. schrieb: > Mehr als ein digitaler > Bilderrahmen der Bilder aus dem SPI Flash auf ein Display bringt wird > wohl nicht drin sein. Muss ja auch nicht. Ich habe vor ein Programmiergerät für einen anderen Microcontroller zu bauen. Man kann dann einfach die kompilierte .hex-Datei von Windows / Linux aus in den "USB-Stick" kopieren. Der CH551 streamt das dann in den SPI-Flash und programmiert hinterher den anderen Microcontroller. Das ermöglicht sogar eine Standalone-Funktionalität da der SPI-Flash natürlich nicht flüchtig ist. Soweit der Plan.
OK dafür reicht auch schon ein CH551. Ich hab für den umgekehrten Fall CH559 als Host für einen Memory Stick im besten Fall 4kB gebraucht. (UDisk) Dein MSD Code sollte dicke in 8KByte passen dann hast du immer noch 4kB für den Programmer. Zu deiner Eingangsfrage wegen der Geschwindigkeit: Das ist kein Problem du bekommst von Win via BulkOnly Protokoll immer einen 512B Sektor. Da der Chip nur USB1.1 kann sind das dann 8 Bulk Transfers a 64 Bytes die du auf das SPI Flash schiebst. Wenn die Daten gespeichert sind, nimmst du einfach den NAK weg und der nächste Bulktransfer wird von Win initiiert. Wenn du den CPU Takt auf 24 MHz stellst kannst du einen SPI Takt bis 12 MHz verwenden. Es ist vermutlich sinnvoll das SPI Flash mit dem Image z.B einer leeren Diskette einmalig zu initialisieren. Nicht vorhandene Sektoren werden in der FAT einfach als defekt markiert Nachteil ist dann dass du dich mit FAT12 beschäftigen musst, aber da gibt's ja genügend Beispiele. Der FAT Code ist halt etwas hässlicher. LFN brauchst du vermutlich nicht 8.3 Filenamen werden reichen.
Die Suppe versalzen kann dir natürlich die Blockgröße des SPI Flashs. Je die Blockgröße ist desto komplizierter wird es. Ein rudimentären Flashfile System wirst du brauchen. Ich hab das vor Jahren mal mit einem 29F40 gemacht der eine 360k Diskette emulierte.
Ich habe mich mit der Portierung meines UDisk Codes nach IAR beschäftigt. Das funktioniert soweit ich kann's bloss nicht abschließend testen da ich nur die Demo habe. Die einzelnen Dateien kann ich aber kompilieren. Dann hab ich mir nochmal den MicroC Pro Compiler angeschaut. Das Ding ist der Hammer die übersetzen doch tatsächlich unsigned short in einen 8Bit Typ also gleich wie unsigned char. So einen Mist hab ich noch nie gesehen. Ich hab das dann mal auch für deren AVR Compiler nachgeschaut dort ist es genauso.
Beitrag #6327110 wurde von einem Moderator gelöscht.
Habe nun auch etwas beizutragen. Habe gestern eine Arduino USB HID interface Library fertiggestellt. https://github.com/atc1441/CH_HID_Arduino Damit ist es möglich den CH554, CH552 oder CH551 als USB Maus und Tastatur zu verwenden und über einen beliebigen Arduino / Seriellen Micro zu steuern. Der CH55x code ist komplett in der Arduino IDE entwickelt und liegt bei / wird darüber geflasht.
Aaron C. schrieb: > Der CH55x code ist komplett in der Arduino IDE entwickelt und liegt bei > / wird darüber geflasht. feine Sache das Ganze. Mich stört etwas die libusb Geschichte. Damit verliert man die Möglichkeit das WCH isptool zu benutzen. Wenn ich dich richtig verstanden habe wird das ja nur für den Bootloader benutzt. Wäre da nicht sinnvoller die WCH dll zu benutzen und einen Wrapper für die Loader Funktionen zu schreiben? Die DLL Export Funktionen sind ja mittlerweile bei WCH öffentlich verfügbar.
Das stört mich selber leider auch etwas und ist wirklich nur für den Bootloader, habe viele andere variationen über direkten windows USB zugriff usw. Leider ginz nichts ohne extra treiber. Es ging dabei darum es komplett ohne closed source auszukommen. Auch wenn es etwas aufwand ist kann man den treiber wieder deinstallieren und WCHispTool nutzen.
Das stimmt schon insbesondere wenn das Teil auch mal unter Linux verfügbar sein wird. USB bedeutet dass immer ein Treiber im System sein muss. Dieser kommt ja automatisch mit wenn man das WCHIsptool installiert wird und wird mit der DLL in den Usermode gewrappt. Ist natürlich kein Open Source da WCH keine Lizenzen in den Sourcen hat. Erinnert mich an meine Experimente mit den Loadern. Ich hatte ja anfangs auch mit custom Loadern und libusb gearbeitet damit die WCH vid/pid unangetastet bleibt. Man verliert halt dabei nochmal 2kb Flash Speicher
Wie ihr vermutlich gesehen habt, habe ich mich mit der Portierung von udisc nach IAR beschäftigt. Das passt soweit und ich konnte diese Woche den code mit einem lizensierten Compiler testweise übersetzen. Mehr dazu wenn ich die binaries auch getestet habe. Mir ist durch die Portierungen die Idee gekommen die CPU Headerfiles zu vereinheitlichen, so dass der Compiler keine Rolle mehr spielt. Ein unvollständiger und ungetestetes Beispiel im Anhang. Was denkt ihr? Sinnvoll oder eher weniger sinnvoll? Dieses File würde ich dann für alle MCUs anlegen. Noch habe ich keine sinnvolle Idee wie man IAR da unterbringen kann. Die Header würden dann einfach ein compiler.h includieren welches die Compiler spez. marcos baut. Thomas
Ich hab jetzt den IAR Support für UDisk fertig gestellt. Das Header File ist jetzt wie oben angedeutet umgestellt. Am Source waren nur minimale Änderungen notwendig. In der Hauptsache war das idata Variablen in Funktionen (Auto Variablen) IAR kann das nicht. Da es dann zu Speichermangel auch bei SDCC kommt muss der Debug Target dort dann mit --stack-auto übersetzt werden. Des weiteren ist in Main eine Dummy Initialisierung der xdata Puffer notwendig. Ohne diese wurden die Puffer immer rausgenommen und der linker hat sie nicht mehr gefunden. Keil und IAR sind im wesentlichen gleichwertig was die Code Größe angeht. IAR in diesem Fall etwas schlechter, was vermutlich auf das Lowlevel ASM Modul in Keil zurückzuführen ist. Die Projekt Dateien sind extra gezipt um das Wurzelverzeichnis übersichtlich zu halten. Die anderen in compiler.h aufgeführten Übersetzer sind nicht geprüft.
Aaron C. schrieb: > Habe nun auch etwas beizutragen. > > Habe gestern eine Arduino USB HID interface Library fertiggestellt. > > https://github.com/atc1441/CH_HID_Arduino > > Damit ist es möglich den CH554, CH552 oder CH551 als USB Maus und > Tastatur zu verwenden und über einen beliebigen Arduino / Seriellen > Micro zu steuern. > > Der CH55x code ist komplett in der Arduino IDE entwickelt und liegt bei > / wird darüber geflasht. Das sieht ja schon einmal genial aus! Jetzt bin ich auch mal am überlegen, ob ich mir ne kleine Platine bastel um als HID-Device den PC zu steuern. Nur bräuchte ich evtl kurz deine Hilfe. Wie werden denn in diesem Fall die HID-Befehle zusammen gestellt? In deiner CH_HID_Arduino.h hast du z.B. KEY_ESC als 0xB1 definiert. Ich würde mir das Ganze noch einmal ein bisschen erweitern, damit ich Volume Up und Volume Down damit versenden könnte. Hier habe ich jetzt eine Tabelle gefunden mit den Scanncodes, jedoch stimmen diese nicht wirklich mit deinen überein. Könntest du mir helfen, wo ich die richtigen Codes dafür finde, damit ich mir das Ganze ein bisschen erweitern könnte? :) Grüße
Moin, die definition der Keys setzt sich aus dem HID Keyboard descriptor zusammen, dieser ist im falle vom dem CH552 hier: https://github.com/atc1441/CH_HID_Arduino/blob/master/examples/CH552_Interface/usb.c#L39 Man kann den descriptor hier parsen um ihn zu lesen: https://eleccelerator.com/usbdescreqparser/ Dort wirst du sehen dass keine medien keys definiert sind. Um medien key zu unterstützen benötigt man einen anderen descriptor, auch must du den USB CFG descriptor dementsprechend anpassen. siehe hier: https://www.stefanjones.ca/blog/arduino-leonardo-remote-multimedia-keys/ Die Arduino seite von dieser library ist stark and die Leonardo library angelehnt deswegen wirst du viel wiederfinden.
Hi, ich habe gerade einen CH552 mit dem Blink Beispiel zum laufen gebracht. Vielen Dank für die Arduino Integration! Leider klappt das HID Beispiel aus der Library nicht, vielleicht hat jemand einen Tipp für mich?
1 | C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/bin/sdcc -c -V -mmcs51 --model-large --xram-size 0x0400 --xram-loc 0x0100 --code-size 0x3800 -DMCUch552 -DFREQ_SYS=24000000L -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\cores\ch55x -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\variants\standard -IC:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/include C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\CH_HID_Arduino.cpp -o C:\Users\Benutzer\AppData\Local\Temp\arduino_build_824754\preproc\ctags_target_for_gcc_minus_e.cpp |
2 | cpp gefunden |
3 | C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/bin/sdcc -c -V -mmcs51 --model-large --xram-size 0x0400 --xram-loc 0x0100 --code-size 0x3800 -DMCUch552 -DFREQ_SYS=24000000L -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\cores\ch55x -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\variants\standard -IC:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src -IC:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/include C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\CH_HID_Arduino.c |
4 | + C:\Users\Benutzer\DOWNLO~1\ARDUIN~3.5_S\portable\packages\CH55XD~1\hardware\ch55x/0170E4~1.0/sdcc/bin\sdcpp.exe -nostdinc -Wall -std=c11 -D"MCUch552" -D"FREQ_SYS=24000000L" -I"C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\cores\ch55x" -I"C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x\0.1.0\variants\standard" -I"C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src" -I"C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/include" -obj-ext=.rel -D__SDCC_CHAR_UNSIGNED -D__SDCC_MODEL_LARGE -D__SDCC_FLOAT_REENT -D__SDCC=4_0_2 -D__SDCC_VERSION_MAJOR=4 -D__SDCC_VERSION_MINOR=0 -D__SDCC_VERSION_PATCH=2 -DSDCC=402 -D__SDCC_REVISION=11616 -D__SDCC_mcs51 -D__STDC_NO_COMPLEX__=1 -D__STDC_NO_THREADS__=1 -D__STDC_NO_ATOMICS__=1 -D__STDC_NO_VLA__=1 -D__STDC_ISO_10646__=201409L -D__STDC_UTF_16__=1 -D__STDC_UTF_32__=1 -isystem "C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/bin\..\include\mcs51" -isystem "C:\Users\Benutzer\Downloads\arduino-1.8.5\portable\packages\CH55xDuino\hardware\ch55x/0.1.0/sdcc/bin\..\include" "C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\CH_HID_Arduino.c" |
5 | |
6 | sdcpp.exe: fatal error: when writing output to : Invalid argument |
7 | |
8 | C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\/CH_HID_Arduino.h:32: error 1: Syntax error, declaration ignored at 'class' |
9 | |
10 | C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\/CH_HID_Arduino.h:32: syntax error: token -> 'CH_HID_' ; column 13 |
11 | |
12 | C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\/CH_HID_Arduino.h:36: error 1: Syntax error, declaration ignored at 'Stream' |
13 | |
14 | C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\/CH_HID_Arduino.h:37: error 1: Syntax error, declaration ignored at 'public' |
15 | |
16 | C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino\src\/CH_HID_Arduino.h:43: syntax error: token -> '}' ; column 1 |
17 | |
18 | cp:: No such file or directory |
19 | Bibliothek CH_HID_Arduino in Version 1.0.0 im Ordner: C:\Users\Benutzer\Downloads\arduino-1.8.5\libraries\CH_HID_Arduino wird verwendet |
20 | exit status 1 |
21 | Fehler beim Kompilieren für das Board CH552. |
Moin, das Example selber ist für den echten Arduino angedacht, der code für den CH552 ist das Interface beispiel. hoffe das ist verständlich
Danke für die Info, das konnte ich flashen :). Was genau macht sendAckMSG? Einen Buchstaben per HID Keyboard senden? Aktuell passiert nichts wenn ich auf die Touch Tasten drücke. Danke
sendAckMSG sendet eine nachricht per Uart an den angeschlossenen Arduino
ok, besteht dann auch die Möglichkeit als Tastatur zu agieren oder ist das aktuell nicht möglich ?
Dafür wird in dem code der Arduino genutzt. Der CH552 ist als Maus und Keyboard interface gedacht.
Also der Arduino sendet per UART die Buchstaben, die der CH552 dann per USB "Tippen" soll?
Habe mal etwas mit dem Code gespielt, sollte das so funktionieren? Wenn ich auf eine der Touch Tasten drücke soll "test" getippt werden.
1 | #include "intTemp.h" |
2 | #include "time.h" |
3 | #include "usb.h" |
4 | #include "touchinput.h" |
5 | #include "uart.h" |
6 | #include "bootloader.h" |
7 | |
8 | uint32_t last; |
9 | uint8_t HIDKey1[4]; |
10 | #define LED_PIN1 7 // Pin7
|
11 | SBIT(LED1, 0x90, LED_PIN1); // Port1 |
12 | |
13 | void setup() |
14 | {
|
15 | init_freq(); |
16 | init_usb(); |
17 | init_touch(); |
18 | init_millis(); |
19 | init_uart(); |
20 | EA = 1;// Enable Interrupts |
21 | delay(250); |
22 | sendAckMSG('B'); |
23 | }
|
24 | |
25 | void loop() { |
26 | if ((millis() - last) > 40) { |
27 | last = millis(); |
28 | LED1 = !LED1; |
29 | }
|
30 | if ( Touch_IN != 0 ) |
31 | {
|
32 | if ( Touch_IN & CH2 )jump_to_bootloader(); |
33 | if ( Touch_IN & CH3 )sendAckMSG('t'); |
34 | Touch_IN = 0; |
35 | HIDKey1[0] = 't'; |
36 | HIDKey1[1] = 'e'; |
37 | HIDKey1[2] = 's'; |
38 | HIDKey1[3] = 't'; |
39 | send_Keyboard_data_to_usb(); |
40 | }
|
41 | |
42 | processUSB(); |
43 | processUart(); |
44 | }
|
Angehängte Dateien:
I have had success with ch55x
Foer those of you that like to play with Chinese 8051, A more complete kid available take a look http://www.sinowealth.com:8088/ftp//8051%20mcu/8bit%20flash%20mcu/ss450b_sh88f6161_6162/SH88F6161_6162%20V2.2.pdf
Ich habe mich nochmal näher mit dem Config Bereich des CH552 beschäftigt. Ich hatte da ja letztes Jahr schon ein paar Experimente gemacht. Im Anhang ein Programm um die Bits zu kontrollieren. Dabei ist das Bit zum sperren des Bootloaders aus Sicherheitsgründen gesperrt. Das Programm setzt momentan v1.1 Loader vorraus. Ich habe einen Controller geopfert um das Verhalten der Bits zu testen. Wie erwartet ist nach dem Löschen des Bits 14 kein Bootloader Start mehr möglich ein manueller Aufruf funktioniert immer noch. Man kann danach auch nicht mehr die Bits ändern weil im GLOBAL_CFG das Bit gelöscht ist. Lt Datenblatt ist das Bit bBOOT_LOAD readonly tatsächlich kann ich das Bit aber wieder setzen zumindest funktioniert das bei deaktivierten Bootloader. Das Verhalten ist ein Weg wie man einen v2.31 Loader tauschen kann. Thomas
Angehängte Dateien:
-
IMG_20200829_114619_761.jpg
200 KB
Schön zu sehen das noch bewegung drin ist :) Es gibt einen neuen Bootloader V2.40 Geflasht wird dieser gleich der V2.31 werde ihn bei gelegenheit auslesen, habe davon auch ein paar hier. Leider werden auf Aliexpress CH552G varianten ohne vorgeflashten bootloader verkauft. Ich wurde angeschrieben weil der Chip nicht erkannt wurde an usb und ich habe davon nun auch einen vorliegen. Ich denke wenn man die ISP Programmierung reversed dann sollte man jeden beliebigen Bootloader flashen können und das würde ich soweit als ziel ansetzen.
Aaron C. schrieb: > Ich denke wenn man die ISP Programmierung reversed dann sollte man jeden > beliebigen Bootloader flashen können und das würde ich soweit als ziel > ansetzen. Ja mit meinem Tool kann man ja Bit 15 manipulieren. Das wäre der erste Schritt um ISP freizuschalten. Leider wird das Bit vom WCH Tool bei jedem Flashen gelöscht. WCH weigert sich ja konsequent zu ISP irgendwas zu veröffentlichen. Ich kann mir übrigens nicht vorstellen dass die Teile ohne Loader geliefert werden, vielmehr glaube ich dass der Loader einfach deaktiviert ist, was im Ergebnis aber das gleiche ist wenn man kein Programm auf dem Controller hat um den Bootloader manuell zu starten. Zu v2.4 das ist vermutlich die Antwort auf eine Email von mir. Ich hatte WCH letztes Jahr auf die Sicherheitslücken im Loader aufmerksam gemacht. Wenn die das richtig gemacht haben funktioniert das bisherige Verfahren wahrscheinlich nicht mehr. Mir stellt sich nun die Frage ob es noch mehr readonly Bits gibt die sich unter bestimmten Umständen doch beschreiben lassen. Ich denke da speziell daran aus einem ch552 einen ch554 zu machen das Die ist ja immer gleich. Thomas
Ich hab jetzt noch ein paar Tests gemacht... Bit bBOOT_LOAD ist tatsächlich readonly solange der Bootloader nicht deaktiviert ist.
Habe nun auch einmal versucht den 2.40 zu dumpen und es hat nicht funktioniert, schade! das machte produkte mit dem CH eigentlich sehr interessant Mit dem normalen dump tool/V2.30 Bootloader emulator sollte es ja weiterhin kein problem sein den bootloader selber zu dumpen dann kann man einmal vergleichen was genau geändert wurde
Aaron C. schrieb: > Habe nun auch einmal versucht den 2.40 zu dumpen und es hat nicht > funktioniert, schade! Das hatte ich so auch erwartet. Die haben dazugelernt. Wenn du meinen Fake Loader nach 0x3000 installierst und den startest sollte alles wie gehabt funktionieren. Alternativ halt ein Programm schreiben was den Loader über die ser. Schnittstelle ausgibt.
Anbei einmal den gedumpten V2.40 Bootloader
Zeit für eine kleine IDA Session. Der Dump ist gut die Versions Info hab ich schon. Das Ding ist bis auf wenige Ausnahmen identisch zum 2.31 nur etwas länger.
Aaron C. schrieb: > Leider werden auf Aliexpress CH552G varianten ohne vorgeflashten > bootloader verkauft. mir ist gerade noch was eingefallen. Beim V2.31 und wie ich gerade gesehen habe beim V2.40 Loader kann die HW Aktivierung anstelle mit D+ auch mit P3.6 gemacht werden das ist lt WCHIsptool sogar der Default. Das könnte das Problem mit den Chips von Ali sein.
Thomas Z. schrieb: > Aaron C. schrieb: >> Leider werden auf Aliexpress CH552G varianten ohne vorgeflashten >> bootloader verkauft. > > mir ist gerade noch was eingefallen. Beim V2.31 und wie ich gerade > gesehen habe beim V2.40 Loader kann die HW Aktivierung anstelle mit D+ > auch mit P3.6 gemacht werden das ist lt WCHIsptool sogar der Default. > Das könnte das Problem mit den Chips von Ali sein. Oh danke richtig. Das teste ich ! EDIT.... Mhhh P3.6 ist USB DP :D aber teste den P1.5 zur sicherheit einmal
Mist verwechselt....
Ich hab mir jetzt den Code näher angesehen. Mir sind bis jetzt nur wenige Änderungen aufgefallen. Die wichtigste Änderung ist dass beim Verify nun nur noch Addresse < 0x3800 erlaubt sind. Dann gibt es eine kleine Änderung im Startup Code und in Main fehlt der Timeout um den Softreset zu starten. Ansonsten ist alles gleich, selbst die Variablen Belegung hat sich nicht geändert. Der Bug beim USB Setupcode ist immer noch drin.
Die Verify Funktion kann nicht mehr zum Auslesen benutzt werden da der Bytewalk nicht mehr funktioniert. Das Lowbyte der Addresse muss ein Vielfaches von 8 sein, was in der Konzequenz bedeutet dass man für 8 Bytes 2^64 Kombinationen testen müsste. Das ist praktisch nicht zu schaffen. Das haben die gut gemacht ich sehe keinen Weg das zu knacken. Das einzige was man ev noch finden kann sind leere Bereiche indem man auf 0x00 oder 0xFF testet. Ohne SPI Reader geht da nichts mehr. Als einziger Weg bleibt wohl nur ein deaktivierten SPI readout Schutz. Thomas
Ok schade, denke die möglichkeit des freien flash suchen könnte man für ein dumper ausnutzen da ist aber auch irgendwann schluss weil vor dem schreiben ja eh ein erase gemacht werden muss.
Ich werde irgendwann nächte Woche den Loader hier einstellen. Momentan taste ich mich ausgehend von V2.31 per bin Vergleich vor. Etwa die Hälfte hab ich schon. Das hat den Vorteil dass so alle Änderungen schön sichtbar werden. Ich werde die Stellen im Source dann mit v2.4 kennzeichnen.
Hier nun der Sourcecode für die v2.40. Da ich den Code von der v2.31 abgeleitet habe sind alle bisherigen Kommentare drin geblieben. Als Besonderheit kann man zwischen v2.31 und v2.40 umschalten. Wenn die Startadresse auf 0x3800 steht ist der Code binärgleich zu den jeweiligen Originalen von WCH. Zum übersetzen ist Keil notwendig die freie Version reicht. Das Header File mit den SFRs ist weiter oben zu finden.
Ich habe das neue Bit unglücklicherweise bFlashErr genannt. bVerifyErr trifft es eher. Das Bit wird beim ersten Verify Error gesetzt und wird nur vom Erase Kommando oder Neustart zurückgesetzt. Wenn das Bit gesetzt ist schlagen nachfolgende Verify Versuche fehl. Beim Erase werden jetzt 8 1k Blöcke zerstört vorher nur 4 Blöcke. Insgesamt ist der Bootloader nun dicht. Thomas
Danke fürs reinschauen. Ist aufjedenfall ziemlich interessant zu sehen das solch eine rückmeldung etwas bewirkt auch bis nach china :)
Ich werde, wenn ich Zeit finde, basierend auf Bit 14 im Configspace vielleicht probieren ein universelles win Programm zu schreiben, um einen beliebigen Bootloader auf den Chips zu installieren. Ich hab mir jetzt erst mal einen Fakeloader gebastelt um mit der V2.4 etwas zu spielen. Hat das mit dem Alichip funktioniert?
Der alichip ist leider weiterhin nicht ansprechbar und zeigt keine reaktion über usb, das Die ist verglichen und der Oszillator läuft auch also muss er tatsächlich blank sein. Selbst wenn ein Programm geflasht wäre welches den Bootloader am Start verhindert müsste man ihn trotzdem in den Bootloader bekommen per Dplus pin. Jedoch sollte dann SPI ja noch aktiviert sein vielleicht kann man damit testen per SPI zu kommunizieren wenn es bei den anderen gesperrt ist
Dann hätte ich noch die Idee mal den Reset Pin auf Low zu legen. Du erinnerst dich an mein Problem mit dem ch559 als ich nach dem ersten Flashen nicht mehr an den Chip gekommen bin? Beim Ch552 kann man ja auch den ext Reset aktivieren.
Das versuche ich noch einmal, danke. Der reset beim ch552 ist bissher standart mässig aktiviert also sobald high läuft er nicht mehr und floating / low gleich running. Hatte damit gerade erst für den HID zu Arduino code mit zutun teste es aber wie gesagt dennoch. Auch besagt ja die spi anleitung das wenn reset high ist SPI slave aktiv ist soweit ich es verstanden hatte hat nichts mit dem testen zutun aber ist für später auf jeden Fall interessant
Nun mir ist klar dass der ch559 was die Ports angeht etwas anders tickt. Floading ist bei einem default Port normalerweise eine 1. Vielleicht kannst du das Teil auch seriell dazu überreden in den Bootloader zu springen das hat mir damals beim ch559 den Arsch gerettet.
Leider hatte ich weiterhin keinen erfolg, auch über seriell nicht. Mit einem normalen chip funktioniert seriell aber mit dem Ali chip weiterhin leider nicht.
Did you evaluate the possibility of the ali chip is a total fake ?
8051 Guy schrieb im Beitrag #6391339: > Did you evaluate the possibility of the ali chip is a total fake ? Yes its genuine. Compared the die with the real one
Ich wollte eigentlich das Testprogramm zum manipulieren der Configbits auf die v2.31 erweiterten, damit es mit allen Loadern klar kommt. V2.31 und v2.40 verhalten sich da ja identisch. Dazu hab ich mir das Schreibkommado 0xa8 noch Mal näher angeschaut. Fazit es geht nicht, bit15 wir immer gelöscht bit14 immer gesetzt egal was man dem Kommando an Parameter mitgibt. Damit fällt dies Option auch weg. Für Tests mit der SPI Schnittstelle bleibt also nur der V1.1 Loader übrig.
Hallo, meine CH559 Applikation ist im Grunde genommen fertig, nun möchte ich gerne einen Bootloader schreiben, welcher das Update von einem USB Stick ließt. An sich nichts abwegiges, sowohl für das File Lesen, als auch für Flash schreiben gibt es Code Beispiele, neurdings auch ins Englische übersetzt: https://github.com/bootrino/ch559samplestranslated Beim Versuch das "CH559 U disk host file system interface" einzubinden stoße ich jedoch auf folgendes Problem: Ein Teil der Funktionalität wird nur als .LIB bereitgestellt. Ich compiliere mit SDCC und habe nun den Verdacht, dass die lib nicht mit SDCC kompatibel ist. Hat da jemand Erfahrungen oder kennt sich besser mit Keil und SDCC aus? Klar zur Not schreibe ich das alles selber mit FatFS, möchte aber nur ungern das Rad neu erfinden hier. vielen Dank
Schau dir meinen UDisk Code weiter oben an. Der compiliert auch mit SDCC. Mit einem Sprung nach 0xD800 schaltet er den 1. Usbport in den Hostmode und holt ein ev vorhandenes vordefinierten File vom Stick und flasht es auf den Controller.
oh großartig! Hatte zwar den thread durchsucht, aber das wohl leider nicht gefunden. danke
udisk-2.zip ist die Variante die auch Support für SDCC hat. Ansonsten gibt bei WCH auch einen Download der alle Beispiele enthält. Dort ist auch die UDisk Lib im Source enthalten, allerdings nur für Keil und nicht besonders effektiv. Mein Code ist vom WCH Beispiel abgeleitet.
Hi Thomas, zunächst mal vielen Dank für den uboot code, konnte ihn ohne Probleme compilieren. Mir ist klar, dass nicht alle USB-Sticks funktionieren (steht ja auch in der readme), war dann aber doch überrascht, dass von den 4 die ich hier habe leider keiner läuft. Bei 3 Stück war die Configurator Länge > 32 Byte, bei einem erhalte ich die Meldung "reading bootrecord failed". Wenn ich den length check testweise raus nehme scheint alles zu laufen, es kann aber kein file gefunden werden. Besteht irgendeine Chance durch besseres Parsen des Configuration Descriptor mehr Kompatibilität zu erreichen, oder sind das einfach alles die falschen Sticks? Beispiel Configuration Descriptor. Hier gibt es noch einen zusätzlichen Interrupt Endpoint. (7 bytes mehr) Nach auskommentieren des length checks bekomme ich dann allerdings einen "Open failed" error mit 0x42. Rootcluster und PartDataStart sind 0 Danke!
1 | descriptors[0] = "Configuration Descriptor" |
2 | bLength = 9 |
3 | bDescriptorType = USB_CONFIGURATION_DESCRIPTOR_TYPE (2) |
4 | wTotalLength = 39 |
5 | bNumInterfaces = 1 |
6 | bConfigurationValue = 1 |
7 | iConfiguration = 0 |
8 | Reserved = 0 |
9 | SupportsRemoteWakeup = 0 |
10 | SelfPowered = 0 |
11 | PoweredByBus = 1 |
12 | MaxPower = 0x31 -> 98 mA |
13 | |
14 | descriptors[1] = "Interface Descriptor" |
15 | bLength = 9 |
16 | bDescriptorType = USB_INTERFACE_DESCRIPTOR_TYPE (4) |
17 | bInterfaceNumber = 0 |
18 | bAlternateSetting = 0 |
19 | bNumEndpoints = 3 |
20 | bInterfaceClass = UsbMassStorage (8) |
21 | bInterfaceSubClass = 6 |
22 | bInterfaceProtocol = 80 |
23 | iInterface = 0 |
24 | |
25 | descriptors[2] = "Endpoint Descriptor" |
26 | bLength = 7 |
27 | bDescriptorType = USB_ENDPOINT_DESCRIPTOR_TYPE (5) |
28 | bEndpointAddress = 1 |
29 | Reserved = 0 |
30 | Direction = Output |
31 | type = Bulk (2) |
32 | reserved = 0 |
33 | wMaxPacketSize = 512 |
34 | bInterval = 1 |
35 | |
36 | descriptors[3] = "Endpoint Descriptor" |
37 | bLength = 7 |
38 | bDescriptorType = USB_ENDPOINT_DESCRIPTOR_TYPE (5) |
39 | bEndpointAddress = 2 |
40 | Reserved = 0 |
41 | Direction = Input |
42 | type = Bulk (2) |
43 | reserved = 0 |
44 | wMaxPacketSize = 512 |
45 | bInterval = 1 |
46 | |
47 | descriptors[4] = "Endpoint Descriptor" |
48 | bLength = 7 |
49 | bDescriptorType = USB_ENDPOINT_DESCRIPTOR_TYPE (5) |
50 | bEndpointAddress = 3 |
51 | Reserved = 0 |
52 | Direction = Input |
53 | type = Interrupt (3) |
54 | reserved = 0 |
55 | wMaxPacketSize = 64 |
56 | bInterval = 8 |
Welche Größen haben deine Sticks? Ich hab hier mit einem alten 1Gb und einem 16Gb Stick getestet. Sind die Sticks wirklich Fat32 formatiert? Ich muss mal nachschauen für was der Interrupt EP benutzt wird das schaut nicht nach Bulk only aus. Ansonsten sollte es kein Problem darstellen die Länge erst mal zu ignorieren. Ich nehme an du testest mit dem Debug Release. Dir ist klar dass der Filename immer upper Case sein muss und ev mit space aufgefüllt werden muss? Noch ein Hinweis benutze keine USB3sticks. Der ch559 ist USB fullspeed only. Ich hab noch nie probiert ob 3.0 Stick korrekt die 1.1 Modi beherrscht Bulk ist dort ja nur 64 Bytes. Du kannst dir ja mal die bulksize der EPs per Debug Print ausgeben lassen. Ich meine mich auch daran zu erinnern, dass im Original ein Test auf < 32 GB drin war.... Ich hatte den chin. Kommentar auch übersetzt nicht so richtig verstanden.
OK ich hab das gerade mal nachgelesen. MSC mit Interrupt EP sprechen das UFI Protokoll. Das beherrscht UDisk nicht dazu sind umfangreichere Änderungen am Protokoll notwendig. UDisk kann nur Bulk only Protokollcode 0x50. Tendenziell solltest du erst Mal mit einem alten Stick testen.
Was mich eben stutzig macht ist, dass der Stick sich sehr wohl als bInterfaceClass = UsbMassStorage (8) bInterfaceSubClass = 6 bInterfaceProtocol = 80 Meldet. Also ganz klar bulk -only UFI wäre wenn ich das richtig verstehe SubClass 4 Das ist ein recht alter 4GB Stick, Ich probiere es weiter auch mit anderen Sticks, danke erstmal :)
Bulk only Transport ist bInterfaceProtocoll=0x50. Das ist auch das was meine Sticks reporten.(usbmassbulk_10.pdf) Kannst du mal die komplette Ausgabe von UsbDevView hier einstellen? Ich muss allerdings gestehen, dass ich vorwiegend mit dem Keil getestet habe. Es ist nicht auszuschließen dass im SDCC Code noch ein Bug steckt. Versuch dich mal im Debug Release mit zusätzlichen printf Ausgaben ranzutasten. Ich würde beispielsweise mal die bulksize der beiden Bulkeps ausgeben die müssen bei fullspeed auf 64 stehen. Zusätzlich kannst du mal ausgeben ob die Zuordnung für in und out korrekt abgebildet wird.
Puh! Ok. Aaaalso, nach einigen Stunden Specs lesen und USB transfers mitschneiden habe ich nun heraus gefunden: 1. Zumindest Windows Disk Management und auch Rufus legen einfach keinen MBR an, wenn es auf dem Stick nur eine Partition gibt. Bei nur einer Partition, liegt das Dateisystem einfach an Adresse 0. Nur bei 2 oder mehr Partitionen (oder wenn bootbar) wird ein MBR angelegt. Das sollte sich durch einen zusätzlichen Check:
1 | if( (TxBuffer[0]==0xEB) && // JMP |
2 | (TxBuffer[1]==0x58) && // Marker FAT32 |
3 | (TxBuffer[2]==0x90)) // JMP offset |
recht gut herausfinden lassen. 2. Manche Sticks geben sich als "Bulk only Transport"
1 | bInterfaceClass = UsbMassStorage (8) |
2 | bInterfaceSubClass = 6 |
3 | bInterfaceProtocol = 0x50 |
aus, haben aber noch zusätzliche Endpoints. Ich habe Sticks gesehen, die noch einen zusätzlichen Interrupt Endpoint haben z.B. Die sollten aber trotzdem kompatibel sein, man muss nur die Endpoints korrekt parsen Ich werde mal morgen Code schreiben und berichten.
ben utzer schrieb: > Nur bei 2 oder mehr Partitionen (oder wenn bootbar) wird ein MBR > angelegt. Das passt meine Sticks sind alle bootbar entweder ein Dos oder div Linuxe. Auf die Idee, dass der MBR fehlen könnte, bin ich nicht gekommen. Das muss abgefangen werden. Den Jmp offset sollte man ev gar nicht auswerten. Die Fat32 Erkennung ist sicher noch ausbaufähig.
Thomas Z. schrieb: > Auf die Idee, dass der MBR fehlen könnte, bin ich nicht gekommen. Die Dinger nennen sich "Superfloppy". :-) Ein besserer FAT-Check sieht so aus:
1 | if( (TxBuffer[0] == 0xE9) || |
2 | (TxBuffer[0] == 0x69) || |
3 | ((TxBuffer[0] == 0xEB) && (TxBuffer[2] == 0x90)) ) { |
4 | // ist FAT
|
5 | }
|
Kleines Update: Hatte mit dem Bootloader von Thomas angefangen, aber nun mittlerweile so viel modifiziert, dass kaum mehr was vom Originalcode übrig ist. Werde den Code posten, wenn fertig. Das ganze läuft dann über Petit FatFS und ist kompatibel mit FAT12, 16 und 32. Unterstützt sowohl Sticks, mit als auch ohne MBR.
Angehängte Dateien:
-
offline_flash.png
13 KB -
spi_interface.png
25 KB
Ich hab mir am WE das ch559evt.zip näher angeschaut. Dort gibts im PUB Ordner einen Schaltpan der die Beschaltung zum ext SPI Program Interface zeigt.Meine Vermutung ist nun, dass RST aktiv sein muss damit man den Prog Mode erreichen kann. Zusätzlich gibts eine OffLine Burner software bestehend aus exe und dll.Ich habe dann mal einfach mit dem PE explorer in die recoursen der exe geschaut. Gefunden hab ich ein chin. Dialog und ein binary blob. Das binary könnte die FW für einen CH559 sein. Ich muss mal schauen wie ich das aus den Recourcen exportiert bekomme. Vieleicht kann man damit die ext Programmierung aktivieren. Kennt jemand von euch eine Software die Unicode strings in Recourcen korrekt anzeigt? Der PE explorer zeigt nur ????? an. Für eine Übersetzung nicht hilfreich. Deshalb auch nur als png exportiert dort wird der Text korrekt angezeigt Thomas
Das sieht ja ziemlich vielversprechend aus die Datei scheint ja eine komplette ÍÑ»úÉÕ¼Æ÷ʹÓÃ˵Ã÷.pdf Anleitung zu sein
so ich hab das blob exportieren können. Es ist tatsächlich eine CH559 FW. Die FW ist ca 32k gross und leider im large mode übersetzt. Das macht die Sache ziemlich unübersichtlich. Das wird etwas dauern bis das vernüftig formatiert ist. Das gute ist es gibt jede Menge debug strings. Thomas
Denkst du es ist die Mini SPI firmware ?
Aaron C. schrieb: > Denkst du es ist die Mini SPI firmware ? keine Ahnung ich hab allerdings die Hoffnung dass die FW für beide Offline Flasher ist und dass da irgend was drin ist für den ext SPI mode. Noch ist es allerdings viel zu früh da eine Aussage zu treffen. IDA hat jedenfalls jede Menge libbcode aus der c51L.lib identifiziert. Leider gibts keineSchaltpläne der beiden Offline Flasher Thomas
Peter D. schrieb: > oder > Wickenhäuser Hehe, dass der überhaupt bekannt wurde mit der grottigen IDE... Aber genau das macht's aus und irgendwo hab ich auch noch nen Schuhkarton voll mit Boards von denen. C535 oder so ähnlich mit riesigen Wannensteckern. Mehr Adaptergebastel als sonstwas...
@Thomas Z. Wo wir gerade bei 8051 RE sind, hast du dich zufällig schonmal mit dem CC1110 beschäftigt? Bin da bei einer firmware von preisschildern auf der suche nach dem RF teil also welche frequenz sie nutzen und welches protokoll genutzt wird. Bin recht weit aber habe problem mit ghidra die richtigen Parameter für eine function rauszufinden auch weil die frequenzen über ein array geladen werden Sorry für OT
Aaron C. schrieb: > @Thomas Z. > Wo wir gerade bei 8051 RE sind, hast du dich zufällig schonmal mit dem > CC1110 beschäftigt? nein denn kenn ich nur vom hörensagen. Kennst du den Compiler? Das sollte anhandvon finger prints relativ einfach rauszufinden sein. ghidra kenn ich garnicht ich mach alles mit IDA
Der compiler müsste IAR sein. Leider gibt es das SDK nicht offen und nur einfache nicht original SDK beispiele sonst könnte man gut den code vergleichen. Mit ida habe ich es auch probiert aber ghidra ist dort angenehmer wegen der pseudocode darstellung, auch wenn es bei 8051 echte probleme hat
Aaron C. schrieb: > Der compiler müsste IAR sein. also little endian. Gibt's für ghidra sowas wie die Erkennung von Lib Funktionen?
Angehängte Dateien:
-
offline_flash1.png
12 KB
kleines Update.. ich hab die Recourcen des Dialogs nun mit hilfe des Recource Hackers überarbeitet noch sind die Strings zu lang (chin Strings sind halt kürzer) Mir ist aufgefallen, dass so ziemlich alle Controls des WCHISPTools vorhanden sind nur halt auf unsichtbar geschaltet
Cool, das sieht ja weiterhin sehr vielversprechend aus.
Ich bin inzwischen ein Stück weiter, glaube allerdings nicht dass dies zum Ziel führt, den ext SPI zu entschlüsseln. Was ich bisher gefunden habe: 1. Es gibt 2 Interrupt Funktionen USB und Timer2 2. SPI0 geht sehr wahrscheinlich auf das SPI Flash 3. Eine soft serial ist vermutlich eine I2C für die 7Seg 4. P4.0 und P4.1 sind die beiden LEDs / Statusleitungen 5. USB wird sowohl als Device oder Host betrieben 6. Es ist eine Art udisk für das Spi Flash implementiert. 7. printf geht auf Uart0 wegen der original putchar Funk. 8. P0 ist vermutlich das machine Control Interface Ich kann den Code inzwischen bitgleich zum Original übersetzen, allerdings sind noch viel zuviele magic numbers im Code. Als nächstes werde ich wohl die Keil libs in include files auslagern und ein paar Makros schreiben um die Quellen einzudampfen.
Ein Zwischenstand: Ich habe die wesentlichen Funktionen inzwischen identifiziert. Nach wie vor hab ich keine Hinweise zu einem ev ext SPI Interface gefunden. Ich bin mit der Speicher und Variablen Belegung fast durch. Es gibt etwa 10 Code Referenzen die außerhalb des Codes liegen. Noch hab ich keine Idee was dort liegen muss, es wird aber von der Firmware nur lesend darauf zugegriffen. Ev sind das config Optionen. Firmware Bugs habe ich auch schon gefunden und ein memset mit der Länge null, oder ein Code Pointer der auf den Bootloader zeigt, aber im Typbyte die Kennung für idata hat.
Ich hab über die Feiertage etwas weiter gemacht... In der Firmare ist keinerlei Code drin um den ext SPI programmer zu aktivieren :-( Der große Offline Flasher ist einfach ein GangProgrammer der 8 Devices über USB Flashen kann. Er verwendet einen CH543 als Led Treiber und zur Tastenabfrage (I2C). Der 2. Baustein dürfte ein CH544 sein der als Hub für die Ports fungiert. Ev stellt der auch den Port für den Memory Stick bereit der die Statistik Daten speichert. Zusätzlich kann der große Flasher auch über ein Adapter Chips im Yamaichi Sockel flashen. Die Firmare selbst kann beide Flasher bedienen. Der MiniOffline Flasher ist eine abgemagerte Version, dort wird ein Chip seriell programmiert. Die Betriebsart wird mit P0.0 und P0.1 beim Mini eingestellt (4 Modes). Beim großen Flasher über einen DIP Schalter an P1.0 .. P1.2 (8 Modes). Insgesamt nicht das was ich mir vorgestellt hatte. Mehr lässt sich ohne Schaltpläne nur schwer ermitteln. Vielleicht frickle ich irgendwann mal ISD51 ans Ende der Firmware, damit man man in uVision auf der HW steppen kann.
Seit einiger Zeit gibt es 2 neue Controller von WCH. CH556 und CH557. Der CH556 ist der kleine Bruder mit 2 Fach Usbhub und ohne RGB Led Interface Gemeinsam ist den Chips: - 64k Flash - 8k XRam - 2 x Uart - 2 x SPI - 1 x I2C Master - 1 x I2C Slave - 1 x Usb Device - 1 x Usb Host Die Dinger sind im 48Pin Gehäuse pinkompatibel zum CH558/CH559. Das Flash Interface wurde wesentlich modifiziert. Die Blocksize ist nun 64 und lustigerweise werden beim Löschen die Bits auf 0 gesetzt. Ist also wohl eher ein EEPROM. Auch lustig: ein sfr was den Akku reversed ausgibt. Einige sfrs sind wieder im xdata implementiert. Von WCH gibt es noch keinen Beispiel Code bis auf ein paar Usb Fragmente, die Header sind weitgehend unbrauchbar. Da ich sowieso ein ch55x.h plane habe ich die header mal überarbeitet. Ich hab meine Version mal angehängt. Thomas
Mich hat das Endpoint Handling der CH5xx schon die ganze Zeit gestört, weshalb ich schon früh mit ein paar Makros gespielt habe. Allerdings hat mir das alles nicht so recht gefallen, bzw in einigen Fällen auch nicht richtig funktioniert, weshalb ich das bisher nicht benutzt habe. Nun habe in einem neuen Projekt die Dinger mal ausprobiert und getestet. Die Macros sind in einem eigenen Header File untergebracht und sollten bei allen CH5xx Chips funktionieren. Einen Hinweis zum USB core hab ich noch: Bei meinem aktuellen Projekt habe eine ganze Weile nach einem Fehler beim USB Handling gesucht. Ursache war schlussendich eine falsche Reihenfolge bei der USB Initialisierung. Es muss zuerst USB_CTRL bzw UDEV_CTRL initialsiert werden, ansonsten wird zumindest UEP2_3_MOD nicht korrekt gesetzt. Dazu ist leider nichts in den Docs zu finden. Gemerkt hab ich das auf einem CH559 dürfte aber ev auch die anderen Chips der Serie betreffen.
Danke dir für Das Update. Kann leider nicht viel meinerseits dazu beitragen derzeit aber finde es gut dass du immer noch dabei bist.
hab gerade gesehen das mein Header File einen Fehler hat: (T und R vertauscht) So ist es richtig:
1 | #define STALL_IN(ep) (UEP ##ep ##_CTRL |= UEP_T_RES_STALL)
|
2 | #define STALL_OUT(ep) (UEP ##ep ##_CTRL |= UEP_R_RES_STALL)
|
Ich überlege gerade den CH552 als UART/JTAG Bridge für einen ESP32-S2 zu verwenden. Bevor ich in China bestelle, wenn jemand noch ein paar /5-10) Exemplare hat, die er gerne los werde möchte, würde ich nehmen wollen. Danke....
Es gibt mittlerweile auch ein Shop in DE der die CH552 in beiden Gehäusen preiswert anbietet. https://www.shotech.de/de/schaltkreise/mikrocontroller/mikrocontroller-8bit/
Ich habe mal ein Compound Device bestehend aus MSD und VCP gebaut, zusätzlich würde noch ein 2. VCP oder ein HID Interface gehen. Beim VCP hab ich auch den IAD Descriptor mit eingebaut ohne IAD funktioniert das zumindest in Verbindung mit dem MSD nicht (mehr). Die Idee ist ein Device zu bauen was ohne Treiber Installation direkt verwendet werden kann, weshalb ich ausschlieslich auf CLASS Interfaces setze. Enum funktioniert und der Gerätemanager zeigt sowohl Comport als auch Memory Device an. Zusätzlich habe angefangen die USB Kompatibilität mit dem USB Command Verifyer Tool von der usb.org zu überprüfen. Das Tool ist zwar etwas wackelig, zeigt aber, dass keines der WCH samples ohne Errors durchläuft. Ich teste unter W10 und im Moment auf einem CH559. Der code sollte aber problemlos auf einem CH552 laufen.
1 | const uint8_t code ConfigDesc[98] = |
2 | {
|
3 | sizeof(ConfigurationDescriptor), |
4 | USB_CONFIGURATION_DESCRIPTOR, |
5 | sizeof(ConfigDesc),0, |
6 | 3, // 3 interfaces |
7 | 1, // one config |
8 | USB_STRING_UNDEFINED, |
9 | 0x80, // buspwerd |
10 | 100/2, // 100mA max |
11 | |
12 | // MSD Class
|
13 | sizeof(InterfaceDescriptor), |
14 | USB_INTERFACE_DESCRIPTOR, |
15 | MSD_INTERFACE, |
16 | 0, |
17 | 2, // 2 Endpoints |
18 | USB_CLASS_MSD, |
19 | MSD_SUBCLASS_SCSI, |
20 | MSD_PROTO_BULKONLY, |
21 | USB_STRING_UNDEFINED, |
22 | |
23 | sizeof(EndpointDescriptor), |
24 | USB_ENDPOINT_DESCRIPTOR, |
25 | 0x2, |
26 | EP_BULK, |
27 | 0x40,0x00, |
28 | 0, |
29 | |
30 | sizeof(EndpointDescriptor), |
31 | USB_ENDPOINT_DESCRIPTOR, |
32 | 0x82, |
33 | EP_BULK, |
34 | 0x40,0x00, |
35 | 0, |
36 | |
37 | // IAD
|
38 | 0x08, |
39 | 0x0B, |
40 | VCP_CONTROL, // first interface = 1 |
41 | 2, // 2 interfaces |
42 | USB_CLASS_CDC, |
43 | CDC_SUBCLASS_ABSTRACT, |
44 | CDC_PROTOCOL_V250, |
45 | USB_STRING_UNDEFINED, |
46 | |
47 | // cdc class
|
48 | sizeof(InterfaceDescriptor), |
49 | USB_INTERFACE_DESCRIPTOR, |
50 | VCP_CONTROL, // interface No 1 |
51 | 0, // alternate setting |
52 | 1, // 1 extra endpoint |
53 | USB_CLASS_CDC, // class |
54 | CDC_SUBCLASS_ABSTRACT, // subclass |
55 | CDC_PROTOCOL_V250, // protokol |
56 | USB_STRING_UNDEFINED, |
57 | |
58 | 5, |
59 | CDC_CS_INTERFACE, |
60 | CDC_SUB_HEADER, // identifier header |
61 | BCD_CDC & 0xFF,BCD_CDC >> 8,// |
62 | |
63 | 5, |
64 | CDC_CS_INTERFACE, |
65 | CDC_SUB_CALL_FUNCTION, // identifier Call Management |
66 | 0x00,0x00, |
67 | |
68 | 4,CDC_CS_INTERFACE, |
69 | CDC_SUB_ABSTRACT_CTRL, // identifier Abstract |
70 | 0x02, // cababilities |
71 | |
72 | 5, |
73 | CDC_CS_INTERFACE, |
74 | CDC_SUB_UNION_FUNCTIONAL, // identifier Functional |
75 | VCP_CONTROL, // interface 1 ctrl |
76 | VCP_DATA, // interface 2 Data |
77 | |
78 | sizeof(EndpointDescriptor), |
79 | USB_ENDPOINT_DESCRIPTOR, |
80 | 0x81, // ep1 in |
81 | EP_INTERRUPT, // interrupt |
82 | 8,0, |
83 | 0xFF, // interval |
84 | |
85 | //interface2 data interface
|
86 | sizeof(InterfaceDescriptor), |
87 | USB_INTERFACE_DESCRIPTOR, |
88 | VCP_DATA, // interface No 2 |
89 | 0, // alternate setting |
90 | 2, // 2 extra endpoint |
91 | CDC_CLASS_DATA, |
92 | USB_SUBCLASS_UNDEFINED, |
93 | USB_PROTOCOL_UNDEFINED, |
94 | USB_STRING_UNDEFINED, |
95 | |
96 | sizeof(EndpointDescriptor), |
97 | USB_ENDPOINT_DESCRIPTOR, |
98 | 0x03, // ep3 out |
99 | EP_BULK, // bulk |
100 | 0x40,0x00, |
101 | 0x00, // interval |
102 | |
103 | sizeof(EndpointDescriptor), |
104 | USB_ENDPOINT_DESCRIPTOR, |
105 | 0x83, // ep3 In |
106 | EP_BULK, // bulk |
107 | 0x40,0x00, |
108 | 0x00
|
109 | };
|
Heute habe ich den WCH552G auf meine Board aufgelötet und nach kleinen Startschwierigkeiten das CDC Beispiel auf UART0 angepasst zum Laufen bekommen. Sehr schön! Mir ist jetzt aufgefallen, dass allerdings der Reset nicht funktioniert. Wenn ich, durch einen Drucktaster auf der RST Leitung einen High-Pegel anlege, dann passiert irgendwie nichts. Meine Led bleibt an und das Gerät verschwindet auch nicht vom USB Bus. Muss ich da noch irgendwas anprogrammieren?
Andreas M. schrieb: > Muss ich da noch irgendwas anprogrammieren? Ja du musst den Reset Pin im WchIspTool beim Flashen aktivieren. Es gibt dafür eine Optionshaken
Angehängte Dateien:
-
pcb_preliminary.jpg
60 KB
Thomas Z. schrieb: > Ja du musst den Reset Pin im WchIspTool beim Flashen aktivieren. Es gibt > dafür eine Optionshaken Danke, dann muss ich wohl mal eines der freien Tools so anpassen, dass das geht, habe kein Windows :-) Nachdem ich dann über ein paar Eigenheiten des SDCC (2-dim array) gestolpert bin und auch an einigen anderen Stellen zu kämpfen hatte, habe ich erst mal einen guten Zwischenstand bei meinem Projekt erreicht. Auf dem WCH552 laufen jetzt parallel ein 115.2kBaud USB-To-Serial mit Double Buffering zum Programmieren des ESP32-S2 und eine JTag Emulation des espjtag Interfaces von Espressif. Letzteres hat wohl irgendwo noch ein Problem, der openocd findet zwar die CPU und kann auch Register auslesen aber im GDB klappt das setzen von Breakpoints und das Steppen noch nicht. Irgendwann bleibt dann auch die USB Kommunikation mit dem openocd stehen. Um das näher zu untersuchen muss ich mir mal was überlegen, eventuell einen USB Control Transfer mit dem ich mir die Variablen aus dem WCH ziehen kann. Der espjtag treiber im openocd hat leider ein paar Schwachstellen wo er sich beim kleinsten unerwarten Verhalten am USB in eine Endlosschleife legt. Irgendwo wird wohl in meinem Programm was nicht passen, eventuell habe ich auch noch einen Dead-Lock im Ablauf. 8051 und auch der SDCC ist für mich Neuland, man kann ja leider nicht einfach rein debuggen (https://github.com/espressif/openocd-esp32/blob/master/src/jtag/drivers/esp_usb_jtag.c) Eventuell geht auch noch eine Schneller Baudrate, für 115200 muss die Chipfrequenz allerdings auf 24MHz gestellt werden, das ergibt dann ziemlich genau einen Takt-Teiler von 13. Hier liegt das Projekt: https://gitlab.com/amesser-group/electronic-devices/bastelino-esp32-s2 PS: Auf den Bild darf man meine Unfähigkeit, dass richtige Gehäuse zu bestellen bewundern :-) Ich habe mich dummerweise am Produktbild auf der Shop-Webseite orientiert.
Angehängte Dateien:
-
p2330692_crop.jpg
300 KB -
p2330693_crop.jpg
400 KB -
p2330703_crop_ch552g.jpg
250 KB
Moin, der Vollständigkeit halber möchte ich erwähnen, dass der Low-Cost-Programmer "EZP2019 Plus" (z.B. https://www.ebay.de/itm/264972921339) auch den CH552G verwendet. Ich hatte mich gewundert, als ich den gestern aufgemacht habe und gesehen hab, dass es ein USB-Controller aus der CH-Famile ist, aber ohne Quarz. Darum hab ich recherchiert und bin u.A. auf diesen Beitrag gestoßen. Beste Grüße, Marek
Vielen dank für die info Das heist andersrum ja auch das man den programmer nachbauen könnte :)
Ich habe auch den Verdacht, dass viele dieser billigen LED Panel Meter den CH552 benutzen und dort einfach ein Dual Slope Converter in Software nachgebaut wird. Ich hab leider keines zur Hand um das zu überprüfen. Ist also nur eine Theorie aufgrund diverser Bilder.
ich habe mal angefangen mit github zu spielen.... Herausgekommen ist ein erstes repro was sich mit den CH55x beschäftigt. Hab da einfach mal ein paar infos reingehackt. Noch sind nur ein paar grundsätliche Dinge drin. Aber ein Anfang ist gemacht.. https://github.com/usbman01/WCH-8-Bit-x51-controllers
Ich bin jetzt inzwischen mit meinem Debugger weitergekommen. Ich habe das Protokoll jetzt auf OpenULINK umgestellt und kann damit jetzt erfolgreich JTAG debuggen und parallel dazu die UART laufen lassen. Jetzt versuche ich gerade den Stromverbrauch zu optimieren und bin dabei über ein Problem mit der PWM gestolpert. Ich dachte zunächst, es hängt irgendwie mit dem Standby zusammen, aber da ist noch was anderes nicht in Ordnung. Mit einem Code-Schnipsel, der einfach nur schnell auf das PWM2_DATA Register immer wieder den gleichen Wert schreibt, sehe ich auf dem Oszi als Ergebnis, dass die PWM ab und zu, für einen Zyklus einen Duty-Cycle von 100% erzeugt und dann wieder den korrekten Duty-Cycle macht. Das ist mir aufgefallen, weil da eine LED dranhängt. In dem Header und dem Manual liest man was von PWM FIFO. Wirklich Informationen habe ich dazu aber leider nicht gefunden. Weis da jemand genaueres, was man bei der PWM beachten muss? Leider sind ja alle Kommentare auf Chinesisch
Andreas M. schrieb: > Leider sind ja alle > Kommentare auf Chinesisch Google Translate aufs Handy, Kamera Live Übersetzung wählen und los gehts. Nicht super komfortabel, aber so ist Chinesisch kaum noch eine Hürde.
Harald schrieb: > Google Translate aufs Handy, Kamera Live Übersetzung wählen und los > gehts. Nicht super komfortabel, aber so ist Chinesisch kaum noch eine > Hürde. Das habe ich schon gemacht ( Copy-Paste aus dem PDF Reader reicht dazu auch) Allerdings sind die Informationen zur PWM leider sehr dürftig. Leider gibt es auch ausgerechnet zur PWM kein Schaubild über den Internen Aufbau. Meine Vermutung ist nämlich, dass die irgendwie noch einen PWM Sequenzer mit einer FIFO oder extra Puffer drinnen haben. Das Clock-Schaubild zeigt auch zwei Takte die in die Unit reingehen. Der eine kann mit einem Teiler konfiguriert werden wobei nicht wirklich klar ist, für was der Teiler ist. Wenn man die PWM Auflösung von 256 Stufen und den 8 Bit Teiler berücksichtigt, dann könnte man auf die Idde kommen, das der Teiler für den PWM Grundtakt zuständig ist. Das Oszi hatte das PWM Signal auf ca. 83Hz taxiert, der Grundtakt waren 6MHz ( Interner RC Oszillator) Meine Vermutung ist, das der interne Komparator irgendwie auf die Nase fällt, wenn man das PWM Register zum falschen Zeitpunkt schreibt. Es gibt da ein paar Status Bits. Es gibt auch "End Of Cycle" Interrupte für die PWM. Ich werde mal versuchen die zu benutzen.
Ich selbst ha mich noch nicht mit dem PWM Modul beschäftigt, weis aber aus dem WCH Forum, dass sich die Leute über die mangelhafte Doku beschweren. - Wie hast du den initialisiert? - welchen Teiler verwendest du bei welcher fSys? Ist dir klar dass du nur neuschreiben darfst wenn das bPWM_IF_END Flag 1 ist? Also entweder pollen oder Interrupt aktivieren. Das PWM Example aus CH554EVT.zip kennst du? Edit ok den letzen Beitrag hatte ich nicht gesehen der beantwortet ja die Fragen
Thomas Z. schrieb: > Ich selbst ha mich noch nicht mit dem PWM Modul beschäftigt, weis aber > aus dem WCH Forum, dass sich die Leute über die mangelhafte Doku > beschweren. > > - Wie hast du den initialisiert?
1 | /* setup pwm for led */
|
2 | PWM_CTRL = bPWM2_POLAR | bPWM2_OUT_EN; |
3 | PWM_DATA2 = 0x40; |
> - welchen Teiler verwendest du bei welcher fSys? Ich habe Fsys=6 MHz, Das PWM Teiler Register fasse ich (bisher) nicht an. Allerdings wird Fsys je nach UART Baudrate erhöht. > Ist dir klar dass du nur neuschreiben darfst wenn das bPWM_IF_END Flag 1 > ist? Jetzt schon :-) Danke für den Hinweis, mein Chinesisch ist nicht so gut :-) > Also entweder pollen oder Interrupt aktivieren. > Das PWM Example aus CH554EVT.zip kennst du? Ich hatte gestern mal angefangen verschieden Beispiele durchzusehen, bin aber noch nicht so weit gekommen. (Falls es jemanden interessiert, der vollständige Quellcode liegt hier: https://gitlab.com/amesser-group/electronic-devices/bastelino-esp32-s2/-/tree/master/firmware/programmer)
Andreas M. schrieb: > mein Chinesisch ist nicht so gut > :-) meins auch nicht aber google Translate funktioniert erstaunlich gut WCH hat übrigns was ganz ähnliches gebaut, die nennen es WCH Link baasierend auf einem CH549. Das Ding stellt einen DAP debugger + VCP bereit. Das Teil braucht ma wohl um den M3 Cortex oder den RISC V core unter dieser chin Moun River Studio IDE zu debuggen / flashen. Infos unter https://github.com/kaidegit/CMSIS-DAPbyWCH
Thomas Z. schrieb: > WCH hat übrigns was ganz ähnliches gebaut, die nennen es WCH Link > baasierend auf einem CH549. Das Ding stellt einen DAP debugger + VCP Danke, gut zu wissen. Das Teil ist ja quasi für solche einfachen Debugger prädestiniert. Espressif hat bei seiner toolchain den openocd leider um eine ganze Menge Treiber erleichtert, so dass die Auswahl an verfügbaren Protokollen nicht so gut ist. Aber ich werde es mir mal merken ( Falls ich meinen Lauterbach Power Debug irgendwann mal nicht mehr haben sollte )
Eigendlich hatte der Vertrieb von WCH versprochen mir so einen WCH-Link kostenfrei zu schicken... Das war allerdings vor 5 Wochen. Seitdem hab ich nichts mehr von denen gehört. Das wird dann wohl auf einen Selbstbau rauslaufen, wenn der CH549 im SO16 Gehause wieder allgemein verfügbar ist Momentan gibts nur die QFN Variante, die trau ich mich nicht von Hand zu löten,
Thomas Z. schrieb: > Ist dir klar dass du nur neuschreiben darfst wenn das bPWM_IF_END Flag 1 > ist? Ja, das war es. Mache es jetzt in der ISR, jetzt läuft die LED so wie sie soll. Danke! Irgendwann muss ich mir dann nochmal das Powermanagement ansehen. In den Beispielen sieht man immer das WAKE_CTRL direkt vor setzen des PD bits geschrieben wird im SAFE_MODE. Ich habe das bei mir ja aufgeteilt und Setze WAKE_CTRL nur einmalig beim Start und später nur noch das PD Bit. Nach den Strommessungen her sehe ich aber keinen Unterschied im Stromverbrauch in beiden Methoden. Allerdings ist der Verbauch des Gesamtboards höher als erwartet. Kann aber gut sein, das der ESP nicht wirklich schläft.
Andreas M. schrieb: > Irgendwann muss ich mir dann nochmal das Powermanagement ansehen. In den > Beispielen sieht man immer das WAKE_CTRL direkt vor setzen des PD bits > geschrieben wird im SAFE_MODE. Ich habe das bei mir ja aufgeteilt und > Setze WAKE_CTRL nur einmalig beim Start und später nur noch das PD Bit. beide Methoden sind gleichwertig. Ich vermute mal dass du den Chip bei USB Events und RX Events aufwecken willst. Ob du das nun einmalig beim ProgStart machst oder immer bevor du PD aktivierst ist dann egal. Ich werde die Erkenntnisse zum PWM Modul in mein Repro zu den CH55x mit aufnehmen wenn ich das Repro umbaue.
Da ich nicht mehr glaube dass der WCH Link hier noch ankommt, habe ich mir das Binary aus der Repro mal näher angeschaut. Das ist ja für den CH549 gebaut die es wohl auch in absehbarer Zeit nicht geben wird. Das Binary besteht au 2 Progammen. Teil 1 ist wohl ein Bootloader der das WCH übliche IAP Protokoll macht (0x000 .. 0xBFF) Teil2 (0xC00 .. 0xBC60) ist der eigentliche WCH-Link. Das Ding beherscht zwei grundsätzliche Betriebsarten. Einnmal HID/VCP damit ist wohl der CMSIS-DAP realisiert, die 2. Betriebsart ist vendor defined und ist ev das Interface zum RiscV. Generell entspricht die Codequalität dem was wir von WCH schon kennen um max ineffizenten Code zu generieren - alle Module im large Mode - haufenweise Var Inits auf File Ebene (Inittable ist 640 Bytes lang) - maximal umständliche Konvertierungen von LSB <> MSB - viele unbenutzte Funktionen Wegen der Code Größe kommen nur die 64k Chips in Frage also entweder CH549 CH557 CH559 wobei beim CH559 das Flash Interface ein anderes ist. Ich hab für ein paar kurze Tests die USB Initialisierungen einfach mal auf den CH559 angepasst, das funktioniert auf Anhieb. Ich bin mir relativ sicher dass man den CMIS_DAP auch auch einem CH552 ans laufen bekommt wenn man die Vendor Betriebsart entfernt. Weil ich neugierig war hab ich dieses mal auch Ghidra benutzt. Gefällt mir ausgesprochen gut. Ich glaube es lohnt sich dafür etwas flirt ähnliches zu bauen um die runtime libs zu lokalisieren.
Thomas Z. schrieb: > Teil2 (0xC00 .. 0xBC60) ist der eigentliche WCH-Link. Das Ding beherscht > zwei grundsätzliche Betriebsarten. Einnmal HID/VCP damit ist wohl der > CMSIS-DAP realisiert, die 2. Betriebsart ist vendor defined und ist ev > das Interface zum RiscV. Ok, gut zu wissen. Ich habe leider inzwischen bei meinem Code/Schaltung Probleme festgestellt. Ich weis noch nicht genau wo es herkommt. Meistens geht es, aber von Zeit zu Zeit gibt es bei der UART und auch beim JTAG Kommunikationsprobleme. Ich konnte noch nicht herausfinden wo es herkommt bzw. was das genaue Problem ist. UART ist ja meist prädestiniert für Fehler im Timing, aber JTAG ist ja quasi-statisch bzw. durch den Takt synchronisiert und da sehe ich ja auch Fehler. Möglicherweise hängt es mit den Spannungspegeln zusammen? Der WCH läuft bei mir ja mit 5V damit er programmierbar ist. Deswegen habe ich vom WCH 5V -> ESP32 3.3V Levelshifter mit 74HC4050. Die Richtung ESP32 -> WCH habe ich direkt verbunden. Wenn ich das Datenblatt des WCH richtig lese, dann sollte der bei 5V Betriebsspannung ab 2,4V einen High-Pegel erkennen. Ich hatte zunächst versucht die Pins des WCH, die ich als Eingang benutze als echte Inputs zu konfigurieren. ( Nicht den Bi-Dir Mode des 8051) Das schien anfänglich auch zu helfen aber inzwischen habe ich den Fehler wieder gesehen. Mal sehen wie ich da weiterkomme. Vielleicht ist auch noch irgendwas in meinem Programm quer, aber das sollte ja wiederum die UART nicht treffen. Vielleicht gibt es Probleme wenn gerade viele Interupte im System aktiv und der USB Interrupt nicht zeitnah bedient wird? Ich fühle mich beim 8051 mit sdcc noch nicht wirklich heimisch. Irgendwo hab ich mal was von Overlays gelesen und das man da mit Interupten aufpassen muss. Da der Fehler nur sporadisch auftritt muss ich mir mal überlegen wie ich das weiter untersuchen kann.
Das riecht etwas nach nicht atomic Zugriff auf Variablen. Kandidaten sind Variablen die sowohl im Irq als auch auserhalb verwendet werden , speziell dann wenn das 16 Bit Vars sind. Wie hast du die Irqs priorisiert? Ev solltest du mal einen Irq in einer eigenen Registerbank laufen lassen. WCH läßt beim Link alle 3 Interrupts (USB, Uart, Timer2) in eigenen Registerbänken laufen, Ich bin aber der Meinung das das zumindest beim T2 unnötig ist der nur TimeOut Funktionen bedient. Man spart sich lediglich das PUSH/POP von R0..R7. Ansonsten würde ich wohl den 2. Uart initialisieren und ab und an ein paar printfs raushauen. Dazu must du eine CharOut Funktion für diesen Uart dazulinken. Details dazu stehen im SDCC Handbuch. Ist der code auf Git aktuell?
Thomas Z. schrieb: > Wie hast du die Irqs priorisiert? Ev solltest du mal einen Irq in einer > eigenen Registerbank laufen lassen. Damit hatte ich mich bisher noch gar nicht beschäftigt. Das mit den Registerbänken muss ich mir dann auch mal ansehen wie das funktioniert. Bisher kenne ich sowas ähnliches nur vom ARM926/966, wobei dort ja nicht zwischen den verschiedenen IRQs unterschieden wird. Wenn ich unterschiedliche IRQ Prios vergebe, unterbrechen sich dann die IRQs auch gegenseitig? Ich vermute mal, da braucht man dann zwingend unterschiedliche Bänke? Thomas Z. schrieb: > Ansonsten würde ich wohl den 2. Uart initialisieren und ab und an ein > paar printfs raushauen. Dazu must du eine CharOut Funktion für diesen > Uart dazulinken. Details dazu stehen im SDCC Handbuch. Hmm, das Problem ist, das der WCH selbst ja nix davon mitbekommt wenn ein Fehler auftritt. Mal sehen ob ich da irgendwo ansetzen kann. Entweder beschwert sich der ESP-IDF Programmer über einen Timeout oder der openocd kann den ESP nicht anhalten. Beim Programmer reicht ein Neustart. Beim openocd meist jedoch nicht, da scheint das Verhalten eher vom Mond abhängig zu sein. :-) Manchmal hilft es einen anderen USB Port zu nehmen. Thomas Z. schrieb: > Ist der code auf Git aktuell? Ja
Andreas M. schrieb: > Wenn ich unterschiedliche IRQ Prios vergebe, unterbrechen sich dann die > IRQs auch gegenseitig? Ich vermute mal, da braucht man dann zwingend > unterschiedliche Bänke? nein das nichts miteinander zu tun. Mit dem Bankswitch sparst du nur die PUSH/POP für R0..R7, das heist deine IRQ Latenz wird etwas besser. Die natürliche Priorität ist durch die Interrupt No vorgegeben, bedeutet ein IRQ mit der kleineren No wird immer einen Interrupt mit höherer No unterbrechen, wenn du nicht sperrst. (Ein wesenticher Unterschied zu den AVRs) Der USB Irq liegt bei 0x43 bei dem würde ich die Prio anheben dann können die anderen Irqs den USB Traffic nicht mehr unterbrechen (unter der Vorraussetzung dss alle anderen IRqs auf Pri0 laufen) Zum Verständnis deines Codes: ich hab da grad mal etwas quergelesen EP1 In ist der VCP Status (unbenutzt) EP2 bulk In/Out dein JTAG EP3 bulk In/Out der VCP richtig so? Ich hab leider nicht gesehen ob USB überhaupt auf einem Interrupt läuft.
Thomas Z. schrieb: > Die natürliche Priorität ist durch die Interrupt No vorgegeben, bedeutet > ein IRQ mit der kleineren No wird immer einen Interrupt mit höherer No > unterbrechen, wenn du nicht sperrst. (Ein wesenticher Unterschied zu den > AVRs) > > Der USB Irq liegt bei 0x43 bei dem würde ich die Prio anheben dann > können die anderen Irqs den USB Traffic nicht mehr unterbrechen (unter > der Vorraussetzung dss alle anderen IRqs auf Pri0 laufen) Ah, das ist auf jeden Fall mal ein wichtiger Punkt. Ich war bisher davon ausgegangen, dass sich die Interrupte erst mal nicht gegenseitig unterbrechen können. Da muss ich meine Code nochmal prüfen. Meine aktuelle Implementierung macht die Annahme, dass die sich nicht unterbrechen. Bei der ARM926/966 beziehungsweise bei aktuellen Cortex-R oder -A können sich Interrupte auch nicht standardmäßig einfach unterbrechen. Das muss erst explizit im Interrupthandler wieder freigegeben werden. Nur bei Cortex-M passiert das automatisch anhand der Priorität. Thomas Z. schrieb: > Zum Verständnis deines Codes: > ich hab da grad mal etwas quergelesen > EP1 In ist der VCP Status (unbenutzt) > EP2 bulk In/Out dein JTAG > EP3 bulk In/Out der VCP richtig so? Ja genau > Ich hab leider nicht gesehen ob USB überhaupt auf einem Interrupt läuft. Ja, usb.c Zeile 184 ist der Handler. Allerdings werden nicht alle Aktionen darin gemacht. bei JTAG z.B. wird der In/Out Endpoint einfach nur auf NAK gesetzt. Die eigentliche Datenverarbeitung geht dann über der Hauptschleife aus der main.c heraus gemacht. (openulink_protocol.c Zeile 215) Da Openulink Protocol arbeitet da quasi uni-direktinal, deswegen müsste das eigentlich passen. Die Verarbeitung des CDC erfolgt größtenteils nur im Interrupt, nur das Löschen des "NAK" bits wird aus der Main-Schleife heraus gemacht, und zwar immer dann, wenn für den Out (USB->UART) der nächste Puffer frei ist oder der nächste Puffer für den In (UART->USB) Daten zum Versenden enthält. Wobei das natürlich schief gehen könnte bzw. wird wenn da gleichzeitig der USB Interrupt für den selben Endpoint aber die andere Richtung reinkommt bzw ein ganz anderer Interrupt und dann auf dem EP_CTRL rummacht. Argh... Da werde ich wohl viel mit Interrupt-Locks ( EA=0;.. EA=1) arbeiten müssen. Was besseres fällt mir da grad nicht ein. Bei ARMs versuche ich das wo es geht zu vermeiden und nutze da das Verhalten aus, dass Interrupthandler sich nicht unterbrechen. Gibt es beim 8051 ein intelligenteren Weg das zu synchronisieren? Nachtrag: Darf ich EA=0;.. EA=1; auch innerhalb eines Interrupthandlers schreiben?
Immer dort wo du im MainContext an EPxControl rumfummelst muss zwingend der USB IRQ gesperrt werden. Also immer dann wenn du ein NAK/ACK aif den Bulk EPs machst. EA = 0/1 ist der falsche Ansatz die Bits des Interrupt Registers kannst du einzeln direkt setzen. IE_USB=1 / 0 Die anderen Interrupts dürfen weiterlaufen. Nur Variablen die im Irq Kontext und Main Kontext gelesen/geschrieben werden brauchen spez Beachtung insbesondere wenn es 16 Bit Vars sind. EA im Interrupt zu setzen / löschen macht beim 8051 keinen Sinn ist aber erlaubt. Ich kenne sowas nur von den AVRs. Durch die natürliche Priorität wird z.B dein TimerIrq für JTAG immer den UART IRQ unterbrechen können.
>> zwei grundsätzliche Betriebsarten. Einnmal HID/VCP damit ist wohl der >> CMSIS-DAP realisiert, die 2. Betriebsart ist vendor defined und ist ev >> das Interface zum RiscV. kleine Korrektur meinerseits: Die 2 Betriebsarten sind CMSIS V1 bzw CMSIS V2 des DAP. Bei V2 wird anstelle des HID Interfaces ein WinUSB Device enumeriert. https://arm-software.github.io/CMSIS_5/DAP/html/dap_revisionHistory.html Die Umschaltung wird über Settings im DataFlash gemacht welches beim Start ausgewertet wird. Eine etwas abgespeckte Firmware wird auch in den CH552 passen. Ich probier das gerade mit dem Stick von Aaron aus. V1 passt locker in 6kByte wenn man die lsb <> msb Konvertierung mit einem htonl() in Assembler erledigt. Auch die 128 Byte DataFlash würden ausreichen. Lediglich fSys wäre nur 24MHz anstatt der 48Mhz beim Original. Da muss man etwas an den nops beim SWD Interface anpassen.
Thomas Z. schrieb: > Durch die natürliche Priorität wird z.B dein TimerIrq für JTAG immer den > UART IRQ unterbrechen können. Ich habe mich jetzt mal ein bischen mehr in das Thema Interrupte beim 8051 eingelesen. So wie ich die verschiedenen Beschreibungen aus dem Internet verstehe, gibt es beim 8051 je nach Implementierung zwei bis vier Prioritätsebenen. Man kann jeden Interrupt durch entsprechende Konfigurationsregister einer dieser Ebenen zuordnen. Die Interrupthandler die zur gleichen Prioritätsebene gehören werden sequenziell nacheinander ausgeführt, entsprechend Ihre Interruptnummer und unterbrechen sich nicht gegenseitig. Ein laufender Interrupthandler kann nur von einem Interrupthandler einer höheren Prioritätsebene unterbrochen werden. Das macht für mich auch am Sinn, denn sonst wird die Synchronisierung zwischen Interrupten aufwändig und kostet Performance und Speicher. Nach Deiner Beschreibung müsste dass dann beim WCH552 jedoch anders sein? Thomas Z. schrieb: > Immer dort wo du im MainContext an EPxControl rumfummelst muss zwingend > der USB IRQ gesperrt werden. Also immer dann wenn du ein NAK/ACK aif den > Bulk EPs machst. Naja, wenn ich zum Beispiel im ISR den Bulk EP nach Empfang nur auf NAK stelle und dann später im Main Context nach der Verarbeitung der Daten den Bulk EP wieder auf ACK stelle, dann sollte das auch ohne Interruptsperre funktionieren. Denn solange der EP auf NAK steht dürfte gar kein weiterer Interrupt für diesen EP mehr auftreten und somit der Handler sowieso nicht mehr an dem Register rumfummeln. Ich denke man muss nur sicherstellen das die "Besitz"-Übergänge passen und je nach Zustand jeweils nur ein Kontext "fummelt".
Andreas M. schrieb: > Nach Deiner Beschreibung müsste dass dann beim WCH552 jedoch anders > sein? Nein ich hab das falsch beschrieben, das war Unsinn. Interrupts der gleichen Prio unterbrechen sich nicht. Die Reihenfolge wird durch die Interrupt Nummer festgelegt. Die WCH Dinger haben 2 Prio Ebenen. zu EPxCtrl: wenn du sicherstellst, das EPxCtrl nur durch einen Befehl manipuliert wird brauchts keine Sperre Beispiel: UEP1_CTRL &= ~MASK_UEP_T_RES; //stellt den EP1In auf ACK das wird zu anl UEP1_CTRL, #~ MASK_UEP_T_RES; -> 1 Befehl das ist aber nur bei einfachen Verknüpfungen sichergestellt. Oft wird EpXCtrl erst mal in den Akku kopiert dort manipuliert und dann zurückgeschrieben. Da du nicht sicher sagen kannst ob es ein einzelner Befehl wird, ist die Sperre da die einfachste Lösung. Du kannst natürlich auch ins LST File schauen. Mit der Sperre bist du auf der sicheren Seite. Ob diese in jedem Fall notwendig ist müsste man sonst für jeden einzelnen Fall überprüfen. Übrigens macht das WCH bei einigen neueren Beispielen nun auch so.
Angehängte Dateien:
-
Uv_debug.png
150 KB
Ich arbeite im Moment an einem Replacement für das debug.c von WCH. Geplant ist die Erzeugung einer Lib die dann nur noch zur Anwendung gelinkt wird. Im ersten Schritt erst mal für Keil, ich will das jedoch auch den für SDCC machen. Ich hatte debug.c bisher nicht verwendet, sondern einzelne Funktionen daraus in mein Projekt kopiert. Es hat mich gestört wenn unreferenced function warnings auftauchen. Das passiert bei einer Lib nicht wenn diese korrekt gebaut ist. Im Anhang ein Entwurf mit den Kategorien die ich so plane. Erste Tests waren erfolgreich. Da die Controller in der Regel keinen Quarzanschluss haben (den gibts nur im 20Pin Gehäuse). habe ich mich bei der ClockConfig momentan auf den internen Oszilator beschränkt. Schwierigkeiten bereiten mir momentan noch die delay Funktionen. Ich plane die von der aktuell eingestellten Clockfrequenz abzuleiten. Das hat den Vorteil dass dann die delays unabhängig vom clock sind. Allerdings werde ich wohl auf 8 bit Parameter gehen. Ein max von 255ms bzw 255us halte ich für ausreichend. wenn jemand eine geniale Idee dazu hat wie man das kompakt hinbekommt immer her damit. Das Ganze kann man dann auf Git Hub anschauen. Das Project ist schon angelegt, aber noch auf private gestellt.
hier eine simple Funktion in Assembler für Kopieraktionen. Ich habe das Parameterhandling an memcpy angelehnt allerdings kopiert die Funktion nur max 255 bytes. der Prototyp:
1 | void fastxcpy8 (unsigned char xdata *dest, //R6R7 |
2 | unsigned char xdata *src, //R4R5 |
3 | unsigned char size) //R3 |
und das dazugehörige asm Modul
1 | sfr XBUS_AUX = 0xA2; |
2 | ?PR?_fastxcpy8?FASTXCOPY SEGMENT CODE |
3 | |
4 | PUBLIC _fastxcpy8 |
5 | $REGUSE _fastxcpy8(R7,A,DPTR) |
6 | |
7 | RSEG ?PR?_fastxcpy8?FASTXCOPY |
8 | _fastxcpy8: |
9 | INC XBUS_AUX ;second DPTR is always dest |
10 | MOV DPH,R6 |
11 | MOV DPL,R7 ;destination |
12 | |
13 | DEC XBUS_AUX |
14 | MOV DPH, R4 |
15 | MOV DPL, R5 ;source |
16 | |
17 | mov A,R3 |
18 | MOV R7,A |
19 | JZ ?C001 ;nothing todo |
20 | |
21 | ?C000: MOVX A,@DPTR ;read source |
22 | INC DPTR ;maybe enable autoinc on DPTR0 |
23 | DB 0A5H ;MOVX @DPTR1,A & INC DPTR1 |
24 | DJNZ R7,?C000 |
25 | ?C001: RET |
26 | |
27 | END
|
Das INC DPTR könnte man noch sparen wenn man das autoinc feature aktiviert. Ich habe mich bewußt für die memory specific pointer endschieden weil sonst nicht alles in den Registern übergeben werden kann. Eine 2. funktion fastccpy8 kann aus dem Codebereich kopieren. Ach ja fast vergessen das passt so natürlich nur den Keil C Compiler. SDCC muss ich erst noch anlesen.
ich hab jetzt mal die Delay Funktionen implementiert. Die brauchen vermutlich noch etwas Feintuning und bei fSys <=750 KHz stimmen die Zeiten wohl nicht. Das ist aber beim Original auch so. Der Source ist unter https://github.com/usbman01/Replacement-WCHs-debug.c zu finden. Noch habe ich keine Projekt Dateien drin und die Doku fehlt weitgehend das kommt noch wenn ich das ding auch mit SDCC am laufen habe.
so es gibt ein erstes build für den SDCC. Das war nicht so ganz einfach weil nur sehr wenig in den docs steht wie man libs baut. Auch die Sache mit der Parameter Übergabe könnte besser beschrieben sein. So wie das verstehe muss mindestens SDCC 4.0 eingesetzt werden, weil es vorher einen Bug in sdar gab und der alte lib manager nicht mehr mitgeliefert wird. Ich habe ein paar Tests im Simulator gemacht um die Parameterübergabe bei fastxcpy8 zu überprüfen das hat sowohl in Keil als auch in SDCC gut ausgesehen. Für den SDCC baue ich das Ganze einfach mit einer passenden Batch Datei. Noch hab ich nicht überprüft ob die ASM Module für die fastcopy Funktionen auch für den large mode korrekt sind. Näheres unter dem Gitlink. Das ist aber noch sehr dynamisch dort. Es fehlen immer noch vernüftige uart module. Wer sich das Zeug runterladen will sollte unbedingt die Ordnerstruktur einhalten, da mein build sowohl unter Keil als auch unter SDCC darauf abgestimmt ist.
Angehängte Dateien:
-
BaudRateCalc.png
110 KB
Für die Reload Werte beim Uart0 (T1 Baudrate) hab ich mir mal ein Spreadsheet gebaut. Damit kann man ganz gut sehen wenn der Fehler zu groß wird. 2.4% würde ich schon als grenzwertig betrachten, hat aber bisher bei mir noch funktioniert. Das Sheet für Open Office ist hier: https://github.com/usbman01/Replacement-WCHs-debug.c/tree/main/doc
Hallo, Ich habe gerade dieses Forum gefunden. Ich benutze deepL, um vom Englischen ins Deutsche zu übersetzen, also entschuldige, wenn es nicht ganz korrekt übersetzt wird. Ich bin gespannt auf meine CH55xT Leiterplatten (derzeit in der Luft so in ein paar Tagen fällig). Ich habe einige 559T, 559L Chips und 551G Chips und die Electrodragon 552, 554 & 559 Boards auch. Ich habe SDCC, MinGW und make heruntergeladen und funktionieren, aber ich habe noch keine 55x Chips programmiert. Derzeit lese ich mich durch diesen Thread und freue mich darauf, zu berichten und zu lernen. Ray :) Übersetzt mit www.DeepL.com/Translator (kostenlose Version)
Ray you are welcome. You may write here in English too. Most people here will understand it.
Angehängte Dateien:
-
CH55xT_3D.jpg
56 KB
Thanks Thomas. What program are you using to program the CH55x chips (via USB)? I am using Windows 10 Pro x64. There seems to be 3a few choices WCHISPTOOL WCHPROG CHPROG I also found the CH55xOneClickCompiler but haven't downloaded / tried it yet. I am looking for a simple / best way to get into programming these chips. I have designed a pcb that will take the CH552/CH554/CH558/CH559 T versions (SSOP-20 & TSSOP-20) chips for testing these chips which shoule be here in a few days.
Ray R. schrieb: > What program are you using to program the CH55x chips (via USB)? As long as you are using Win i would go for the WCHISPTOOL. Not because its the best tool but it works and installs certified drivers for accessing usb. As far as i know all other tools need libusb therefore you have to lock libusb to the bootloader VID/PID. Usually thats done by zadig. When doing so the WCHISPTOOL cant find the chip anymore until you remap the driver again. There are options which can be set only by WCHISPTOOl (RST pin for example on CH552 or alternate Boot Pin Option). CH55xOneClickCompiler is from Aaron here. My own Flasher which also uses the wch driver is still not ready. i have put some infos about the CH55x together at https://github.com/usbman01/WCH-8-Bit-x51-controllers There you can find headerfiles which are compatible with Keil and SDDC, basically they are the same as posted here. Thomas
One note on your PCB. WCH sais while flashing VCC should be at 5V. From expierance i know it might work in most cases at 3.3V too. So you may omit that switch and the LDO unless you want to save power. According to some posts @3.3V max fSys is 16MHz.
Thanks Thomas :) WCHISPTOOL is working and programming my Electrodragon CH552 board nicely. However, I have a problem with compiling as the code produced is completely different to the precompiled hex file. I then downloaded and tried Aaron's CH55xOneClickCompiler which also doesn't produce a correct hex file. I disabled the download in the bat file and used the wchisptool instead. I'm still trying to find the problem. Perhaps the oneclick compiler has the wrong paths. I'm not familiar with SDCC or even GCC - I'm more a designer and assembler programmer although I do program in python in my current day job. My pcbs arrived today so as soon as I sort this compile problem I cna build the boards. Looking forward to this :) Ray
Just a little more info to my compile problem... I have SDCC v4.1.0 (latest) and also v3.9.3 #11345 (MINGW64). I swapped the directory out as I have the PATHs set. Neither compiles the simple blink program correctly ie does not compare to the same as the hex file provided with the download, and neither compiled programs work after downloading. The original hex file does download correctly. BTW I haven't used SDCC or GCC before so I am a novice here. Ray
well if you are comparing original hex files from WCH to your own ones they are different, because WCH uses KEIL and you use SDCC. Both versions 3.9 and 4.1 will be ok for you, although 3.9 has a bug when it comes to creating libs. Me i am using Keil (prefered) and SDCC 4.1. With my own device headers I can compile the source with both compilers. Do you get any warnings or errors during compilation? Please post the used cmdline and your blinky.c
Thanks Thomas :) I think I have found the problem. I was testing with a CH552 which I assumed to be a subset of CH554. The header file CH554 is being used. When I tested with a CH554 chip/board the program worked and the LED(s) flashed. The ch552.h file (downloaded with WCH-8-bit-x51-controllers-master) seems quite different from the ch554.h file I was using with the CH552oneClickCompiler by Aaron. Keil version??? Seems I will need a CH552.h and debug.h and debug.c to compile for the CH552, and similarly for the CH558 & CH559 too. Is there any common way to use all these chip series with the one set of headers? My PCB can use the 20pin CH552T CH554T CH558T / CH559T. Currently I only have CH559T chips but was planning to order some of each of these. I also have some CH551G, CH554E, CH558L and CH559L chips but I haven't done pcbs for these yet. Ray
CH554 c program to flash P1.0-1.7 & P3.0-3.5 (14 pins) attached for CH554-T TSSOP-20. I am using Aaron's CH55xOneClickCompiler-master to compile (excluding chflasher.exe) an using WCHISPTOOL to flash the code with Enable RST Pin unchecked & Run the target program checked. Note this does not work on CH552 chips - need to get ch552.h working with this. Next: 1. Get serial working 2. Get SPI working (not strictly SPI so will be bit-bashing) Thanks to Thomas for helping and to Aaron for his CH55xOneClickCompiler download :)
Ray R. schrieb: > The ch552.h file (downloaded with WCH-8-bit-x51-controllers-master) > seems quite different from the ch554.h file I was using with the > CH552oneClickCompiler by Aaron. Keil version??? yes that is because this files can work with many compilers. (see compiler.h) I have testet it with Keil, SDCC and IAR. Tasking is still on my todo list. There is however one difference in my files: I did not include any typedefs like UINT16 or uint16_t because in my opinion these should not be part of a device header. In SDCC just #include <stdint.h> to have uint16_t.... BTW CH552 and CH554 differ just in one Bit (USB HOST mode) you always can use CH554 header files thats save. So your program should work on CH552 too. CH559 is a complete different matter, because some sfrs changed position and there are sfrs in xdata space too (LED,USB and others) I have tried to create some universal header some time ago but have decited otherwise, because even on such a header you need to get a define from cmdline to choose the right ones. This would make it more complex. That debug.c is originally from WCH and peronally i had never used it, but just copied needed funktions to my app. (delay_xx in your case) Replacing that debug.c by a lib is my actual goal. You can see my efforts under https://github.com/usbman01/Replacement-WCHs-debug.c but its still incomplete, usage examples are missing, no docs. But there is a first build.bat for SDCC. As you can see there i prefer relative paths. So i have no idea why your prog does not work on CH552 but we know at ALI there are guys selling disfunctional CH552 chips.
Thanks Thomas :) I will try again to use the CH554 hex file on CH552. The boards I'm currently using are from Electrodragon - I have a CH552, CH554 and a CH559. The chips I have currently are from LCSC but I do have a few coming from eBay as they were out of stock at LCSC. I'll take a look at your replacement debug.c. Perhaps I can help although I am not really a C programmer. Ray
as long as you can access the bootloader you dont have those fakes. if you want to get rid of that debug.c just copy that delay_us and delay_ms into you main.c and remove debug.c from your batch.
Thomas, The working code for CH554 will not work on CH552. I know the CH552 works because I can program it with an pre-compiled blink.hex file and it does report the downloaded CH554 code as successful. I am not sure where to look. I compared the CH554.h file with the WCH CH552.h file and noticed that there was a #define ID_554 0x54 so I tried adding #define ID_CH552 0x52 but that did not work. All registers and bit definitions are the same so that's not the problem. I simplified the code. Here is the compile info C:\SDCC\OneClick>compile006 + SDCC\bin\sdcpp.exe -nostdinc -Wall -std=c11 -I"/" -D"FREQ_SYS=24000000" -obj-ext=.rel -D__SDCC_CHAR_UNSIGNED -D__SDCC_MODEL_LARGE -D__SDCC_FLOAT_REENT -D__SDCC=3_9_3 -D__SDCC_VERSION_MAJOR=3 -D__SDCC_VERSION_MINOR=9 -D__SDCC_VERSION_PATCH=3 -DSDCC=393 -D__SDCC_REVISION=11345 -D__SDCC_mcs51 -D__STDC_NO_COMPLEX__=1 -D__STDC_NO_THREADS__=1 -D__STDC_NO_ATOMICS__=1 -D__STDC_NO_VLA__=1 -D__STDC_ISO_10646__=201409L -D__STDC_UTF_16__=1 -D__STDC_UTF_32__=1 -isystem "SDCC\bin\..\include\mcs51" -isystem "SDCC\bin\..\include" "main006.c" + SDCC\bin\sdas8051.exe -plosgffw "main006.rel" "main006".asm + SDCC\bin\sdld.exe -nf "main006.lk" packihx: read 18 lines, wrote 25: OK. hex2bin v1.0.1, Copyright (C) 1999 Jacques Pelletier Lowest address = 00000000 Highest address = 0000010F C:\SDCC\OneClick> And the zipped files are attached. Any help would really be appreciated as I don't know where to look :) BTW I found an error in debug.c that comes with Aaron's CH552OneClickCompiler. This line #elif FREQ_SYS == 26000000 CLOCK_CFG = CLOCK_CFG & ~ MASK_SYS_CK_SEL | 0x05; // 16MHz should be #elif FREQ_SYS == 16000000 CLOCK_CFG = CLOCK_CFG & ~ MASK_SYS_CK_SEL | 0x05; // 16MHz
Oops. Forgot the zip file. Ray
wow what a complicated cmd line in that batch most of it is not needed. I will check that and upload a simplified batch. I can understand why beginners with c give up when they see that. Aaron uses the large model which is not neccessary in most cases, especially on such a simple program. I will come back later. first need to look for Aarons debug.c
this ch554.h just can work if compiler.h is in the include path, which i guess is not for your installation. It seems a mix of my own header files and the original WCH ones. The echo off may cover all warnings and errors.
Ray, that hex file you postet works perfectly P1.4 is blinking. I did simulate that in Keil. Here a more simplified compile batch for the small mode. That hex is also working. So i actually dont know whats wrong. Whatever the problem is its neither the compiler nor the main.c.
Thanks Thomas. Your compile.bat is much simpler. I didn't want to mess with it too much until everything is working. The .hex file I posted works on the CH554 but doesn't work on the CH552. I can download good hex files to the CH552 so I know both the WCHISPTOOL and the CH552 board are working. However, the .hex file(s) that I compile only work on the CH554 but not on the CH552. Do you have a real CH552 and if so, could you please try this program? It should flash P1.4 and P3.3. Thanks, Ray
ok I will setup one of my boards (Aarons stick) and test it this evening. Here its 10 AM. But guess you are in very differnt timezone so it wont matter for you.
Thanks Thomas. Yes it’s now 10:30pm here - Sydney, Australia. We’re GMT+10. We FaceTime our daughter and her family who live in London most nights so I’m familiar with time zones. Ray
I looked at the hex file to see what is happening. There is setup code that is not in the listing $0006-$005E and $$00D4-$00D8 that I decoded. I'm not quite sure what it is doing yet. I also noticed that the register _SAFE_MOD $A1 (safe mode) is being set by the main.c code multiple times. Now I need to learn 8051 assembler code. I have written lots of assembler code for various micros over the last 45 years so it shouldn't be a problem.
The instructios at $0055 were wrong
90 mov DPTR,#0x0001
00
01
E4 clr A
F0 movx @DPTR,A
A3 inc DPTR
:04 005B 00 D8 djnz R0,0xfc
Problem Solved :) The CH552 board had the wrong link soldered. The 3V was joined to VSS instead of 5V. I was sure that I had successfuly programmed this board but I must have been mistaken. Thanks for your help Thomas and sorry for wasting your time. Are you still programming with these CH55x chips? If so, which ones and what are you doing with them?
The asm code you posted is part of the c-startup, I would not think to much about it. I am using CH552 mostly for various USB applications. (MIDI CDC MSC). 2 projects already reach the comercial state. Because of the security flaws in V1 and V2.3 bootloader i developed my own loader with some extras to replace the V1.1 loader. For new chips with 2.4 loader this is no longer neccessary. For development i am using my own 48 Pin CH559 breakout board. WCH has some intersting other chips including ARM / RISC but currently most of them are not available. I started with ASM 40 years ago but these days i use c and c++. Its just a hobby now although i have no problem with making some extra money with it. :-)
Bei solchen Riesen-Threads hat ja jeder das Problem, keinen Durchblick mehr zu haben und neue Einsteiger in den Thread müssten erstmal 3 Stunden lang lesen. Ich kann es auch nicht leiden, wenn die gleichen Fragen immer wieder kommen, nur weil die Leute zu faul zu Lesen sind ... aber das ist hier mittlerweile so viel Text, dass das unmöglich ist. Daher verzeiht bitte, wenn ich jetzt nicht mehrere hundert Posts durchlesen möchte um die Frage evtl. beantwortet zu bekommen: kann der Controller als USB Host agieren, so dass ich eine Tastatur oder Barcode Scanner anschließen kann und die empfangenen Infos (also gedrückte Taste / gescannten Datenblock) per UART ausgeben kann? Gibt es da schon fertigen Code für? Danke!
Moin. Dies kann der CH554, CH558 und CH559 Für den CH559 habe ich mit Bitluni einen code für genau dein vorhaben erstellt. https://youtu.be/Th88RiSmj2w
Ohh super! Das Video schaue ich mir heute Nachmittag mal an. Jetzt wollte ich mal eben sehen, wo ich die WCH µC herbekomme ..... kann es sein, dass man die hier in Europa nirgends kaufen kann? Selbst Ebay zeigt mir nichts. Klar bei Ali, aber dauert ja Wochen...
Hätte sonst noch ein paar die ich abgeben kann. Ca. 20 x CH559 und diverse (300 x ) nicht usb host fähige CH552
Aaron, What were you planning with all those CH552’s? Are they CH552T? I just received my pcbs back which take CH552/4/8/9 T versions. Has anyone checked to see if the CH340 is just a preprogrammed CH551-4? Ray
Peter, I have just read through the whole thread. Lots of good info but took a while to read through it! Ray
Thomas, Nice. I work 2 days/week programming in python. I don’t know much about C or C++. For the past 10 years I’ve been playing with the Parallax propeller P1 and P2 chips. They are 8 core 32-bit micros. The P2 has 512KB shared RAM plus 4KB RAM per core and we’re overclocking to 360MHz. Ray
@Ray I just bought them without any reason, they where just cheaper that way The ones i got are the CH552G, the ones from the first image of this thread. The CH340 / Series is a fully different chip, there are DIE shots and a bit of RE available in the web.
Angehängte Dateien:
-
SimpleComputer-pcb-top.jpg
170 KB
Here are my basic CH55xT boards, and the boards I building to use them.
Angehängte Dateien:
-
CH55xT-pcb-top.jpg
210 KB
Oops. Adding the second jpg cancelled the first. This is the basic CH55xT board.
Angehängte Dateien:
-
pinouts.png
110 KB
I found this website by Christian where you can do pinout diagrams. https://christianflach.de/ic-pinout-diagram-generator/ I have emailed Christian the code to add the CH552 family. There is a problem with the CH552P QFN pinout. Here is a pic of the pinouts
Today I did the pinout diagrams for the CH340 series, the CH551G, combined the CH552/4 series, and the CH558/9 series. Hopefully they will be on the website soon :)
Thomas, Now that I have the latest SDCC compiler v4.1.0 working for both CH552 and CH554 I have been looking at debug.h and debug.c and CH554.h. I recall you saying you wanted to tidy debug up. To me (not a GCC/SDCC C programmer) it seems that debug is not really debug, but rather a few utility routines. What are your thoughts as I don't want to reinvent the wheel? I can do something here to help if you would like, before I get too involved with coding my project. BTW I found these typos in debug.h. I am not sure where these fixes should be posted. #ifndef UART0_BUAD #define UART0_BUAD 9600 #endif #ifndef UART1_BAUD #define UART1_BUAD 9600 #endif BUAD should be BAUD in 3 places. Ray
Ray, this debug.c comes from from WCH, including all typos and limits. I guess originally the main purpose was to have printf ready for debug outputs on UARRT0. The clock & baudrate are setup by defines which means fixed consts at compile time. If you change clock during runtime for some reason, neither uart nor delay will work correctly. The main reason why i dont use debug.c is because under Keil you get warnings about unused functions. Not a real problem but i always fix my code until no warnings pop up. BTW That usage of debug.c for printf does not work anyway under SDCC out of the box, because under SDCC putc is not part of the std lib. In keil a putc version is linked to the code if printf is used for sending the output to UART0. So for SDCC you have to provide your own putc to get printf ready. There is one more thing: If you check the reload calculations for the baudrate. They use a long div which is a very bad idea on a 8 bit controller stupid since they just use a div by 10. I have not worked on my debug.lib for the last too weeks. I know there are still some flaws in the SDCC asm parts which needs to be fixed. I still did not figure out how i have to handle params for the large mode.
Thomas. Thanks for your info. I'm not sure what you suggest I do. I don't have Keil so I'm stuck with SDCC. Debug.c needs to be compiled with SDCC separately. Should I create a new library folder for CH55x and place the library in it? Split debug.c (and debug.h) into separate files (CH554config and CH554serial and CH554wdtTimer) ie For the basics - CfgFsys, mDelayus, mDelayms and put the UART routines into another file and Timer/Watchdog into a third file? Place CH554.h and CH559.h into this folder too? Ray
well as i said i dont use that debug.c at all. My controller usually work at the default fSys (6MHz) so i just copy those 2 delay functions to main and set #define FREQ_SYS 6000000L. So i have no neet for CfgFsys(). When it comes to serial com i setup the UART manually (UART1). For the Reload values I use the spread sheet from my repro. I just once had a case up to now on the ch559 where i had change fSys to 48MHz to speedup some descrampling. For that i just changed the clock for this function and fall back to the default when finished. As for CH554.h or CH559.h I have them local in \inc which means i need to copy them always into the local project. Others prefer to have those files in SDCC\inc directory. Then you always can do a #include <CH554.h> instead of some #include ".inc\CH554.h" But these are all my preferences. You also simply can use debug.c but dont forget to use -DFREQ_SYS=%dfreq_sys% when compiling debug.c
Here is my try at conditional compiling the various routines in debug.c. What I tried was to use #define in the main file (blink4.c) but it does not pass through to my debug.c/h replacement (ch554_lib.c/h) so I needed to compile using -Dxxx parameters.
I also tried splitting debug.c/h into config.c/h delay.c/h uart0.c/h uart1.c/h wdtm.c/h but in the end I wasn't happy with this.
As I mentioned a few posts back, I have done the CH55x family pinouts. They are now live soif you find any errors please let me know. Christian has done a fantastic job to take a javascript definition and render them in pictures. https://christianflach.de/ic-pinout-diagram-generator/
Ray R. schrieb: > I also tried splitting debug.c/h into config.c/h delay.c/h uart0.c/h > uart1.c/h wdtm.c/h but in the end I wasn't happy with this. yes and that tons of ifdefs are not the best way to handle this problem. This is where a real lib may be a better solution. Just put every single function in an extra file compile them and create a lib containing all that functions. The linker will just include functions used in the app. Problem solved. Check my example. The functions are named a bit different because functions also behave a little different. For example my delay functions currently just take 8 bit params and maybe they still need some finetune. I am still not sure if i should uses the same names. That multible definitions you will get comes from my own compiler.h. It seems there is something wrong with my sfr16 makro for SDCC. for now you may just ignore it. I will soon update the git repro.
Thanks for posting this Thomas. I will take a look tonight and report back. Did you take a look at the pinout diagrams?
Ray, note this lib is not very well tested, there might still be bugs inside. At this time its more like a proof of concept. That fastcopy functions will work in smal model only. Yes i checked that pinouts nice work.
Thomas Z. schrieb: > That multible definitions you will get comes from my own compiler.h. It > seems there is something wrong with my sfr16 makro for SDCC. here is modified version of the lib with no warnings. I need to update my compiler.h
Ich habe heute die Debug Lib vervollständigt und auch das Keil Projektfile hochgeladen. Es ist nun möglich die Lib für Keil und SDCC zu bauen. Ich würde mich über Tests aber auch Kritik / Verbesserungsvorschläge freuen. Einen Haken hat die Sache noch ich hatte mich beim Anlegen mit dem Ordner vertippt, CH544 anstelle von CH554. Ich bin leider noch ein ziemlicher Nob was Gid angeht. Ich hab noch nicht rausgefunden wie man ein Verzeichnisname ändert. https://github.com/usbman01/Replacement-WCHs-debug.c Nachtrag: vieleicht kennt jemand hier einen Weg wie man sdar ein controlfile mitgeben kann. Ich bin da nicht so recht schlau geworden wie das geht. Das würde die überlange zeile in der Batch verhindern.
This will partially reduce the line length set s=..\obj\sdcc\ sdar -rc %s%ch554_debug_SDCC.LIB %s%clksetup.rel %s%wdtchange.rel %s%wdtfeed.rel %s%wdtstart.rel %s%wdtstop.rel %s%delayms.rel %s%delayus.rel %s%pwm1_alt.rel %s%pwm2_alt.rel %s%uart0_alt.rel %s%uart1_alt.rel %s%fastxcopy.rel %s%fastccopy.rel %s%simpleuart.rel %s%uart0_24M.rel %s%uart0_16M.rel %s%uart0_12M.rel %s%uart0_12M.rel %s%uart0_6M.rel %s%uart0_3M.rel %s%uart0_750k.rel %s%initstdio.rel BTW The ch554_debug_SDCC.LIB you posted 2 posts back seems to compile unused routines in the hex file. Is there a way to not include unused routines?
Or try this - the ' ^\n\t' cases a continuation followed by newline and a tab. sdar -rc ^ ..\obj\sdcc\ch554_debug_SDCC.LIB ^ ..\obj\sdcc\clksetup.rel ^ ..\obj\sdcc\wdtchange.rel ^ ..\obj\sdcc\wdtfeed.rel ^ ..\obj\sdcc\wdtstart.rel ^ ..\obj\sdcc\wdtstop.rel ^ ..\obj\sdcc\delayms.rel ^ ..\obj\sdcc\delayus.rel ^ ..\obj\sdcc\pwm1_alt.rel ^ ..\obj\sdcc\pwm2_alt.rel ^ ..\obj\sdcc\uart0_alt.rel ^ ..\obj\sdcc\uart1_alt.rel ^ ..\obj\sdcc\fastxcopy.rel ^ ..\obj\sdcc\fastccopy.rel ^ ..\obj\sdcc\simpleuart.rel ^ ..\obj\sdcc\uart0_24M.rel ^ ..\obj\sdcc\uart0_16M.rel ^ ..\obj\sdcc\uart0_12M.rel ^ ..\obj\sdcc\uart0_12M.rel ^ ..\obj\sdcc\uart0_6M.rel ^ ..\obj\sdcc\uart0_3M.rel ^ ..\obj\sdcc\uart0_750k.rel ^ ..\obj\sdcc\initstdio.rel
Ray R. schrieb: > BTW The ch554_debug_SDCC.LIB you posted 2 posts back seems to compile > unused routines in the hex file. Is there a way to not include unused > routines? i guess you mean the various delayus variants. I dont see a way to not include them at this time, because of the way the function is designed. As you can see I just use the Clk register to determine which delayus will be used. So therefore i have to include all variants. Until now the 750Khz delay and 187khz delay are missing and give no acurate response.
Aaron C. schrieb: > Hello. > > The CH554, CH558 and CH559 can do this > > For the CH559 I have a code with Bitluni for exactly your project > created. > > https://youtu.be/Th88RiSmj2w I'm sharing the lesson I learned about the USB host. DO NOT USE it without a crystal. The internal oscillator is not accurate enough and some peripheral (especially AVR V-USB) will not send ACK back to host. This has been confirmed with the FAE.
Deqing schrieb: > The internal oscillator is not accurate enough and some peripheral > (especially AVR V-USB) will not send ACK back to host. This has been > confirmed with the FAE. thanks for that Info, I know some of that threads at WCH but i cant confirm that. I build a host based on a CH559 and could successfully enumerate a memory stick. No problem with datatransfer too. AVR V-USB ist a lowspeed device timing ist completely done in firmware. Maybe its a problem on LS devices or V-USB itself. Even WCH sells preprogramed chips with hostmode and without xtal CH9350
Thomas Z. schrieb: > Deqing wrote: > > The internal oscillator is not accurate enough and some peripheral >> (especially AVR V-USB) will not send ACK back to host. This has been >> confirmed with the FAE. > thanks for that info, I know some of that threads at WCH but i cant > confirm that. I build a host based on a CH559 and could successfully > enumerate a memory stick. No problem with datatransfer too. > > AVR V-USB is a low-speed device timing is completely done in firmware. > Maybe its a problem on LS devices or V-USB itself. > > Even WCH sells preprogramed chips with hostmode and without xtal CH9350 I guess the V-USB only sample 1 time for each bit while hardware USB samples more times each bit. With my test, a CH549 with 1.4% clock error dit not get any ACK. A CH549 with 0.6% clock error got ACK at the 6th request. A CH549 with 0.3% clock error got ACK every time. I did not get such issue with another USB peripheral so it may not be a common problem.
Deqing i am interested on the bootloader of the CH549. Could you do me a favour and read out code from 0xF400 to 0xFFFF and post a binary here or send it to my git email account. As you might know i am intersted on those loaders and these chips are not available right now. That would be great
Thomas Z. schrieb: > Deqing i am interested on the bootloader of the CH549. Could you > do me a > favor and read out code from 0xF400 to 0xFFFF and post a binary here or > send it to my git email account. As you might know i am intersted on > those loaders and these chips are not available right now. > That would be great I can help with that and I got multiple CH549. Do you have a code dumping the flash so I can save some time writing one?
Deqing schrieb: > I can help with that and I got multiple CH549. Do you have a code > dumping the flash so I can save some time writing one? thanks that will be great. I will prepare some code tomorrow to dump it via Uart0 in ascii. Here its already 8 pm. So you just need to connect a serial converter to uart0 and open some terminal.
Hello Deqing, i compiled a simple dumper in keil. If i did not make any mistake it should dump the the bootloader to UART0 @ 57600 8N1 in ascii. The zip contains the complete keil project, but you may simply use dumper.hex Thanks
Thomas Z. schrieb: > Hello Deqing, > i compiled a simple dumper in keil. If i did not make any mistake it > should dump the the bootloader to UART0 @ 57600 8N1 in ascii. > The zip contains the complete keil project, but you may simply use > dumper.hex > > Thanks Not sure why the code did not generate anything meaningful on UART, I guess it is the baudrate issue. I rewrote the code in Arduino with CDC anyway. All CH549 chips I have prints the same thing with a lot of 0 between F400 and FBFF. I guess it may be protected?
mm thanks for the dumping. As for CH549 this cant be the complete loader. I think you are right seems they disabled movc from 0xF400 to 0xFC00. I dont see any other way to dump this. The b formater is special to Keil. The intersting thing is that this loader is bigger than the other ones. I have already a 2.4 from the CH554. I wonder what will be dumped with E_DIS=1. Maybe a dump from 0x0000 to 0xFFFF.
Thomas Z. schrieb: > mm thanks for the dumping. As for CH549 this cant be the complete > loader. I think you are right seems they disabled movc from 0xF400 to > 0xFC00. I dont see any other way to dump this. > The b formater is special to Keil. The intersting thing is that this > loader is bigger than the other ones. I have already a 2.4 from the > CH554. > > I wonder what will be dumped with E_DIS=1. Maybe a dump from 0x0000 to > 0xFFFF. It doesn't help much.
Deqing schrieb: > It doesn't help much. ok seems this is a new core then, that simple aproaches dont work. Anyway thanks for your help. Maybe i can figure out something later.
Thomas Z. schrieb: > Deqing schrieb: >> It doesn't help much. > > ok seems this is a new core then, that simple aproaches dont work. > Anyway thanks for your help. Maybe i can figure out something later. I also tried to use the A6 verify command to dump the data. Unfortunately even with the data on 0xFC00, the A6 command did not respond OK. So I think there must be some protection as well.
Deqing schrieb: > I also tried to use the A6 verify command to dump the data. > Unfortunately even with the data on 0xFC00, the A6 command did not > respond OK. So I think there must be some protection as well. Well A6 does not work anymore in the Bootloader aera in V2.4 they fixed that. I could compile a V2.3 from CH559 to a different start address and do a fix that it would report itself as a CH559. But i am not so shure If that would help. If they disabled movc there ist no way i can think of. Further that matches with some confirmation at the WCH bbs where one guy said calling the bootloader manually does not work on CH549.
Aaron C. schrieb: > -8051 Kern mit den Meisten Standard Register, befehlen usw. nur 10-15x > Schneller In Zeiten von ARM Cortex M braucht das kein Mensch mehr. Es sei denn, man hat schon einen 5k Euro IAR-Compiler.
I did some disassembly on 0xFC00 and that part follows the general patterns i know from the other V2.4 loader. Even the vars are at the same places. some addresses: - 0xFBCA : main - 0xFC79 : mainloop - 0xFCA7 : Serial Dispatcher - 0xFD32 : FlashProgPage - 0xFD8D : Keil rand() - 0xFE23 : PrepareUsbPaket() - 0xFE5A : CopyDescPaket() - 0xFE8E : Keil ?C?CLDPTR - 0xFEA7 : Keil ?C?CSTPTR - 0xFEB9 : FlashErasePage() - 0xFED4 : C_Startup - 0xFEE0 : Uart0Rx() - 0xFEEB : Uart0Tx() A educated guess might be that 0xF400 and 0xF800 range is only activated as long as bBOOT_LOAD ==1 which means just on PwrOnReset cleared on SoftReset. Since the FlashInterface is very different from the CH559 i am hoping that it might be possible to change some bits from 0 to 1 in the unused part starting at 0xFEF5. If that is possible it simply means that last segment is not protected. Otherwise there is no way and the chips are secure. if thats working there would be the place for an attack. I need to find some of that chips.
Angehängte Dateien:
-
cdc.jpg
140 KB -
wchlink.png
38 KB -
wchlink2.png
40 KB
Ich hab mir einen neuen Stick auf Basis des CH552 gebaut. Die Platine enthält die So16 Variante der CHxxx chips 2 Leds und eine Stiftleiste die entsprechend der WCH-Link Platine belegt habe. auf der Unterseite gibts optional einen 3.3V Regler sowie ein SPI Flash. Die Platine ist mit Eagle designed, da ich aber gerade dabei bin auf KiCad umzustellen, hab ich das mal in KiCad importiert. Bis auf ein paar Bauteil Bezeichner, die ich manuell verschoben hatte, entspricht das Layout weitgehend dem Eagle Original. Als erstes habe ich meinen Midi Source und ein DualCDC portiert, beides funktioniert unter Keil schon mal. Es ist auch das erste mal dass ich meine debug lib verwendet habe (Uart1Alt(), fastccpy()). Zwar keine große Sache zeigt aber dass ich mit der Lib auf dem richtigen Weg bin. Für die USB Midi Funktion versuche ich mir gerade ein FW Update via SysEx zu bauen, die Idee dabei ist eine 2. Kopie im Flash bereitzuhalten, die CRC zu testen und dann je nach Ergebnis beim Start die FW auszutauschen.
Ich wollte mal etwas mit der USB-Host Funktion des CH559 spielen, habe mir einige Tutorials dazu angesehen. Während ich auf die HW warte mal drei Fragen dazu an die CH55x-Spezialisten: 1. Mir fällt auf, dass die Host-Designs alle ohne Quarz sind. USB-Devices ohne Quarz sind ja keine Seltenheit, beim Host habe ich das aber noch nicht gesehen. Ist der interne Oszillator so gut oder müssen die Slaves einfach mit der Abweichung leben? Bei einem Device ohne Quarz kann ich mir das gut vorstellen, bei einem Device mit Quarz hingegen weniger. 2. An einem CH559 im SSOP20 habe ich nur einen USB-Port, oder habe ich da etwas übersehen? 3. Kann ich an der USB-Serial Software zwei USB-Geräte gleichzeitig anschließen und die werden beide zum UART übertragen? Vielen Dank!
Harald schrieb: > Ist der interne Oszillator so gut oder müssen > die Slaves einfach mit der Abweichung leben? Ich hab vor einiger Zeit mal auf dem CH559 einen Host gebaut der einen Memory Stick enumeriert das hat problemlos ohne quarz funktioniert. Falls du da Bedenken hast kannst du ja einen ext Quarz benutzen und die PLL passend einstellen, hab ich allerdings noch nie gemacht. zu 2: ja nur ein Port zu 3. verstehe ich nicht
Hallo Thomas, Vielen Dank für deine Antworten. Es ist nicht so, dass ich mich um einen Quarz reißen würde - es hat mich nur gewundert. Ich denke mal, dass es in gewissen Grenzen ganz gut ohne Quarz funktioniert, im Zweifel sollte man wahrscheinlich besser einen Quarz einbauen. Zu 3. - ich meinte diesen Source hier: https://github.com/MatzElectronics/CH559sdccUSBHost Ich habe mir das Video von Aaron aber nochmal genau angeschaut und er packt ja tatsächlich zwei USB-Geräte an den CH559. Also funktionieren zwei USB Devices gleichzeitig.
Harald es gibt Hinweise, dass V-USB Probleme an einem Host ohne Quarz hat, Deqing hat weiter oben was dazu geschrieben. Aaron und ich haben das bei Devices mit HW USB nicht bemerkt. Das Beispiel von Aaron kenne ich nicht im Detail. Der CH559 besitzt keinen Hub man muss also manuell zwischen den beiden Host Ports umschalten. Es gibt nur einen gemeinsamen Registersatz für beide Host Ports. WCH hat übrigens auch einen Controller mit integriertem HUB. CH555 der wohl weitgehend vom CH556/7 abgeleitet ist. Diese Teile sind relativ neu und noch nicht allgemein verfügbar.
Hier ist der code von dem genannten beispiel https://github.com/atc1441/CH559sdccUSBHost/blob/master/USBHost.c
V-USB ist doch diese Software-Emulation eines USBs, richtig? Das hätte für mich eh keinerlei Relevanz da meiner Meinung nach völlig obsolet. Danke auch für die Erläuterung mit dem Hub. Im verlinkten Source wird ja dauernd vom RootHubPort gesprochen, meint dann aber offensichtlich in diesem Zusammenhang etwas anderes. Völlig bekloppt an dem Teil ist ja die Tatsache, dass man ausgerechnet einen der Quarz-Anschlüsse für den Download auf GND ziehen muss. Damit führt man schön die HF spazieren und ggf. noch auf einen Taster zur „verbesserten“ Abstrahlung.
Harald A. schrieb: > Völlig bekloppt an dem Teil ist ja die Tatsache, dass man ausgerechnet > einen der Quarz-Anschlüsse für den Download auf GND ziehen muss. Damit > führt man schön die HF spazieren und ggf. noch auf einen Taster zur > „verbesserten“ Abstrahlung. na ja zu dem Zeitpunkt beim PowerOn Reset ist das ein ganz normaler Port Pin. Der Controller läuft auf dem internen Oszilator, Ich glaube 12MHz. Das ganze FW Update läuft via internal Oszilator. Erst deine Anwendung gibt dann den ext Oszi frei und setzt die PLL. WCH empfiehlt danach etwa 10 ms zu warten bis das alles stabil läuft. Einen Taster wirst du nur in der Debug Version haben üblicherweise ist da einfach an Jumper gegen GND. Aufpassen must du nur wenn statt dem quarz ein Oszilator verwendet wird. Erst deine FW macht aus P4.6 den XI. Zum Verständniss: Beim PowerOn Reset und nur da wird anstelle des ResetVectors (0x000) nach 0xF400 zum Bootloader gesprungen. Ich vermute dass da einfach das BootloaderSegment nach 0x000 gespiegelt ist. Das ist natürlich Spekulation, deckt sich aber mit Erkenntnissen aus Experimenten mit Reset Pin und den Config Registern.
Ja, das hatte ich schon so verstanden, trotzdem Danke! Da sich die Anwendung mal ändern kann hätte ich schon gerne einen Taster gehabt. Ich denke ich werde einen sehr kleinen Taster ganz nah am Quarz positionieren. Das „Problem“ ist, das der Quarz im Endeffekt zu 99.999% der Betriebszeit aktiv ist. Vlt. braucht es den Quarz ja auch nicht, werde mal ein wenig auf Temperatur testen.
Ev kommt für dich auch die Alternative in Frage via 10K von DP+ nach V3.3. Dazu musst du dann den alt. Bootpin in der Konfiguration auswählen. Das muss beim allerersten Download schon selektiert werden, da nur ein leerer Chip den Bootloader automatisch startet. Das darf bei weiteren FW updates auch nicht vergessen werden, sonst kommst du auf normalem Wege nicht mehr an den Loader. Genau das ist mir bei den ersten Experimenten mit dem CH559 passiert. Der Ausweg war dann via serial ein leeres Programm aufzuspielen
Thomas, besten Dank! Im Grunde auch alles kein Problem, ich frage mich nur, wie es im Hause WCH zu dieser Designentscheidung gekommen ist. Vlt. hatten die ein Glücksrad mit 48-3 Pins und genau da ist es stehengeblieben.
Habe mich gerade nochmal mit dem "missglückten" Pin des Bootloaders auf dem Crystal-In beschäftigt. In der o.g. Firmware ist es ja so, dass Pin 4.6 permanent abgefragt wird und im Bedarfsfall in den Bootloader gesprungen wird. Ein schönes Feature, dass aber leider nicht mehr funktioniert, sobald man den externen Quarz nutzen möchte. Warum? Hat man erstmal im Programm auf externen Quarz umgestellt würde man durch die Betätigung des Tasters den Quarz "anhalten". Eine Verzweigung in den Bootloader würde nicht mehr stattfinden.
Harald, nein das ist so nicht richtig, der Bootloader startet nicht wenn du im laufenden Betrieb den Pin auf 0 legst das würde er übrigen auch nicht machen wenn du kein Quarz angeschlossen hättest. Es ist allerdings richtig dass der Quarz stoppen wird, wenn du den Taster betätigst. Der Loader kann auf 2 verschiedene Weisen gestartet werden. 1. Dein Flash ist leer (es werden die ersten beiden Bytes geprüft) 2. Dein Loader Pin ist aktiv Beides wird nur beim PowerOn Reset geprüft. Ist keine der Bedingungen gegeben wird ein SoftReset ausgelöst und die normale FW ab 0x0000 gestartet. Das og. ist etwas vereinfacht. Es werden ein paar mehr Bedingungen abgefragt. So ist es z.B beim CH559 mit v2.31 Loader auch möglich im Loadermode eine beliebige Addresse anzuspringen. Es gibt noch einen 3.Weg: Der Loader kann auch mit LJMP 0xF400 manuell aus der App gestartet werden. Dann gelten allerdings ein paar Einschränkungen. Es ist dann nicht möglich die Config Bits zu ändern.
Thomas Z. schrieb: > Es gibt noch einen 3.Weg: > Der Loader kann auch mit LJMP 0xF400 manuell aus der App gestartet > werden. Genau so wird es in der o.g. Firmware gemacht. Und das würde eben nicht mehr funktionieren. Ein Ausschnitt aus dem Main.c: while(1) { if(!(P4_IN & (1 << 6))) runBootloader(); processUart(); s = checkRootHubConnections(); pollHIDdevice(); } Kann man mit leben, aber schon sehr suboptimal. Die Designer des CH559 haben in der Hitliste der ungeeignetsten Pins den Rang 7 erreicht (vorher kommen nur noch GND, VDD33, VIN5, RESET, DM, DP). Aber nun soll es auch gut gewesen sein, ich habe die Augen schon genug gerollt. Ich weiß, dass nach einem Coldreset der interne Oszillator aktiv ist und damit der externe Quarz sozusagen kein Problem ist.
jetzt verstehe ich dich was du meinst. Du willst den gleichen Pin auch in der Mainloop zum Starten des Loaders benutzen. Das geht natürlich nur wenn kein ext. Quarz benutzt wird, da hast du recht. Noch ein Hinweis: Das manuelle Starten per App funktioniert bei neueren (anderen) Controllern sowieso nicht mehr (CH549 ev auch CH557/8) weil WCH den Bootloader Sektor im Appmode ausblendet. Den gleichen USB Core hat WCH übrigens auch im CH32F103 zusätzlich eingebaut was den F103 dann mit 2 USB Schnittstellen ausstattet, die extra Schnittstelle auch mit Hostmode. Leider sind die meisten WCH Chips momentan nicht zu bekommen.
Thomas Z. schrieb: > Du willst den gleichen Pin auch > in der Mainloop zum Starten des Loaders benutzen. Ja, das kann ich ausbauen, Update kann man auch mit dem Reset starten, kein Problem. Thomas Z. schrieb: > Leider sind die meisten WCH Chips > momentan nicht zu bekommen. Ja, bei LCSC.COM sah es etwas mau aus, das stimmt.
So, gerade ist ein weiteres Projekt auf Basis des CH552 fertig geworden, und zwar ein Display/IR Empfänger. (mit USB Schnittstelle, logisch) Für das Display habe ich versucht mich an die USB HID Definitionen zu halten, so dass es generisch bleibt. Der IR Empfänger wird über CDC/ACM angesprochen und versteht das "GIRS" Protokoll und sollte mit lirc und seinem "girs" treiber funktionieren. https://gitlab.com/amesser-group/electronic-devices/usb-hid-display Bei diesem Projekt bin zum ersten mal darüber gestolpert, das der sdcc standardmäßig nicht reentrante Funktionen erzeugt. Das hat mich ein paar Haare gekostet :-) Das öffnet dann auch gleich wieder eine Baustelle an meinem JTAG Adapter.
Andreas M. schrieb: > Bei diesem Projekt bin zum ersten mal darüber gestolpert, das der sdcc > standardmäßig nicht reentrante Funktionen erzeugt ja das ist aber bei Keil ganz genauso. Das liegt daran das Funktionsparameter wegen des begrenzten Stacks üblicherweise nicht über einen Stackframe angesprochen werden. Einer der Nachteile der MCS51 Architektur was C angeht.
ich habe meinen USB Midi Code, den ich hier schon mal gepostet hatte, überarbeitet und auch für den SDCC bereit gemacht. Wie erwartet ist der SDCC code etwa 20% größer. Das Projekt ist hier zu finden: Beitrag "Usb Midi Firmare für die WCH CH55x Controller"
Können die bezüglich Stromverbrauch / Batteriebetrieb bei STM8Ls halbwegs mithalten?
im Datenblat werden typisch 2 mA bei 775kHz und 6 mA bei 16Mhz genannt @3,3V Sleep: max 150µA bzw im besten Fall (alles abgeschaltet) 10µA. https://github.com/Blinkinlabs/ch554_sdcc/tree/master/documentation
Also gefühlt ziehen die schon relativ viel Strom. Gerade mit steigender Taktfrequenz. Ob man aus dem Deep Sleep mit alles Aus wieder rauskommt ohne den Reset zu ziehen... Dafür sind se halt nicht gemacht, auf meinen Boards sind Hauptverbraucher aber Andere, da fällt das nicht so ins Gewicht.
Thomas Z. schrieb: > ja das ist aber bei Keil ganz genauso. Das liegt daran das > Funktionsparameter wegen des begrenzten Stacks üblicherweise nicht über > einen Stackframe angesprochen werden. Einer der Nachteile der MCS51 > Architektur was C angeht. Nö, es wird ein Vorteil des MCS51 ausgenutzt, daß er viele Operationen direkt im RAM machen kann. Z.B. einen Schleifenzähler kann man mit "DJNZ Adresse" im RAM laufen lassen. RAM wird dadurch nicht gespart, nur eine Menge PUSH/POP. Damit wird der Code klein und schnell. Dazu wird ein Call-Tree erstellt und die benutzten lokalen RAM-Variablen der Funktionen überlagert. Reentrante Funktionen braucht man nur extrem selten, so daß es sich lohnt, nur diese mit dem Attribut "reentrant" zu versehen. Diese werden dann natürlich pushen und poppen, bis der Arzt kommt. Bei zeitkritischen Sachen kann es sich daher lohnen, diese Funktion einfach zu kopieren.
Harald schrieb: > Kann man mit leben, aber schon sehr suboptimal. Die Designer des CH559 > haben in der Hitliste der ungeeignetsten Pins den Rang 7 erreicht > (vorher kommen nur noch GND, VDD33, VIN5, RESET, DM, DP). Aber nun soll > es auch gut gewesen sein, ich habe die Augen schon genug gerollt. Ich > weiß, dass nach einem Coldreset der interne Oszillator aktiv ist und > damit der externe Quarz sozusagen kein Problem ist. Wollte nur mal berichten, dass die Umschaltung auf den externen Quarz beim CH559 ohne Probleme funktioniert. Ich hatte ja berichtet, dass ich beim USB-HOST Betrieb einen „richtigen“ Quarz für erstrebenswert halte. Der Boot-Taster hängt halt parallel mit am Quarzeingang XI - hmmmh ja, grummel, meinetwegen. Nebenbei: Beim Einstellen der Baudrate für die UART fühlt man sich direkt in die alten 8051-Zeiten zurückversetzt. Wie primitiv (und unflexibel) das damals war… man ja ist ja doch schon durch die 32bit Welt etwas verwöhnt.
Angehängte Dateien:
-
capture.png
310 KB
Ich habe vermutlich den ersten Ausfall des Flashs bei einem CH552 mit v2.31 Bootloader. Der Baustein hat m.M. die 200 Zyklen nur knapp überschritten bringt aber beim Verify bei manchen Hex Files nun einen Verify Error. Es ist so, dass wohl ein Bit in den ersten 0x3D Bytes sich nicht mehr auf 1 setzen lässt. Bei Chips mit V1.1 Loader ist mir das nie passiert. Das kann natürlich Zufall sein, ich habe aber den Verdacht dass dies auch mit der Art und Weise zu tun hat wie das Erase Cmd bei der v2.31 implementiert ist. Ein Hexfile mit 0x00 auf allen Adressen lässt sich ohne Fehler flashen, ein File mit 0xFF bricht mit verify error beim ersten Block ab. Zurückgelsen hab ich noch nicht. Im Anhang ein Bild mit dem Verify Request der den Fehler meldet.
Harald A. schrieb: > V-USB ist doch diese Software-Emulation eines USBs, richtig? Das hätte > für mich eh keinerlei Relevanz da meiner Meinung nach völlig obsolet. > ... V-USB ist zudem nicht mit USB 3.0 Controllern ohne dazwischen geschaltenen USB-Hub, der oftmals toleranter ist, kompatibel, wie ich mit einem DigiSpark ATTINY85 verifiziert habe. Der DigiSpark ATTINY85 geht mit der Arduino USB-Firmware, die ja auch auf V-USB basiert an keinem einzigen USB 3.0 Port bei drei verschiedenen Laptops (darunter ein Macbook Pro). Daher aus meiner Sicht jetzt obsolet - denn immer mehr Laptops/PCs haben keinen einzigen USB 2.0 Port mehr. Interssant wäre es, z.b. USB-ASP auf den CH552 zu portieren, weil es da 1) Billige fertige Devboards gibt 2) Der CH552 einen USB-Bootloader hat 3) Es einen freien C-Compiler (SDCC) gibt D.h. jemand, der das nachbauen will benötigt nichts anderes als das billige CH552G-Devboard. Ausserdem hätte ein Port von USBASP auch den Vorteil, dass die Chinesen wieder mit der Massenproduktion von USBASPs - diesmal USB 3.0 kompatibel - loslegen können ;) Was den CH552 betrifft - laut WCHISPTool habe ich bisher 57x geflashed im Laufe des "Shotgun-Debugging", ich habe noch 2 Devboards rumliegen... ;) Dass man den nur ca. 200x flashen kann ist auch bemerkenswert - viele PICs sind z.b. mit minimum 10k Zyklen spezifiert - d.h. das wird garantiert. Erinnert ein wenig an die sowjetischen Ziegelstein-EPROMs, die auch wenig zyklenfest waren ;) (Das->Dass)
Übrigens dürfte auch der CH9329 ("UART to HID keyboard/mouse/customized
HID IC, supports multiple working modes and serial communication modes")
ein CH552G oder ein CH551G sein, denn das Pinout ist identisch.
Hier gibt es den in Stick-Form
https://www.aliexpress.com/item/1005003679447698.html
Evtl. auch eine Alternative wenn CH55x nicht auf Lager ist?
TU Student 1. schrieb: > Interssant wäre es, z.b. USB-ASP auf den CH552 zu portieren, ich kenne USB-ASP nur vom hören sagen. Ein kurzer Blick in die Sourcen zeigt aber, dass das reines c ist. Nur der Usbtreiber selbst ist natürlich in ASM. Diesen mit einem passenden CH552 C code zu ersetzen dürfte kein allzu großes Problem sein. Ich bin allerdings kein AVR Freak kann also nur schlecht beurteilen wie das mit den Baudraten funktioniert. MCS51 Designs haben ja ein paar Limits was die Baudraten angeht. tpi.s könnte allerdings ein Problem werden. Wie sehen denn die Deskriptoren eines USB-ASP aus?
Ich habe jetzt keinen USBasp(-Clone) hier, aber hier sieht man den Descriptor und der passt auch mit dem Sourcecode aus usbconfig.h und der Tatsache, dass es kein HID-Device ist zusammen: https://www.avrfreaks.net/sites/default/files/llllll.JPG Es dürfte auch alles über den Control-Endpoint 0 laufen, wie es aussieht Der USBasp verwendet einen libUSB-Treiber um mit diesem Custom-USB-Device zu sprechen Meinst du UART-Baudrate? Die AVRs werden per SPI geflashed. Habe mit 8051 selbst eigentlich nie was gemacht, ausser das Tutorial auf 8052.com damals durchgearbeitet ...
TU Student 1. schrieb: > Es dürfte auch alles über den Control-Endpoint 0 laufen, wie es aussieht ok vermutlich geht die Kommunikation dann nur über Setup Vendor Calls wenn ich main.c richtig interpretiere. Das ist ziemlich einfach auf dem ch552 zu machen. Die restlichen c files sehen auch nicht besonders kompliziert aus. Bauchschmerzen würde mir wie gesagt das asm tpi modul bereiten. Es hat sicher einen Grund (Timming?) warum das nicht in C gemacht wurde. Fischl hat in seinem Schaltplan den Uart auf die Stiftleiste gelegt, dass ist aber ev nur zu debug zwecken. Ist es wirklich sinnvoll noch einen Programmer für die AVRs zu machen? Davon gibt es ja schon mehr als genug und wenn ich das richtig sehe jeder mit ganz eigenen Problemen. Ich hätte sogar einen Stick auf dem man das testweise frickeln könnte. Beitrag "Re: uC für 0,20€ CH552 / CH554 von WCH Billig Micro mit USB Funktion, Chip vorstellung"
Beitrag #6953725 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
wchasp.png
13 KB
TU Student 1. schrieb: > Interssant wäre es, z.b. USB-ASP auf den CH552 zu portieren, weil es da > 1) Billige fertige Devboards gibt > 2) Der CH552 einen USB-Bootloader hat > 3) Es einen freien C-Compiler (SDCC) gibt Ich hab da mal was gezeichnet :-) Da der CH552 nicht 5V tolerant ist braucht es Pegel Konverter. Die FW von Fischl habe ich mal testweise portiert (ohne TPI). Zusätzlich habe ich die Deskriptoren erweitert um ein zusätzliches CDC Device unterzubringen. Es gibt wie beim Original einen Speed Jumper so wie die Umschaltung 5V/3.3V. Der CH552 enumeriert als Fullspeed Device. Mit eigener Software könnte man damit auch einen universellen SPI Flasher realisieren.
Zwei Anmerkungen/Fragen zum Schaltplan: 1) Die Kathode der Doppeldiode D3 hängt fest auf 3,3V (oder 3V?). Die würde ich aber eher auf den mittleren Pin (Pin 2 vom "Power-Selector"-Jumper) setzen, damit bei Betrieb mit 5V die Kathode dann auch auf 5V hängt. Oder liege ich da falsch? 2) Wieso ist der CH552G nicht "5V tolerant", wie du schreibst? Wäre es nicht einfacher und könnte man nicht den Levelshifter sparen, wenn man den ganzen Controller einfach mit der Zielspannung versorgt? Gruß Thomas
Thomas T. schrieb: > Wieso ist der CH552G nicht "5V tolerant" um ganz ehrlich zu sein, ich weis es nicht genau, meine aber sowas mal gelesen zu haben, kann dazu aber nichts finden. Es ist allerdings so dass die Port Pins nur auf 3.3V hoch gehen, auch wenn der Chip mit 5V versorgt wird. Der Treiber ist vermutlich nicht notwendig, ich hab den zur Sicherheit mal vorgesehen. Den CH552 umzuschalten ist nicht so ganz einfach, da der V5 Pin im 3.3V Betrieb mit mit dem V3.3 Pin verbunden werden muss und dann mit 3.3V versorgt werden muss. Zusätzlich sind im 3.3V Betrieb nur noch 16MHz erlaubt, da könnte es problematisch werden 115k2 Baud zu erreichen. Das müsste ich noch mal nachrechnen. Ich habe bisher mit 24MHz geplant. Die Doppeldiode soll die zwei Eingangssignale fest auf 3.3V klemmen, da ich den internen Schutzdioden nicht traue.
Ich bin da auch nicht 100% sattelfest, man möge mich verbessern, falls notwendig... Thomas Z. schrieb: > Es ist allerdings so > dass die Port Pins nur auf 3.3V hoch gehen, auch wenn der Chip mit 5V > versorgt wird. Das Datenblatt sagt bei VOH5 (High level output voltage (output current 8mA)): Minimum: VCC-0,4V Da sollte also etwas zwischen 4,5V und 5,0V zu messen sein... Thomas Z. schrieb: > Zusätzlich sind im 3.3V Betrieb nur noch 16MHz > erlaubt, da könnte es problematisch werden 115k2 Baud zu erreichen. Das > müsste ich noch mal nachrechnen. Ich habe bisher mit 24MHz geplant. Oh, bei 3,3V nur 16MHz erlaubt? Dann wird das wohl nichts mit direktem Betrieb mit 3,3V. Du brauchst doch die 24MHz, aus denen dann 48MHz für die USB-Schnittstelle erzeugt werden... Im Datenblatt habe ich aber dazu auch nicht wirklich was gefunden... Gruß Thomas
Thomas Z. schrieb: > Ich habe vermutlich den ersten Ausfall des Flashs bei einem CH552 Ich hatte bei JLCPCB ein paar Platinen mit dem CH559 bestücken lassen. Eine Platine davon lässt sich überhaupt nicht ansprechen. Ich habe alles mögliche geprüft, es müsste der Controller sein. Leider kann ich ihn nicht tauschen, da ich keinen einzelnen CH559 habe. Die Frage ist jedenfalls, ob sonst schon jemand einen Controller aus dieser Familie hatte, der es von vornherein nicht tat.
Thomas T. schrieb: > Du brauchst doch die 24MHz, aus denen dann 48MHz für > die USB-Schnittstelle erzeugt werden... nein der USB Clock ist unabhängig von Fsys. Fullspeed geht ab 3MHz Lowspeed ab 1.5MHz. Bei mir hat USB nicht mehr funktioniert wenn ich auf 32MHz gestellt habe, Das ist aber sowieso nicht spezifiziert.
Harald A. schrieb: > Die Frage ist jedenfalls, ob sonst schon jemand einen Controller aus > dieser Familie hatte, der es von vornherein nicht tat. Prüfe den Reset Pin auf Lötfehler / Kurzschluss. Der hat bei mir wegen eines Schaltungsfehlers anfangs einen Start verhindert.
Thomas T. schrieb: > Das Datenblatt sagt bei VOH5 (High level output voltage (output current > 8mA)): Minimum: VCC-0,4V ok gerade noch mal nachgemessen, Es sind so knapp 4V an den Ports (x51 mode)
Thomas Z. schrieb: > erlaubt, da könnte es problematisch werden 115k2 Baud zu erreichen. Das > müsste ich noch mal nachrechnen. Ich habe bisher mit 24MHz geplant. Für 115k2 Baud brauchst du auf jeden Fall 24MHz. Sonst passt der Teiler nicht und das UART Timing ist kaputt. Hab ich schon auspropbiert.
Angehängte Dateien:
-
wchasp1.png
25 KB
Andreas M. schrieb: > Für 115k2 Baud brauchst du auf jeden Fall 24MHz. Sonst passt der Teiler > nicht und das UART Timing ist kaputt. Hab ich schon ausprobiert. Danke, so ist auch mein Wissensstand. Ich hab nur noch nie ausgerechnet ob 115k2 auch bei 16MHz zu erreichen sind, Bei 24 MHz ist der Fehler ja schon bei 3%. Ich hab mal eine Platine zu dem Schaltplan gemacht. Die Doppeldiode ist noch drin kann man aber problemlos weglassen.
Aaron C. schrieb: > CH552 oder CH554. Ganz spannende Teile nur anscheinden sind die auch schon schwer verfügbar. Also wenn schon die Teile kaum noch zu besorgen sind geht die Welt wirklich unter 😂 Oder ich habe falsch geschaut 🙄
Max M. schrieb: > Oder ich habe falsch geschaut 🙄 hast du nicht LCSC listet fast alle mit 0 Bestand (bei 3fachem Preis). Das ist jetzt schon ein Jahr so. Man kann die Teile wohl momentan nur bei WCH direkt bekommen. Ich habe keine Ahnung was für Stückzahlen da verfügbar sind.
Ich seh mich schon Nachts in der Wertstoffhof einbrechen, um die E-Schrott Kisten zu plündern, wenn das so weitergeht :-/
Max M. schrieb: > Ich seh mich schon Nachts in der Wertstoffhof einbrechen, um die > E-Schrott Kisten zu plündern, wenn das so weitergeht :-/ Für meine Basteleien reicht mein Vorrat. Ich benutze den Lagerbestand bei LCSC als Indikator. Wenn die Teile wieder in Stückzahlen verfügbar sind ist vermutlich die Chipkrise vorbei. :-)
Weitere WCH Module, die man zweckentfremden kann (z.b. hier mit dem CH549): WAVGAT Wchlink Mini HC594F Daplink supports a full range of ARM core chips/Qinheng RISC-V chips 3.3V /5V https://www.aliexpress.com/item/1005003615324166.html? 1 Stk. um 4,83 EUR inkl. Versand Kleines Board das aussieht wie ein ISP-Dongle. WCH link download debugger risc-v framework MCU online debugging SWD interface chip programming https://www.aliexpress.com/item/1005003482789318.html 3 Stk. um 14,59 EUR (= pro Stk. 4,86 EUR) Billigstes Board mit Gehäuse und USB-C WCH-Link emulator download the debugger rISC-V ARM online SWD TTL serial port TYPE-C https://www.aliexpress.com/item/1005002795462484.html 1 Stk. um 3,64 EUR inkl. Versand 3 Stk. um 7,40 EUR inkl. Versand (= pro Stk. 2,46 EUR) Diese Module hat möglicherweise alles drauf um einen ISP/ICSP/... zu realisieren und basieren auf dem CH549, der mehr Features hat (Host Mode, mehr Flash, Temperatursensor (!), ...) Den CH548 (kleineres Modell) gibt es sogar im SOIC8 (SOP8). Wow!
den CH552T ( TSSOP-20 package ) gibt es noch hier: https://www.shotech.de/de/ch552t-e8051-core-mcu.html der CH552G ( SOP-16 package ) ist da leider auch ausverkauft :(
es gibt wohl einen neuen Bootloader v2.5. Zumindest gibt es bei WCH dazu einen Thread. Wenn ich die Übersetzung richtig verstanden habe, ist der kaputt. oder das ISP Tool macht bei der Version murks. THIS YEAR'S NEWLY ACQUIRED CH552G CHIP WCHISP READ OUT ALL THE SAME ID, RESULTING IN THE FAILURE OF THE ORIGINAL FIRMWARE FUNCTION read it all out and that's it 17:47:15:052>> 0#ISP DEV:94-12-00-00-00-00-00-00 17:47:15:055>> UID:94-12-00-00-00-00-00-00,BTVER:02.50 cause the original firmware to be abnormal replaced by the old chip everything is normal, what is the situation?
Thomas Z. schrieb: > there seems to be a new bootloader v2.5. At least there is at WCH > to do so > a thread. If I understood the translation correctly, it is > broken. or the ISP tool messes up the version. > > THIS YEAR'S NEWLY ACQUIRED CH552G CHIP WCHISP READ OUT ALL THE SAME ID, > RESULTING IN THE FAILURE OF THE ORIGINAL FIRMWARE FUNCTION > > read it all out and that's it > 17:47:15:052>> 0#ISP DEV:94-12-00-00-00-00-00-00 > 17:47:15:055>> UID:94-12-00-00-00-00-00-00,BTVER:02.50 > > cause the original firmware to be abnormally replaced by the old chip > everything is normal, what is the situation? Are you the usbman in the wch official forum? I got a few extra 2.5.0 ch552 boards. If you want some, my contact can be found on my GitHub profile (author of ch55xduino). Send me an email with your address and I can mail you 2 boards from US.
ich hab mal wieder mit dem CH552 rumgespielt. Dabei hab ich mich insbesondere mit den Clocks und Powermodes beschäftigt. Folgendes ist mir aufgefallen: 1. man kann den Core mit 32MHz takten USB geht dann allerdings nicht. Damit ist SPI mit 16MHZ möglich 2. Alle diese CH55x chips besitzen kein IDL bit in PCON. Schade, denn dieses Bit ist schon immer im x51 drin gewesen 3. Bootloader via Reset Pin. Man kann den Reset Pin CLOCK_CFG abfragen auch wenn der ext Reset nich aktiviert ist. Ich benutze das momentan um auch über den Reset Button beim PwrOn in den Loader zu springen. 4.ds_user hat mir vor einiger Zeit 2 ch552 mit V2.5 loader zur Verfügung gestellt. Soweit ich sehen kann springt der Loader nun nach einem Timeout automatisch nach 0x000. Das Disassembly kommt demnächst
Wie versprochen erst mal die V2.5 als Intel Hex. Ich hab auch schon ins Disassembly geschaut: Es entspricht weitgehend der V2.4 die ich schon mal gepostet hatte. Dazugekommen ist lediglich eine Timeout Abfrage um automatisch den SoftReset auszulösen. Dadurch ist die main etwas umfangreicher. WCH hat übrigens gemerkt, dass die rand() Funktion vollkommen sinnlos war, die ist nun weg. Vermutlich haben die einfach den Speicherplatz gebraucht. Zusätzlich ist die Position von main() im Addressraum verschoben. Source folgt sobald die ASM Datei ordentlich formatiert ist. Ausgelesen hab ich den Loader mit meinem (modifizierten) freader und einem V1.1 fakeloader ab 0x3000 da ja das Auslesen seit 2.4 nicht mehr funktioniert. Dabei habe ich auch den Grund enddeckt warum der freader bei manchen Leuten nicht funktioniert: Es liegt ganz einfach an der ch375dll.dll die ja beim Installieren des WCHIspTools im Win Verzeichnis abgelegt wird. Davon gibt es unterschiedliche Versionen. Fixen lässt sich das wenn meine DLL im gleichen Verzeichnis wie der freader liegt.
Thomas Z. schrieb: > Source folgt sobald die ASM Datei ordentlich formatiert ist. Ja, bitte. Der Source interessiert mich insofern, da ich inzwischen der Überzeugung bin, dass die in der Firmware enthaltene "c runtime memcpy"-Routine fehlerhaft ist... Und zwar wird in dieser Routine nach rund 7-8 Befehlen ein 16Bit-Pointer inkrementiert (im boot_v2.asm steht dort "RAME/F++"). Allerdings wird das High-Byte dort erst geladen und dann wird verglichen, ob das Low-Byte nach dem Inkrementieren 00h ist, also ein Übertrag stattfand. Wenn dies der Fall sein sollte, wird zwar das High-Byte ebenfalls inkrementiert, jedoch nicht mehr geladen. Als Ergebnis enthält der (geladene) Pointer dann beispielsweise folgende Werte: 03FDh, 03FEh, 03FFh, 0300h(!), 0401h, 0402h, 0403h Auswirkungen hat das aber wohl keine, weil die Routine zur Zeit wohl nicht über Page-Grenzen kopieren muss... Gruß Thomas EDIT: Habe mir den Hexdump mal auf die Schnelle angeschaut: Sieht so aus, als wenn sich nur der Pointer von "RAME/F" nach "RAMD/E" verschoben hat, aber sonst die Befehle gleich sind. Der Fehler ist da wohl immer noch drin...
Thomas T. schrieb: > Überzeugung bin, dass die in der Firmware enthaltene "c runtime > memcpy"-Routine fehlerhaft ist... dazu muss ich sagen runtime stimmt nicht.. Keils memcpy Funktion ist deutlich umfangreicher. Die genannte Funktion ist handgeschrieben. Es sind nur noch 2 Keil Runtime Funktionen drin (Original Namen ?C?CLDPTR und ?C?CSTPTR) Das main Programm ist etwas komisch bei der Auswertung der HW contitions. Die werten das 2 mal aus. Das hab ich noch nicht verstanden. Ich bin aber der Meinung dass der Sprung nach Boot beim PowerOn nicht mehr so zuverlässig funktioniert. Zusätzlich überschreiben Sie an einer Stelle den Timer0 mode der zuvor auf Mode 1 gestellt wurde mit Mode 0 -> mov TMOD, #0x20. Timer 0 wird für den Timeout benutzt. Das hat wohl auch keine Auswirkungen. Viele Änderungen gibts im Serial Dispatcher. Da bin ich noch nicht durch Ich kann zwar schon fehlerfrei übersetzen allerdings noch nicht binärgleich da ich die Änderungen in meine Sourcen reinpflege. Weil der BootStart unzuverlässig auf der weact hw funktioniert starte ich den Loader momentan per Abfrage des Reset Pins.
Thomas T. schrieb: > Allerdings wird > das High-Byte dort erst geladen und dann wird verglichen, ob das > Low-Byte nach dem Inkrementieren 00h ist, also ein Übertrag stattfand. das ist schon richtig so der Keil Compiler ist big Endian sprich Hi Byte kommt vor Low Byte.
Aaron C. schrieb: > Heißt also der CH551 kann als Slave USB Gerät irgendwo angeschlossen > werden wie Maus, Tastatur oder USB Stick an einen PC o.ä. Könnte man auch MIDI-Controller anschließen?
Audiomann schrieb: > Könnte man auch MIDI-Controller anschließen? nur bei Chips die auch den Hostmode unterstützen, aslo ab CH554. CHhh1 und CH552 unterstützen nur USB Device mode
Thomas Z. schrieb: > dazu muss ich sagen runtime stimmt nicht.. Keils memcpy Funktion ist > deutlich umfangreicher. Die genannte Funktion ist handgeschrieben. In c würde die memcopy Funktion etwa so aussehen, da WCH generische ptr verwendet:
1 | void mem_cpy (uint8_t *dest,uint8_t *src,uint8_t len) |
2 | {
|
3 | while(len--) *dest++ = *src++; |
4 | }
|
Beim Keil wird der erste param wird via R1..R3 übergeben, die anderen Params über Speicherstellen. Effektiver wäre folgende Variante:
1 | void mem_cpy (uint8_t xdata *dest,uint8_t code *src,uint8_t len) |
2 | {
|
3 | while(len--) *dest++ = *src++; |
4 | }
|
dann würden alle params per Register übergeben und der Compiler würde dann die beiden ptr funktionen weglassen. Bei dieser Variante könnte man auch sehr gut den extra op code verwenden. Der Unterschied zum memcpy aus der lib ist, dass len nur 8 bit breit ist. https://github.com/usbman01/Replacement-WCHs-debug.c/blob/main/ch544/src/misc/fastccopy.a51 zeigt die Implementierung als Keil ASM Modul. für SDCC hab ich das bis jetzt noch nicht geschafft da ich noch nicht verstanden habe wie die Parameter Übergabe funktioniert.
Thomas T. schrieb: > Ja, bitte. Der Source interessiert mich insofern, da ich inzwischen der > Überzeugung bin, dass die in der Firmware enthaltene "c runtime > memcpy"-Routine fehlerhaft ist... > > Und zwar wird in dieser Routine nach rund 7-8 Befehlen ein 16Bit-Pointer > inkrementiert (im boot_v2.asm steht dort "RAME/F++"). Allerdings wird > das High-Byte dort erst geladen und dann wird verglichen, ob das > Low-Byte nach dem Inkrementieren 00h ist, also ein Übertrag stattfand. > Wenn dies der Fall sein sollte, wird zwar das High-Byte ebenfalls > inkrementiert, jedoch nicht mehr geladen. Ich glaube, da muss ich mich selbst korrigieren. Ich habe mir die Routine jetzt nochmal ganz ganz genau angesehen und Befehl für Befehl nachverfolgt. Die Routine inkrementiert zwar den Pointer, in R1 und R2 soll aber der alte Wert (also der nicht inkrementierte Wert) stehen. Und das macht die Routine auch so. Ich lag da also falsch und bitte um Ignorieren meines vorherigen Beitrags... Gruß Thomas
hier nun der Source Code des V2.5 loaders. Das ganze sollte sich auch mit der Demo Version des Keils übersetzen lassen, da es ein absolutes File ist und nicht aus mehreren Modulen besteht. Ich habe den Overlay Speicher etwas umbenannt. Das übersetzte File ist binärgleich zum ausgelesenen Original. Ach ja: viele Adresslabel entsprechen nicht (mehr) der Realität weil ich das Ding aus den v2.31 Sourcen abgeleitet habe. Ich war da einfach zu faul die alle zu korrigieren. Das ist aber kein wirkliches Problem.
Thomas Z. schrieb: > here is the source code of the V2.5 loader. The whole should also > with the demo version of the wedge, since it is an absolute > File is and does not consist of several modules. > I renamed the overlay memory a bit. The translated file is > binary equal to the read original. > > Oh yes: > many address labels do not (any longer) correspond to reality because I > Thing derived from the v2.31 sources. I was just too lazy > to correct all of them. But that's not a real problem.
1 | mov __addr, A ; if (????) cmdbuffer[3]--; |
2 | anl A, #3 |
3 | orl A, __addr+1 |
4 | jnz code_39C3 |
This should means if ((addr & 0x3FF) == 0) cmdbuffer[3]--;
Thomas Z. schrieb: > here is the source code of the V2.5 loader. The whole should also > with the demo version of the wedge, since it is an absolute > File is and does not consist of several modules. > I renamed the overlay memory a bit. The translated file is > binary equal to the read original. > > Oh yes: > many address labels do not (any longer) correspond to reality because I > thing derived from the v2.31 sources. I was just too lazy > to correct all of them. But that's not a real problem. Also
1 | JumpFunction3: ; delete rom page |
2 | mov A, cmdbuffer+3 ; if (cmdbuffer[3] > 8) break |
3 | clr C |
4 | subb A, #8 |
5 | jnc code_399A |
6 | Xjmp FuncBreak |
This should be if (cmdbuffer[3] < 8) break I tried to set cmdbuffer[3] to different values in vnproch551. Any value less than 8 will case a "Packet 0 doesn't match." error.
ds_user schrieb: > I tried to set cmdbuffer[3] to different values in vnproch551. Any value > less than 8 will case a "Packet 0 doesn't match." error. if i remember correctly funcion3(DeleteTomPage) before did just delete 1 or 2 pages in v2.31 now they delete 8 pages starting from v2.4. Basically using the verify cmd does not work any longer as before. After the first mismatch a error flag is set which just get reset with the delete cmd
TU Student 1. schrieb: > Der DigiSpark ATTINY85 > geht mit der Arduino USB-Firmware, die ja auch auf V-USB basiert an > keinem einzigen USB 3.0 Port bei drei verschiedenen Laptops (darunter > ein Macbook Pro). An meinem Linux Laptop mit USB-3.0 Anschlüssen läuft der DigiSpark einfach so, ohne Tricks.
Es gibt von WCH nun auch offiziell englische DBs. Da findet wohl gerade ein Umdenken statt. http://www.wch-ic.com/downloads/CH554DS1_PDF.html http://www.wch-ic.com/downloads/CH559DS1_PDF.html
Patrick ist da auch hinterher und lässt mit sich reden :) : https://twitter.com/Patrick_RISCV?t=oGbuaci48ZEGl8nVCGqeGg
Helfen Sie mir, Antworten auf Fragen wie diese über CH552 zu finden: - Wo kann ich die Bibliothek für PROTEUS finden? - Welche Speichergröße benötige ich für das HID KBD-Programm? Ich möchte einen USB-Stick erstellen: Es gibt zwei Tasten als Berührungssensor und zwei LEDs. Taste 1 sendet eine Zeichenfolge von 10 Zeichen und schaltet die LED 1 ein. Taste 2 sendet eine Zeichenfolge von 16 Zeichen und schaltet die LED 2 ein. Ich plane, ein KEIL 51 zu verwenden. Wenn ich Erfolg habe, werde ich versuchen, ein EEPROM + i2c-Display hinzuzufügen.
Zur Info: Mir ist grad aufgefallen, das WCH jetzt selbst ein Englisches Datenblatt für den CH552 anbietet: http://www.wch-ic.com/downloads/CH552DS1_PDF.html
Heute habe ich mal ein bisschen mit der PWM gespielt. In der Dokumentation wird das PWM_CK_SE ja leider nicht detailliert beschrieben. Meine Experimente haben ergeben, das man mit PWM_CK_SE ein Taktteiler von 1 bis 256 für die PWM konfigurieren kann. - PWM_CK_SE := 0 -> PWM_CK = FSYS/256 - PWM_CK_SE := 1 -> PWM_CK = FSYS/1 - PWM_CK_SE := 2 -> PWM_CK = FSYS/2 - .... Bei 12MHz FSYS und PWM_CK_SE := 1 ergibt sich somit eine Grundfrequenz von 46.9kHz am PWM Ausgang (1/Periode) Hintergrund ist, das ich gerade an einem UPDI Programmer mit HV Support arbeite und die beiden PWMs als Ladepumpe für die HV benutzen möchte. Im Leerlauf komme ich jetzt so auf knapp 18V. Reichlich übers Ziel hinaus :-)
Moin zusammen, hab mal mit dem Keyboard-Beispiel von CH55xDUINO rumgespielt. Dabei ist ein einfaches IO-Interface rausgekommen, welches das K8055 Protokoll nachahmt. Darüber hinaus habe ich noch mit WebHID rumgespielt, um das K8055 in P5.js nutzen zu können. Leider funktioniert das nur mit Chrome und Edge, da Firefox WebHID nicht unterstützen möchte. Gruß, SIGINT
Ich habe heute relativ viel Zeit mit Fehlersuche bei meiner CDC Implementierung verbracht. Ich benutze den EP3 mit Double-Buffer Mechanismus. Dabei ist mir ein Problem aufgefallen: Wenn ich den Puffer bis zum Maximum von 64 Byte befülle und die Transmission freigebe, dann kommt auf der PC Seite nichts an und es geht nicht mehr weiter, der Transfer wird anscheinend nicht durchgeführt. Wenn ich nur bis 63 Byte befülle dann funktioniert alles wie erwartet. In der Empfangsrichtung geht es problemlos bis 64 Byte. Ich habe verschiedene Dinge ausprobiert um Fehler in meiner Implementierung auszuschließen. Falls jemand drüber schauen möchte, hier ist der Code, sobald man aus der 63 eine 64 macht gehts schief: https://gitlab.com/amesser-group/electronic-devices/usb-updi-hv/-/blob/master/firmware/usb_cdc.c#L267 Ich bin da mit meinem Latein am Ende, hake das jetzt erstmal als Hardware-Fehler ab.
Andreas M. schrieb: > ch bin da mit meinem Latein am Ende, hake das jetzt erstmal als > Hardware-Fehler ab. das ist kein HW bug wenn du genau 64 Bytes sendest und hinterher nichts mehr kommt gibt es einen timeout. Bulk ist dazu gedacht fortwährend 64 Byte Pakete zu übertragen. In USB Terms < 64 bytes sind Shorttransfer (automatisch terminiert) = 64 Bytes braucht ein ZLP um das Ende zu erkennen > 64 Bytes ist ein 64 Byte Transfer + Rest Das war auch beim Code von W.S. lange ein Problem.
Thomas Z. schrieb: > In USB Terms > < 64 bytes sind Shorttransfer (automatisch terminiert) > = 64 Bytes braucht ein ZLP um das Ende zu erkennen Danke für die Rückmeldung. Wieder was gelernt - wobei ich ne schwache Ahnung im Kopf habe das schon mal gewusst zu haben. Mal sehen obs diesmal länger hängen bleibt. :-)
Hello, I'm new here, sorry if I'm doing something wrong. Recently I bought a Bios programmer from AliExpress that works with several NOR chips. It's called XP866+, it uses the CH552G, it works really fine, and the software is attached. I'm posting here so everyone knows that CH552G can work this way, and we can develop a better software or discover different usage for it. I downloaded the android app "CH55x programmer v2 1.8" and tried to dump, but my device always "reset" after I accept the permission. I don't know if it's because of a 47 ohm resistor I added to Pin8 of the NOR chip (that I'm going to program with it) to reduce the voltage and to get exact 3.3v. I haven't done other modifications to the board, so if something else is required, please tell me. The original XP866+ software is not ready to program NAND chips, and I don't know exactly how to add new chips to the database, being sure they will work well.
Barzotto T. schrieb: > that I'm going to program with it) to reduce the voltage and > to get exact 3.3v. I haven't done other modifications to the board, so > if something else is required, please tell me. Please post a picture of the pcb. Firmware dumps just work for bootloader v1.1 and v2.31. You may check bcdVer field of der Device Descriptor in bootloader mode. if you got 2.4 or 2.5 there is currently no way to dump it. I am working on a HW sollution for dumping all the CH55x and CH54X chips but thats still not ready.
Angehängte Dateien:
-
XP866__PCB_Front.jpeg
390 KB -
XP866__PCB_Back.jpeg
200 KB
I'm not familiar with CH552G, but as I mentioned, the device "Run" green LED blinks quickly and "reset" every time I accept the permission in my smartphone, I can't do anything in the app. If I can check it using Windows, tell me how. There go front and back pictures with NOR pins identified.
well in order to use the android software the WCH Chip has to enter the bootloader mode first. For entering the bootloader you need to add a 4.7k .. 10k from D+ to VBus. You may use that 2 free pads for that. The resistor connection is tested only on power up and if found bootmode is entered. This also means for normal operation you have to remove it. As mentioned dumping will work only for old chips (old loaders) LEDs are dont care here. Anyway what are you planning to do with the dump? Any modification might need a lot of knowledge and you need to sniff the usb traffic of the original software. Such a thing is nothing for rookies
I was planning to upload the dump here, so anyone with a CH552G flashed with my dump and the correct wiring could use it for the same purpose I currently use, that is NOR programming, to repair motherboards with corrupt bios. This seems a lot better than CH341A (the most famous cheap NOR programmer), supporting newer models. And maybe it's not required to modify the dump, but if someone wants to analyze the software I uploaded, it would be great to modify it to flash NANDs with it. There are versions of NeoProgrammer that can flash NAND with CH341A, I tested them and they work.
I don't think it's worth the efford. Adding chips is just a matter of software because you only need a SPI or a I2C interface. Using the CH341 is probably the easiest method.
Für ein USB Host Projekt habe ich mir via Amazon ein Paar CH559T (SSOP20) beschafft. Beim Testen habe ich erst mal keine Verbindung zum Bootloader bekommen, die Teile stellten sich einfach tot. Das sollte nicht passieren, da der Bootloader bei leerem Flash automatisch starten sollte. Das dachte ich zumindest bis heute :-) Nach einigen Tests habe ich dann P4.6(XI) auf Masse gelegt und siehe da der Loader hat sich gemeldet. Es stellte sich heraus dass der Loader eine V2.0 Version ist. Der unterstützt weder Autostart bei leerem Flash noch das Aktivieren via D+. Beim Flashen mit dem WCH Tool kommt immer ein Verify Error im letzten Block. Das ist in Bug im ISP Tool und wird laut WCH nicht mehr gefixt da die V2.0 nicht mehr unterstützt wird. Man hat mir also uralte Teile angedreht. Es gibt also mindestens einen Händler der veraltete Chips verkauft. Ich habe dann den Bootloader disassembliert und einige ungewöhnliche Dinge gefunden. 1. Der 2.0 Loader benutzt das V1.1 Kommando Interface. 2. Der Loader benutzt Interrupts (serial, usb, T0) 3. Es gibt tatsächlich keinen Test auf leeres Flash 4. Die Benutzung von D+ als Bootpin ist im Loader nicht vorgesehen Lustig ist, dass der Loader Interrupts verwenden kann. Ich war bisher der Meinung dass nur der Reset Vector beim Power ON gemappt wird. Tatsächlich werden wohl auch die Interrupt Vektoren gemappt, sonst würden die Interrupts bei 0xF4xx ja nicht funktionieren. Da der Loader den ICALL unterstützt kann man ev das Ding auf V2.31 updaten.
Angehängte Dateien:
-
usbasp_sch.png
11 KB -
usbasp_pcb.png
22 KB
Hier ein kleines Projekt für die dunkle Jahreszeit: Das soll ein usbASP Clone werden da ich immer mal wieder Probleme habe das Original an neuen USB Ports stabil ans laufen zu bekommen. Zuverlässig funktioniert das nur wenn ich einen Hub benutze. Ich vermute stark dass die USB Emulation auf dem Atmel Timming Probleme mit neuen USB Ports (USB3.2) hat. Die Schaltung orientiert sich im wesentlichen am Original von Fischl. Die Versorgung kann zwischen 5V und 3.3V umgeschaltet werden. Für die FW plane ich ich die Nutzung von WCID zur automatischen Treiberinstallation und später zusätzlich ein CDC Interface. Da AvrDude wohl Probleme mit Compound Devices hat, muss man das wohl umschaltbar machen. Die Quellen lassen sich sowohl mit Keil als auch mit SDCC übersetzen und wird auch unter Projekte bereitgestellt werden. Die Sourcen sind weitgehend an den CH552 angepasst lediglich lediglich TPI braucht noch etwas Arbeit weil ich nicht so sattelfest in AVR Assembler bin. Das ist übrigens auch ein Grund für dieses Projekt. Ich will mich intensiver mit den AVRs beschäftigen. Vorstellbar ist eine Nutzung auch als SPI bridge.
Angehängte Dateien:
-
AvrDude_test.png
250 KB
Ich kann mich mit AVRDude schon mal auf den Controller verbinden. Lesen funktioniert schon. Schreiben hat noch ein paar bugs. Für SDCC muss ich noch ein paar defines anpassen. Das CDC Interface wird erkannt funktioniert aber noch nicht weil der Code für die beiden Bulk Eps noch nicht eingebaut ist. Als Codebasis habe ich den code von nerdralph genommen https://github.com/nerdralph/usbasp allerdings ohne die function pointer in spi.c weil das in Keil nicht so toll funktioniert. usbdrv.c ist meine eigene Kreation. TPI ist noch abgeschaltet Falls jemand testen will, ich kann ein paar Sticks verschenken. (quasi ein kleines Weihnachtsgeschenk :-) )
:
Bearbeitet durch User
Angehängte Dateien:
Travis Goodspeed hat den CH552 Flash dumper in seinem neuesten Buch "Microcontroller Exploits" erwähnt
Aaron C. schrieb: > Travis Goodspeed hat den CH552 Flash dumper in seinem neuesten Buch > "Microcontroller Exploits" erwähnt Da sieht man wie sich dank online Übersetzer sowas heute verbreitet. Ich glaube übrigens einen Weg gefunden zu haben auch beim V2.4 und v2.5 Loader die Chips auszulesen. Das ist aber wesentlich aufwendiger. Das ist aber noch nicht fertig.
:
Bearbeitet durch User
Max M. schrieb: > einen USB-Stick "vorgaukeln" Wird eng mit nur 16KB Flash und 1KB XRAM. USB Mass Storage basiert auf SCSI, da kommt einiges an Code zusammen bis das läuft. Geschwindigkeit ist egal, USB kann sich anpassen.
so mein usbASP Klon funktioniert nun stabil. Lesen und schreiben ist ok. Ich erreiche damit auf dem Arduino Uno bis zu 6.5kB/s Schreibgeschwindigkeit bei einem SPI Clk von 1.5 MHz. Das dürfte noch etwas besser werden wenn ich EP0_SIZE von 8 auf 64 ändere. Keine Ahnung wie das auf dem Original war, da mein Fischl usbASP hier nur sehr unzuverlässig funktioniert. Der Fehler beim Schreiben war simpel. Ich hatte den USB Data Toggle für Schreib Operationen nicht richtig programmiert. Es ist das erste Mal, dass ich Data out Stages mit mehreren Transfers benutze. Ich tue mich noch etwas schwer mit dem TPI Modul. Da könnte ich Hilfe von einem AVR Programmierer brauchen. Für mich ist die Portprogrammierung mit den diversen Betriebsarten der Ports in AVR asm etwas undurchsichtig.
Hallo Thomas, dein usbasp-Klon funktioniert prima:
1 | Processing -U flash:w:MultiIO.hex:i |
2 | Reading 10694 bytes for flash from input file MultiIO.hex |
3 | Writing 10694 bytes to flash |
4 | Writing | ################################################## | 100% 1.93s |
5 | Reading | ################################################## | 100% 1.75s |
6 | 10694 bytes of flash verified |
7 | |
8 | Processing -U efuse:w:0xFF:m |
9 | Reading 1 byte for efuse from input file 0xFF |
10 | Writing 1 byte (0xFF) to efuse, 1 byte written, 1 verified |
11 | |
12 | Processing -U hfuse:w:0xD9:m |
13 | Reading 1 byte for hfuse from input file 0xD9 |
14 | Writing 1 byte (0xD9) to hfuse, 1 byte written, 1 verified |
15 | |
16 | Processing -U lfuse:w:0xFF:m |
17 | Reading 1 byte for lfuse from input file 0xFF |
18 | Writing 1 byte (0xFF) to lfuse, 1 byte written, 1 verified |
19 | |
20 | Avrdude done. Thank you. |
Und vor allem: Der ist total stabil selbst bei der Versorgung des Targets. Mein China usbasp-Klon fliegt ständig aus dem USB raus wenn ich ein mit dem usbasp-Klon versorgtes Target anstecke. Dein Klon macht da keinen Mucks!
:
Bearbeitet durch User
Jochen D. schrieb: > dein usbasp-Klon funktioniert prima: danke für deine Rückmeldung. Ich hätte noch ein paar Fragen: - Welche Version von avrdude benutzt du? - Welche Atmel Controller hast du geflasht? - Hat es bei dir sofort funktioniert (ohne Treiber Install)
> - Welche Version von avrdude benutzt du? avrdude 8.0 > - Welche Atmel Controller hast du geflasht? Atmega324PB > - Hat es bei dir sofort funktioniert (ohne Treiber Install) Jain. Habe meine Software aber auch in einer VirtualBox. Da wurde der Programmer zuerst nicht erkannt. Schiebe das aber auf die VirtualBox ;) Treiber waren vom China-usbAsp-Klon schon vorher installiert.
Thomas Z. schrieb: > Ich tue mich noch etwas schwer mit dem TPI Modul So das tpi modul ist nach c umgesetzt. Testen kann ich das im Moment nicht, da ich keinen passenden AVR habe. Zumindest das Frame Format scheint aber in der Simulation zu passen. Insgesamt komme ich beim Keil auf etwas weniger als 4Kb in der höchsten Stufe (9. Common Block Subroutines) ca 3.5kB. Meine Usb Irq Funktion ist ziemlich viel code wegen der ganzen Fallunterscheidungen. Der SDCC braucht mehrere sec zum Übersetzender, der mag wohl längere Quelltexte nicht. Ich bekomme die USB Funktionen nur mit EP0_SIZE=8 mit avrdude ans Laufen. Ob das an meinem usbdrv.c liegt oder eine Einschränkung von avrdude ist, kann ich noch nicht sagen. Im Anhang mal tpi.c und usbdrv.c. Nächste Woche gibts das komplette Projekt. Die (zusätzlichen) Klammern bei den case xxx sind nur wegen dem code folding Editor drin.
Ich habe heute den SDCC support vervollständigt (Build per Batch Datei) Mit make komme ich leider immer noch nicht klar :-(. Wie erwartet ist der code ca 25% gößer als bei Keil 4000 bytes versus 5000 bytes. Im schlechtesten Fall sind es sogar fast 40%. (OT9, CDC aus WCID und TPI ein).
Angehängte Dateien:
-
is51b.png
99 KB
Hallo Thomas. Ich arbeite gerade an einer Entwicklungsumgebung für MCS51 unter Linux (Bild is51b.png). Darin werden Einzeldateien direkt übersetzt (compiliert/assembliert), Projekte aus mehreren Dateien und das aufräumen mit "Clean" übernimmt ein Makefile. Dieses ist im Anhang "is51.mak zu finden. Aufruf zum übersetzen: "make -f is51.mak FNM=Dateipfad ohne Extend" Aufruf zum aufräumen: "make clean -f is51.mak FNM=Dateipfad ohne Extend" Vielleicht hilft Dir das Beispiel etwas weiter bei Makefiles. Gruss Tom
:
Bearbeitet durch User
Habe noch ein Beispiel vergessen:
make -f is51.mak FNM=/home/SDCCprogs/Test
Übersetzt die Datei/das Projekt "Test" im Pfad "/home/SDCCprogs/".
Das kann Test.c oder auch Test.asd (asd = Assembler für SDcc) sein.
Tom A. schrieb: > Habe noch ein Beispiel vergessen danke für das make file und die Beispiele. Das passt bei mir so nicht weil ich überall relative pfade habe, und die Ausgabe gerne in getrennten Ordner ablege. Soweit ich das verstanden habe hat make mit einer solchen Struktur Probleme. Ich müsste mir also mein Strings zusammenbasteln. Es ist nicht so, dass ich gar keine Ahnung von make habe... Ich bab das bisher immer auf die lange Bank geschoben und halt passende Batch Files geschrieben. Normale makes gehen ja davon aus dass alles in einem Ordner liegt.
Man könnte auch nur den Dateinamen übergeben und die Pfade innerhalb des Makefiles zuordnen. Damit habe ich mich aber noch nicht beschäftigt, da ich meine Projekte jeweils in eigenen Verzeichnissen verwalte. Wie auch immer, Hauptsache am Ende kommt das Gewünschte dabei raus. Gruss. Tom
Guten Tag, seit kurzem habe ich mir CH559L chips geholt. Beim flashen über USB tritt bei mir allerdings das Problem auf, dass die Programmierung meistens fehlschlägt - sowohl beim WCHISPTOOL, als auch beim chflasher. Beim debuggen mit dem chflasher ergibt sich, dass die Übertragung nach verschieden vielen Transfers beim flashen oder verifizieren einen timeout error aufwirft. Ab und zu ist er schon vornherein nicht erreichbar, obwohl er hier ( https://www.uwe-sieber.de/usbtreeview_e.html#download ) aufgelistet wird. Danach ist der chip, bis man ihn resetted, nicht mehr erreichbar. Mit dem WCHISPTOOL wird Ähnliches erkennbar. Irgendwann bin ich dann auf diesen Thread gestoßen und hoffe, dass ihr mir weiterhelfen könnt? Habt ihr ähnliche Probleme? Noch ein paar Gedanken/Informationen: - Bootloader-Version: 2.40 - ~ Bootloader kann mit Fehlern bei der USB-Übertragung nicht umgehen - ~ höhere Fehlerquote durch langes Kabel? - ~ Flash-Speicher ausgenutzt, sodass das Schreiben fehlschlägt (die chips sind neu, aber ich weiß nicht, ob sie vorher schon benutzt wurden(https://de.aliexpress.com/item/1005004508033849.html))
:
Bearbeitet durch User
Christian E. schrieb: > - Bootloader-Version: 2.40 die V2.4 dürfte das Problem sein. Ab Version 2.4 stellt sich der Chip nach dem ersten fehlgeschlagenen Verify tot. Das haben die eingebaut damit unser Dumper nicht mehr funktioniert. Ich kenne den CH Flasher nicht im Detail, aber da ist vermutlich noch ein Bug drin was das Verify angeht. Ich weis definitiv dass das WCHIspTool manchmal beim letzten zu flashenden Block einen Verify Error wirft. -> Beitrag "Re: uC für 0,20€ CH552 / CH554 von WCH Billig Micro mit USB Funktion, Chip vorstellung" Konvertiere dein hex mal nach bin und probier nochmal das WCH ISP Tool. Je nachdem wie dein Hex aussieht könnte das die Ursache sein.
Thomas Z. schrieb: > die V2.4 dürfte das Problem sein. Ab Version 2.4 stellt sich der Chip > nach dem ersten fehlgeschlagenen Verify tot. Das haben die eingebaut > damit unser Dumper nicht mehr funktioniert. das macht sinn, aber wieso stellt der chip sich schon beim programmieren tot? und wieso wieso wird er beim chflasher und WCHISPTOOL manchmal garnicht erst aufgelistet, obwohl er bei Windows (https://www.uwe-sieber.de/usbtreeview_e.html#download) immer aufgelistet wird? - werden die USB descriptor neu angefragt? Thomas Z. schrieb: > Konvertiere dein hex mal nach bin und probier nochmal das WCH ISP Tool. > Je nachdem wie dein Hex aussieht könnte das die Ursache sein. Das schließe ich aus. Ich habe mehrere Programme ausprobiert, die jeweils oft fehlgeschlagen sind, aber dann irgendwann erfolgreich geflasht wurden. Jedoch schlägt das flashen immer öfter fehl. wie ist das eigentlich mit dem Bootloader - ist er mit *P4.6(XI)* standartmäßig immer erreichbar, oder muss man immer im Programmcode den Bootloader aufrufen (LJMP BOOT_LOAD_ADDR / LCALL BOOT_LOAD_ADDR)? - Ich will mich nicht softlocken.
:
Bearbeitet durch User
Christian E. schrieb: > wie ist das eigentlich mit dem Bootloader - ist er mit *P4.6(XI)* > standartmäßig immer erreichbar, oder muss man immer im Programmcode den > Bootloader aufrufen (LJMP BOOT_LOAD_ADDR / LCALL BOOT_LOAD_ADDR)? > - Ich will mich nicht softlocken. Der Bootloader kann immer mit P4.6 bzw P5.1 gestartet werden. Allerdings werden diese Pins nur beim Powerup abgefragt, nicht beim Reset. Das ist übrigens auch der einzige offizielle Weg. Der LCALL 0xF400 funktioniert inoffiziell auch du solltest aber darauf achten vor dem JMP T0/T1 zu sperren und IE = 0 setzen. Das ist nicht das gleiche wie der Start per POR Event! Beim Start per LCALL /LJMP 0xF400 kannst du die Config Bits (Download Config im ISP Tool) nicht verändern. Ob das alles wirklich so stimmt kann ich nicht sagen weil ich noch nie die v2.4 für den CH559 hier hatte und deshalb auch nicht disassembliert habe. Übrigens bei neueren Controllern (CH548/9) funktioniert der LCALL in den Bootloader sowieso nicht, da geht nur noch der Weg über POR. Der Bootloader ist schreibgeschützt denn kannst du nicht kaputt machen
:
Bearbeitet durch User
Thomas Z. schrieb: > ..., weil ich noch nie > die v2.4 für den CH559 hier hatte und deshalb auch nicht disassembliert > habe. Ich habe mal meinen CH559L (Bootloader V2.40) gedumpt und hier angehongen, wenn das jemand braucht. Nur meinen Code habe ich gelöscht, der Bootloader startet ja bei 0xF400. @Thomas Z., danke übrigends für deine schnellen Antworten, das hat mir weitergeholfen.
:
Bearbeitet durch User
Christian E. schrieb: > Ich habe mal meinen CH559L (Bootloader V2.40) gedumpt und > hier angehongen, wenn das jemand braucht. ich hab mir das mal angeschaut. Der Code entspricht im wesentlichen dem 2.31 mit den Erweiterungen für das VerifyErr bit. Es wurde die Überprüfung auf IAP(ICall) aus der Main Schleife rausgenommen. Der Rest ist ziemlich unverändert. Der TimeOut über T0 wird abgeschaltet sobald die Software das ID Cmd schickt. Reihenfolge der Variablen ist identisch. Bei den Bit Vars gibts Dreher.
ich hab mal das zurückübersetzte main() der v2.4 angehängt
Ich hab jetzt meinen CH552 basierten ISP so erweitert, das er jetzt auch die PIC18FxxQ41 programmieren kann. Der Code ist noch recht rudimentär aber tut was er soll.
Thomas Z. schrieb: > Da sieht man wie sich dank online Übersetzer sowas heute verbreitet. Ich > glaube übrigens einen Weg gefunden zu haben auch beim V2.4 und v2.5 > Loader die Chips auszulesen. Das ist aber wesentlich aufwendiger. Das > ist aber noch nicht fertig. Hi Thomas! Any news on the 2.40 bootloader? I was thinking of erasing a small chunk of memory to reset the bWrProtect bit and then loading a program to print a memory dump, but the bootloader doesn't accept values lower than 8, so we'll lose most of the dump.
Sergiy schrieb: > Hi Thomas! Any news on the 2.40 bootloader? no, in fact meanwhile i think there is no way to dump the firmware for v2.4 and v2.5 bootloaders.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.