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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.