Thomas T. schrieb: > Allerdings führt die CPU, sobald DPTR auf 4000h zeigt (und A=0 ist), bei > einem "MOVC A,@A+DPTR" (Ja, sorry, ich schreibe nur in Assembler...) > einen Reset durch und startet wieder neu... :-( Nun sowas ähniches hab ich hier auch schon gesehen.... Hab das bisher aber eher auf Programmfehler meinerseits geschoben. Wenn da wirklich ein Reset passiert haben die definitiv einen Hack im core. Aber auch dies wäre ja durchaus wichtig zu wissen. Thomas
Thomas schrieb: > Thomas T. schrieb: >> Allerdings führt die CPU, sobald DPTR auf 4000h zeigt (und A=0 ist), bei >> einem "MOVC A,@A+DPTR" (Ja, sorry, ich schreibe nur in Assembler...) >> einen Reset durch und startet wieder neu... :-( > > Nun sowas ähniches hab ich hier auch schon gesehen.... Hab das bisher > aber eher auf Programmfehler meinerseits geschoben. Wenn da wirklich ein > Reset passiert haben die definitiv einen Hack im core. > Aber auch dies wäre ja durchaus wichtig zu wissen. > > Thomas Ich weis leider nicht genau ob das was damit zu tun hat aber wenn ich beim verify eine adresse höher als 0x4000 vergleichen wollte gab es auch einen Reset.
Ich bin ein Stück weiter... 1 der Bootloader ist identisch zu dem was wir schon haben.Er entspricht dem was Sigint ursprünglich ausgelesen hat. 2. Der Usbcore bleibt stehen sobald ein MOVC mit einem DPTR>=0x4000 vorkommt. Keine Ahnung ob es wirklich ein Reset ist da ich keinen Disconnect in meinem Reset code habe. Ich halte den Reset aber für wahrscheinlich. Vermutlich macht es keinen Sinn da weiter zuschauen. Thomas
Thomas schrieb: > 1 der Bootloader ist identisch zu dem was wir schon haben.Er entspricht > dem was Sigint ursprünglich ausgelesen hat. Ah mist, hätte man natürlich auch mal so byteweise vergleichen können... Da beim Flashen ja an den Config Bytes etwas geändert wird, denke ich das man sich die mal etwas genauer ansehen muss. er schreibt vor dem Flashen das als config bytes cmd: a80e000700ffffffff03000000ff520000 vorher war die ausgelesene config so: Cfg Bytes Version SerialNr a77d1a001f00ffffffffffffffffffd27ff5 00020301 e079b644 fdb755bf und nach dem schreiben so: Cfg Bytes Version SerialNr a77d1a001f00ffffffff23000000ff527ff5 00020301 e079b644 fdb755bf hilft so erstmal nicht aber ist ein kleiner überblick
Aaron C. schrieb: > Da beim Flashen ja an den Config Bytes etwas geändert wird, denke ich > das man sich die mal etwas genauer ansehen muss. Du meinst die Config-Bytes an 3FF8h und 3FF9h? Das ist mir auch aufgefallen. Es könnte aber auch damit zusammenhängen, das die Routinen, welche wir als User ins Flash ab 0000h schreiben, einen anderen Status haben als der Bootloader selbst. Ich beziehe mich auf Bit 5 im GLOBAL_CFG-Register (bBOOT_LOAD). Dieses Bit ist 1 nach Power-Up und wird bei einem Software-Reset auf 0 gesetzt. Ich vermute mal, mit diesem Bit wird auch die Möglichkeit freigeschaltet ab 3800h bis 3FFFh zu schreiben. Somit kann der Bootloader das Config-Byte (3FF8h/3FF9h) schreiben (und auch die anderen Bereiche, die aber per Software ausgeklammert werden) und nach einem Software-Reset, welcher unsere "User-Software" startet, tappen wir dann im Dunkeln und können nicht mehr schreibend auf den Bootloader-Bereich zugreifen... Das Bit 5 im CLOBAL_CFG-Register ist leider ReadOnly. So auf Anhieb sehe ich da keine Möglichkeit, das Bit zu setzen... Gruß Thomas
Thomas T. schrieb: > Das Bit 5 im CLOBAL_CFG-Register ist leider ReadOnly. > > So auf Anhieb sehe ich da keine Möglichkeit, das Bit zu setzen... Ich habe vielleicht eine Lösung für das Problem. Zumindest ist es Wert da etwas weiterzuforschen... Das Bit 5 ist ja zumindest nach einem PowerOn Reset erst mal 1. und wird durch den Software Reset gelöscht. Zumindest beim V1 Bootloader gibt diesen ICAll. Dieser wird durch eienn Timeout von T0 ausgelöst wenn passende Werte im Config Bereich vorhanden sind. Das Bit ist dann immer noch 1. Meine Vermutung ist nun dass ein entsprechendes IAP File in der WCH App geladen werden muss dieses IAP File wird dan bei gestztem Bit 5 ausgeführt. Diese Möglichkeit gibts beim v2.3 Loader wohl nicht mehr. Ich werde da mal was programmieren. Thomas
Gibt es hier jemand mit einem Mac? Ich habe ein dual CDC Device gebaut was problemlos unter Linux und WIN funktioniert. Auf stackoverflow hab ich gelesen dass Macs keine IAD Deskriptoren für CDC unterstützen, weshalb ich in der FW einen fix eingebaut habe den ich von früher kenne. Da ich keinen Mac habe bin ich auf eure Hilfe angewiesen... Meine Fragen: Seht Ihr auf dem Mac comports? Wenn ja wie viele? Welche Device ID ist am Mac zu sehen? Der code sollte auch auf einem ch554 laufen das hab ich aber nicht geprüft. Ein CH551 oder CH553 dürfte nicht gehen da die nur einen UART haben. Thomas
Mist falsche Datei ausgewählt. Hier die richtige... Thomas
@Thomas, ich habe leider keinen Mac Sry. Melde mich nun nochmal zum Thema Android App, die habe ich nun erfolgreich für Bootloader V2.31 im play store unter diesem link: https://play.google.com/store/apps/details?id=com.atcnetz.de.ch55xprogrammerV2 insgesamt ist es etwas aufgeräumt und auch erfolgreich für CH551 flashen getestet. Der Fehler weswegen dies nicht funktioniert hatte ist etwas blöd, der Flash des CH551 ist wie angenommen auch 16Kb groß ich habe aber beim erase befehl immer nur FlashSize/2048 geschrieben also bei angegebenen 10Kb nur 5 und nicht 8 wie beim CH552. Dadurch hat der Bootloader natürich nicht den Flash "Freigegeben"... das musste also nur geändert werden und der CH551 lässt sich erfolgreich flashen. Bitte testet dies doch kurz wer die Möglichkeit hat. auch wegen der Bildschirmgröße und dem text innerhalb der Buttons, ob das so mit dem Design etwas schöner aussieht. Und Vielen dank nochmal an Andreas für das Bereitstellen der CH551 Chips :)
Aaron kein Problem. Ich wollte eigentlich nur sicher gehen dass ich keinen kompletten Unsinn programmiert habe. Falls sich niemand hier meldet werde den code einfach so einstellen. Ich habe noch ein 2. Beispiel in der Pipeline ein einfaches UsbMidi Device. Das ist ein Ableger aus einem alten Projekt. Thomas
Thomas schrieb: > Gibt es hier jemand mit einem Mac? Habe ich (genau für solche Testzwecke ;-)) > Ich habe ein dual CDC Device gebaut was problemlos unter Linux und WIN > funktioniert. Auf stackoverflow hab ich gelesen dass Macs keine IAD > Deskriptoren für CDC unterstützen, weshalb ich in der FW einen fix > eingebaut habe den ich von früher kenne. > Da ich keinen Mac habe bin ich auf eure Hilfe angewiesen... > Meine Fragen: > Seht Ihr auf dem Mac comports? Wenn ja wie viele? > Welche Device ID ist am Mac zu sehen? Werde ich bei Gelegenheit prüfen. > Der code sollte auch auf einem ch554 laufen das hab ich aber nicht > geprüft. > Ein CH551 oder CH553 dürfte nicht gehen da die nur einen UART haben. > Thomas CH552? Oder worauf? Aaron C. schrieb: > Melde mich nun nochmal zum Thema Android App, die habe ich nun > erfolgreich für Bootloader V2.31 im play store unter diesem link: > https://play.google.com/store/apps/details?id=com.atcnetz.de.ch55xprogrammerV2 Werde ich ebenfalls Testen. > insgesamt ist es etwas aufgeräumt und auch erfolgreich für CH551 flashen > getestet. Das ist interessant ;-) > Und Vielen dank nochmal an Andreas für das Bereitstellen der CH551 Chips > :) Gerne. Ich habe aktuell etwas viel geplant, und blöderweise auch gerade noch ein Problem mit dem Handy :-( Ein neues wartet schon länger, aber jetzt muss ich wohl wechseln, wird auch noch etwas ungeplante Zeit kosten... Also rechnet nicht mit einer schnellen Antwort, aber ich bin auf jeden Fall da noch dran... mfg Andreas
Andreas B. schrieb: >> Der code sollte auch auf einem ch554 laufen das hab ich aber nicht >> geprüft. >> Ein CH551 oder CH553 dürfte nicht gehen da die nur einen UART haben. >> Thomas > CH552? Oder worauf? Eigentlich sollte der code auf jedem Chip laufen. Es geht mir da in erster Linie um die Enum und die Deskriptoren. Ich benutze den CH552. Der Fix basiert darauf dass man anhand des ersten GetDescriptor(Device) erkennen kann ob ein Device unter Win oder am Mac läuft. Zumindest hat das früher so funktioniert. Vielen Dank schon mal. Thomas
Hallo zusammen, hier nun wie versprochen mein Midi example. Wieder als Keil Projekt. Zum Ausprobieren einfach das Hex aus dem Out Ordner flashen. Das ganze ist für den ch552 gemacht, sollte aber auch auf dem ch554 laufen. Das die Ports auf dem 2. Uart liegen geht der ch551 oder ch553 nicht. Wenn das Ganze auf Aarons Stick läuft werden die LEDs zum Anzeigen des Midi Traffic benutzt. Zusätzlich ist auf dem Midi Output active sense implementiert. Getestet unter Win 10, XP und Ubuntu. Thomas
Hallo zusammen, ich habe mich dieses Wochenende mal mit dem Programmieren der CH552 über das externe SPI-Interface beschäftigt. Also nicht über die USB-Schnittstelle und das WCHISPTool, sondern wie im Datenblatt im Kapitel 6.6 "kurz erwähnt" über ein paar Portbits vom Port 1. Während der CH552 im Reset verweilt (RST=High) ist das IC wohl wie ein SPI-Slave zu betrachten. Mit einem Arduino als Software-"SPI-Master" habe ich dann versucht dem CH552 ein paar Bits zu entlocken. Erfolg hatte ich aber leider keinen, nicht einmal einfache Dinge wollten funktionieren... Folgendes habe ich versucht: A) Basics * Erstmal gehe ich davon aus, das im englischen Datenblatt vom CH554 (das ich für den CH552 nehme) das Signal MOSI fehlt (Im Datenblatt für den CH559 ist es drin...). Über diese Leitung werden die Bits vom Master (meinem Arduino) zum CH552 gesendet. * RST ist die ganze Zeit auf High-Pegel, da der Chip im Reset sein muss... * Die SCS-Leitung stellt wohl "Chip Select" dar, aktiv bei Low-Pegel... B) Das interne SPI-Register * Wenn man sich über Google Bilder von SPI-Verbindungen anschaut, dann findet man schnell interne 8Bit-Schieberegister, welche mittels dem SCK-Signal die Daten von MOSI entgegennehmen und über MISO nach 8 Takten verzögert wieder ausgeben. Dieses Verhalten konnte ich leider nicht nachstellen. Egal was ich auch machte, das MISO-Signal war konstant auf High-Pegel... :-( C) Freischalten des Programmier-Modus ??? Ich habe in meiner Verzweiflung mir mal ein Datenblatt vom einem alten 89S51 angeschaut, welchen man ebenfalls seriell über ein SPI-Interface programmieren kann. Dort ist eine Liste "Serial Programming Instruction Set" abgebildet, wo auch eine Sequenz zum Freischalten des Programmier-Modus aufgeführt wird. Ich habe daraufhin den Arduino so programmiert, dass er 65536 mal 4 Bytes zum CH552 sendet: "SCS auf Low", HighByte, LowByte, 0x00, 0x00, "SCS auf High". Ich hatte gehofft, dass sich dann vielleicht irgendwas auf der MISO-Leitung tut, aber das Signal blieb weiterhin auf High-Pegel... Da das Internet diesbezüglich (nach meiner Suche zu urteilen) absolut leer ist, folgende Fragen in die Runde: 1) Hat von Euch jemand selbst was in dieser Richtung unternommen? 2) Hat von Euch jemand irgendwo was bezüglich der externen SPI-Programmiermöglichkeit gefunden? 3) Gibt es für den CH552 auch ein "Serial Programming Instruction Set"? 4) Und warum kriege ich nur High-Pegel auf MISO? Gruß Thomas
Thomas T. schrieb: > 2) Hat von Euch jemand irgendwo was bezüglich der externen > SPI-Programmiermöglichkeit gefunden? Nicht viel aber ein Ahnhaltspunkt. Leider ist da keine Software oder Firmware dabei. Der Programmer benutzt einen ch559. http://www.wch.xx/public/uploads/file/20170315/1489557538760199.rar xx durch cn ersetzen Thomas
Thomas schrieb: > Thomas T. schrieb: >> 2) Hat von Euch jemand irgendwo was bezüglich der externen >> SPI-Programmiermöglichkeit gefunden? > > Nicht viel aber ein Ahnhaltspunkt. Leider ist da keine Software oder > Firmware dabei. > Der Programmer benutzt einen ch559. > > http://www.wch.xx/public/uploads/file/20170315/1489557538760199.rar > > xx durch cn ersetzen > > Thomas Danke für den Link. In dem rar-Archiv sind zwei Dateien, ein PDF und ein File mit der Endung DDB. Ich konnte mir leider nur das PDF anschauen, aber da kann ich nur draus entnehmen, dass wenigstens keine "Multi-Level"-Signale verwendet werden... Das DDB-File scheint eine Projektdatei (oder ein Schaltplan) für Protel / Altium Designer zu sein. Aber damit kann ich leider nichts anfangen... Gruß Thomas
@Harter Kern: Darf ich bitte eine vermutlich blöde Frage stellen, ich habe versucht, die entscheidende Stelle zu finden aber es erschließt sich mir nicht: Ganz zu Anfang hat Aaron doch berichtet, dass sich die Controller direkt per USB programmieren lassen. Warum wird hier maßgeblich seit vielen vielen Beiträgen über den neuen Bootloader gesprochen? Oder ist das nur für die Programmierung per Android relevant? Danke für die Aufklärung und mein Respekt für das Engagement!
Harald schrieb: > @Harter Kern: > Darf ich bitte eine vermutlich blöde Frage stellen, ich habe versucht, > die entscheidende Stelle zu finden aber es erschließt sich mir nicht: > Ganz zu Anfang hat Aaron doch berichtet, dass sich die Controller direkt > per USB programmieren lassen. Warum wird hier maßgeblich seit vielen > vielen Beiträgen über den neuen Bootloader gesprochen? Oder ist das nur > für die Programmierung per Android relevant? > Danke für die Aufklärung und mein Respekt für das Engagement! Moin Harald, es wurde versucht den vorhandenen Bootloader durch einen eigenen zu ersetzen, dies hat soweit leider nicht funktioniert da wohl ein Schreibschutz auf dem bereich ist. Es hat für die Grundsätzliche Funktion keinen Einfluss und alles funktioniert auch mit dem Originalen Bootloader, der Chip kann so ohne weitere Hardware Programmiert werden. Zusätzlich gab es con WCH ein Update des Bootloaders auf den Chips in den Letzten Monaten, dafür musste dieser ausgelesen werden um die Allgemeine Funktion zu verstehen und auch die App darauf Kompatibel zu machen.
Thomas T. schrieb: > Das DDB-File scheint eine Projektdatei (oder ein Schaltplan) für Protel > / Altium Designer zu sein. Aber damit kann ich leider nichts anfangen... Ist es nicht. Im Header steht JET DB Google meint das ist access97. Ein MDB Viewer sagt allerdings dass ein PW vergeben ist. Ich besitze kein Access. Ich habe Mal im Hex Mode reingeschaut das scheint schematics und pcb im Pads 4.0 Format zu sein. Zumindest deuten Strings darauf hin. Thomas
Hi
>Ist es nicht. Im Header steht JET DB Google meint das ist access97.
Protel benutzt Access-Datenbanken für die Projekt-Files.
MfG Spess
spess53 schrieb: > Protel benutzt Access-Datenbanken für die Projekt-Files. OK das wusste ich nicht. Hab mal etwas mit dem Import gespielt.... Der Offline flasher bedient am Programiersockel nur USB und uart nix mit SPI. Das Teil ist also einfach nur eine aufgeblasene Version um den Bootloader zu starten. Deswegen gibt's auch keine extra Software. Wenn ich das richtig interpretiere wird mit dem Programmer einfach ein zuvor eingelesenes Programm an den Sockel geschickt. Ist wohl dazu gedacht ein fertiges Programm auf viele Bausteine zu flashen bevor diese eingelötet sind. Jedenfalls nicht das was ich vermutet hatte. Thomas
Aaron C. schrieb: > es wurde versucht den vorhandenen Bootloader durch einen > eigenen zu ersetzen, dies hat soweit leider nicht funktioniert da wohl > ein Schreibschutz auf dem bereich ist. > Danke!
Hab mich hier jetzt duchgewühlt. Gibt es eine Projektseite?
Ich hab dieses Wochenende Mal etwas weitergeforscht... Da ich vorwiegend unter Win arbeite hatte ich bisher mit einer zusätzlichen Vid Pid und libusb gearbeitet. Das hat den Vorteil daß bei Tests nie die WCH ID verwendet wird und ich deshalb jederzeit einen Download mit dem ISP Tool anwerfen konnte. Der Nachteil war halt dass nie der Original loader angesprochen wurde. Hat mich bisher aber nicht so gestört. Jetzt ist mir allerdings aufgefallen dass im Isptool die IAP Funktion nicht arbeitet, ob Bug oder Absicht keine Ahnung. Eine Anfrage bei WCH ergab nur ausweichende Andworten. Ich glaube das der Kontakt dort keine Ahnung hat und nur als Übersetzer fungiert. Zusätzlich habe ich seit letzter Woche den Verdacht dass das Isptool nicht alle Funktionen erlaubt die theoretisch möglich wären. Nun stand ich vor dem Dilemma entweder alles unter Linux mit libusb zu machen oder unter win zwischen ch375.sys und libusb umzuschalten. WCH verwendet eine wrapper dll um ihren Treiber anzusprechen. Da diese dll relativ klein ist hab ich die einfach durch den IDA geschickt. Da sind etwa 30 Funktionen exportiert um alles Mögliche anzustellen. Also hab ich mir für meinen Compiler schnell eine passende Import lib generiert und ein paar kurze Tests gemacht. Das sieht gut aus. Ich habe damit erfolgreich die beiden Bulkeps des Bootloaders ansprechen können. Mehr dazu in Kürze. Thomas
Hier das entsprechende Header File um die ch375dll.dll anzusprechen. Es sind allerdings nur 5 Funktionen drin. Diese reichen um den Bootloader anzusprechen Im Moment gibt's noch keinen code. Im Kommentar hab ich beschrieben wie man eine entsprechende Import lib generiert allerdings nur für Borland /Inprice oder wie auch immer die gerade heißen. Thomas
Thomas T. schrieb: > C) Freischalten des Programmier-Modus ??? Nun vielleicht nicht direkt passend zum SPI Programmiermodus aber es ist mir heute gelungen das Bit15 im Config Word zu setzen (Code_Protect) ebenso wie Bit13 und Bit12. Diese Bits waren bisher bei mir gelöscht. Ans Bootloader Bit hab ich mich nicht rangetraut da dies entgültige wäre. WCH behauptet ja dass Bit 15 und 14 nur per Programmer geändert werden kann. Mehr noch die sagen wenn man Bit14 gelöscht haben will muss man passend programierte Chips ab Factory bestellen. Es ist aber einfach so dass im ISPTOOL da nichts vorgehen ist. Gehen würde es sehr wohl. Thomas
Thomas schrieb: > Thomas T. schrieb: >> C) Freischalten des Programmier-Modus ??? > > Nun vielleicht nicht direkt passend zum SPI Programmiermodus aber es ist > mir heute gelungen das Bit15 im Config Word zu setzen (Code_Protect) > ebenso wie Bit13 und Bit12. Diese Bits waren bisher bei mir gelöscht. > Ans Bootloader Bit hab ich mich nicht rangetraut da dies entgültige > wäre. > WCH behauptet ja dass Bit 15 und 14 nur per Programmer geändert werden > kann. > Mehr noch die sagen wenn man Bit14 gelöscht haben will muss man passend > programierte Chips ab Factory bestellen. > > Es ist aber einfach so dass im ISPTOOL da nichts vorgehen ist. Gehen > würde es sehr wohl. > Thomas das hört sich super gut an. Wie hast du es geschafft? Oder bist du da noch nicht soweit es zu veröffentlichen?
Aaron C. schrieb: > das hört sich super gut an. Wie hast du es geschafft? Oder bist du da > noch nicht soweit es zu veröffentlichen? Ein (vorzeigbares) Programm hab ich noch nicht, das kommt vielleicht noch. Das Prinzip ist aber ziemlich einfach. Wichtig dabei ist das der Bootloader per HW contition gestartet wird nicht so wie ich das immer mache mit dem SW1 da sonst bBOOT_LOAD nicht gesetzt ist und das Flashen im Bootloader Bereich nicht funktioniert. Benutzt habe ich die Kommandos 0xB9 zum Lesen und 0xB8 zum Schreiben. (V1.1) Bootloader. 0xB9 liefert dabei die letzten 8 Bytes. 0xB8 0x02 0xFF 0xF2 setzt alle 4 Bits auf 1. Weil das ISP Tool das nicht kann hab ich die DLL mit dem gezeigten Header direkt angesprochen. Das Bootloader Bit hab ich erst Mal außen vor gelassen weil man bei gelöschten Bit nie mehr per HW contition in den loader kommt und per call das Flashen im Loadersegment nicht funktioniert. Du kannst das gleiche auch in deine App einbauen. Thomas
Hallo zusammen hier eine neue Version meines Flash dumpers. Das Auslesen dürfte nun deutlich schneller sein als bisher, da die Attack Funktion bei häufiger auftretenden Bytes früher zum Ziel kommt. Gleichzeitig auch das erste Programm was die WCH dll Funktionen benutzt, weshalb das Wchisptool installiert sein muss. Es werden nach dem Auslesen 2 Files erzeugt. firmware.hex und firmware.bin. Ich hab das Ding nur mit ch552 getestet. Es sollte aber auf jeden Chip laufen solange Bootloader V1.1 installiert ist. Zum übersetzen reichen die free comandline tools von Borland Thomas
Ein kleines Update zum Flashdumper. Der sollte nun auch mit v2.31 umgehen können. Da ich keinen Chip habe der den neuen loader benutzt hab ich das ganze nur mit dem Fakeloader überprüft. Es ist keine Überprüfung der Chip id drin deshalb sollte es mit allen Chips 551 .. 554 funktionieren. Mich würde insbesondere interessieren was bei einem ch551 passiert. Außerdem interessiert mich besonders ob das Ding korrekt mit v2.31 Chips umgeht. Noch ein Hinweis. Bei v2.31 Chips gibt es die Einschränkung dass der dumper nur arbeitet wenn noch kein Download z.b mit dem ISP Tool gemacht wurde. Das liegt daran dass mein Programm auf den original bootkey angewiesen ist. Also immer neu den Bootloader starten vor dem dumpen. Bei V1.1 gibt's diese Einschränkung nicht Thomas
Angehängte Dateien:
-
CH552_V1.png
5,8 KB -
CH551_V2.png
7,4 KB -
CH551_V2.png
7,9 KB -
CH552_V2.png
5,8 KB
Habs direkt mal getestet, 1. Screenshot CH551 V2.3 Bootloader, 2.Screenshot CH552 V2.3 Bootloader, 3.Screenshot CH552 V1.1 Bootloader. Funktioniert bei allen dreien einwandfrei und der inhalt der HEX/Bin datei ist auch plausibel. Auslesen dauert jeweils ca. 3,5 Minuten, bei ca. 20% inhalt im chip. Sehr gut :) ***** So nach dem fünften versuch auch die richtigen bilder hochgeladen.... ***** Der text der bilder ist richtig, bei manchen der text im bild nicht!!!
Danke für die Tests, das passt alles. Warum manchmal beim ersten Aufruf No device kommt ist mir noch nicht ganz klar. Es hat aber damit zu tun wie ich die DLL anwende. Thomas
Das erstme mal war noch ohne chip. Also das war korrekt mit no device. Soweit funktionierte es immer ohne probleme.
Das einzige was mir aufgefallen ist während des dumping konnte man nicht das WCHsp tool öffnen. Erst nach erfolgreichem Dump wurde es dann geöffnet denke es können nicht zwei Programme gleichzeitig auf die DLL Datei zugreifen
Das ist interessant, hab ich nie probiert und dürfte ein Bug im ISP Tool sein. Umgekehrt geht es schon. Erst ISP Tool öffnen und dann den dumper. Wie gesagt in einigen wenigen Fällen findet der dumper manchmal nicht den Chip. Beim 2. Aufruf ist dann alles okay. Die DLL selbst kann 10 Instanzen. Thomas
Hi Thomas, Thanks a lot for your flash dumper. I used it to correct a bug in an LCD screen produced by Elecrow where the CH522 would send a corrupted USB descriptor. I tried contacting the manufacturer but they would not give me a new firmware so I had to dump it, correct the binary and flash it back. More details on this project of mine can be found here (Work In Progress) https://docs.google.com/document/d/1jmeahpnjeAqMjk7ggY5-rmIeFwNI3Z95cOOK5Kqo6uY/edit?usp=sharing. I believe there are two bugs in your flash reader and I would like to help fixing them. First, the memory at address 0 is not loaded as the loop will exit before reading it. In my case I had to manually replace the 0xFF with a 0x02 to have the correct jump instruction. Second, it seems that the crc for the Intel hex format is not correct, I believe the crc should be the 2 complement of the sum when written at then end. I would be happy to fix those and send you an updated version but the source code that your provided last does not run for me: it stops at failed to reset key. Do you have the source code for the last version? freader-2.zip contains only the exe. Thank you in advance and sorry for writing in English, my German is not good.
Hello Cory great to hear the dumper ist usefull for you. I Just checked and you are right about both bugs. I will soon update the reader. Actually i was more concerned in getting that thing working. Should have more carefully check the output. Because i used the hexoutput from another project i did not evaluate it. Just for the same of interest How big was your fw? How long did it take to dump it? Thomas
Hi Thomas, Thanks for your answer. I run a benchmark of the dumper and on my CH552, it takes 7min8s to dump the 16361bytes of the memory. It includes also the bootloader area. I'm able to compile the original code from freader.zip (8.6.2019) with the following command: bcc32c.exe .\freader.c But then when I run I have the error: failed to reset key More precisely, the InitKey function the CH375ReadEndP returns rxlen==0. When I run the freader.exe that comes with the zip, it works fine. Are there any options to pass to the compiler? Here is the version of the compiler I use: Embarcadero C++ 7.30 for Win32 Copyright (c) 2012-2017 Embarcadero Technologies, Inc. Anyway, this is just because I would like to understand more how the dumper works in conjunction with the bootloader. I was able to find that the data at address 0 was not correctly read by doing the following test: From a working hex file, flash the CH552 Convert the hex file to binary using srecord read the program memory using freader compare the two binary. For fixing the firmware of the touchscreen, I had two options: 1-get access to the firmware, fix the binary with the correct USB descriptor and flash it again 2-write the application again reading the touchscreen chip over bitbang i2c and emulate a touch screen HID USB device to send the touch events to the Host. Thankfully with your code, I was able to directly proceed with 1. I look forward to testing the new version. Cory
Hello Cory, i am guessing you allready did some translation on this discussion so i right start in the middle. These controllers are all using some protectiion so there is simply no read back command. Basically there are 2 loaders with different command sets. For verify they use some comand to read back known scrambled data. The verify is working on 16byte chunks which have to be correct inorder to get a ok back. We know that at the end of the loader there are some bytes unused, and i am using that to find the starting point by looking for 16 0xFF. From there its easy just change the fist byte in a loop from 0 to 255. If verify reports ok save the byte , dec address move buffer by one byte. Do that until address 0 is reached. Its a simple brute force attac. This is nothing new Aaron and me developed that about 2 months ago. The new thing is now i am using the original driver to to that and use a statistic table to find the final byte earlier which greately improved the speed. For the new loader v2.31 just the key handling is different the rest will be still the same. On the new loader they now use a 8 byte key with chipserial and chip id encoded. There are no special params needed to translate. I need to check why it does not work for you. Maybe i did some late changes and include a older version of the source? Hope this hlps Thomas
Angehängte Dateien:
Habe nun die "Flash Dump" Funktion auch in die App eingebaut, hatte es bisher ja nur für den Bootloader drin aber da sich dieser ja nicht ändert macht es wenig sinn und war nur für das einmalige auslesen interessant. Anstatt am Begin des Dumpens nach FF bytes als startwert zu suchen nehme ich nun die ersten 7 Bytes vom Bootloader, diese sind ja bekannt und werden sich nach jetzigem stand ja nicht ändern. Es wird dann vom letzten Byte vor dem Bootloader bis zum ersten Byte Ge Bruteforced und danach kann man den Dump Teilen, also per Mail etc. oder einfach in die Zwischenablage kopieren, als Datei wird er erstmal nicht gespeichert da dafür bei Android Schreibrechte gebraucht werden und ich möchte erstmal ohne rechte auskommen. Hier nochmal nen link zur App: https://play.google.com/store/apps/details?id=com.atcnetz.de.ch55xprogrammerV2 Die Erste version ist ja leider nicht mehr Aktualisierbar. Achso, das Dumpen geht mit Version 1 und 2 Bootloadern einwandfrei.
Hello, Thomas, thank you for the explanation! that's a very smart way to read the whole memory! I have created a beta version of the flash dump in Python that runs on Linux based on the usb programmer wchprog (https://github.com/juliuswwj/wchprog). You can find a pull request here: https://github.com/juliuswwj/wchprog/pull/1 I'm waiting to receive dev boards to run more tests with different bootloader version. Cory
Thomas schrieb: > > Ich habe vielleicht eine Lösung für das Problem. Zumindest ist es Wert > da etwas weiterzuforschen... > Das Bit 5 ist ja zumindest nach einem PowerOn Reset erst mal 1. und wird > durch den Software Reset gelöscht. Zumindest beim V1 Bootloader gibt > diesen ICAll. Dieser wird durch eienn Timeout von T0 ausgelöst wenn > passende Werte im Config Bereich vorhanden sind. Das Bit ist dann immer > noch 1. > Meine Vermutung ist nun dass ein entsprechendes IAP File in der WCH App > geladen werden muss dieses IAP File wird dan bei gestztem Bit 5 > ausgeführt. Ich meine für den V1.0-Bootloader eine Möglichkeit gefunden zu haben, um ein Programm ohne "Software-Reset" aufzurufen und somit die Flashmöglichkeit in den 3800h-Bereich aufrecht zu halten: Der Code ab 3CE7h im Bootloader V1.0 wird nach einem 'Timeout von T0'(?) aufgerufen. Dann werden bestimmte Werte im Bereich ab 3FF4h geprüft und wenn diese dort NICHT stehen, wird ein Software-Reset ausgeführt und das User-Programm startet ab Adresse 0000h. Wenn allerdings ab 3FF4h folgendes steht: 57h, A8h, ADDR-Low, ADDR-High dann wird ein Programm ab ADDR aufgerufen. Also: 3FF4:57,A8,00,30 ruft ein Programm ab der Adresse 3000h auf. Dieses startet dann in einem Modus, in dem der Bereich des Bootloaders beschreibbar sein sollte. Möglichkeit zum Testen: 1) Zwei Programme flashen: Eins ab 0000h (vielleicht ein langsames LED-Blinken) und ein weiteres ab 3000h (vielleicht ein schnelles LED-Blinken) 2) Danach die vier Bytes ab 3FF4h ändern zu 57h, A8h, 00h, 30h Dann sollte das schnelle LED-Blinken aufgerufen werden. Zum Abschalten bräuchte man nur das MagicWord 57A8 abändern und dann sollte wieder das Programm ab 0000h mittels Software-Reset gestartet werden. > Diese Möglichkeit gibts beim v2.3 Loader wohl nicht mehr. Ich habe zwar das BIN-File für den Bootloader v2.3 gefunden, aber gibt es davon auch schon ein disassembliertes File? Oder vorher weist du, dass es den icall beim V2.3 nicht mehr gibt? Vielleicht war sich dessen auch WCH bewusst und hat die icall-Möglichkeit deshalb entfernt... Gruß Thomas PS: An der "Programmierung über SPI"-Front gibt es zwischenzeitlich keinerlei Fortschritte. Der Chip reagiert auf keinerlei Bit-Wackeln von außen. Vielleicht fehlt auch hier eine Art Code, der die 'SPI-Slave'-Funktion freischaltet. Auch stelle ich mir die Frage, wie eine Programmierung funktionieren soll, wenn die Reset-Leitung nicht mehr nach draußen geführt wird. Fällt dann die SPI-Programmierung auch flach? Eine Art "High-Voltage" auf die RST-Leitung (oder eine andere Leitung) geht nicht, da dann die internen Dioden gegen VCC die höhere Spannung auf VCC ableiten. Das habe ich mal in meiner Verzweiflung getestet... :-) @Thomas: Vielleicht könntest du mir die Kontaktadresse bei WCH per PN schicken. Würde WCH auf Detailfragen diesbezüglich antworten oder lassen die derartige Fragen unbeantwortet?
Eigendlich ist es ja zu heiss um irgendwas vernünftiges zu machen..... Ich hab das noch nicht bis zum letzten ausgetestet, aber ja das sollte funktionieren. Vermutlich war dazu der IAP call im wchisptool gedacht. Dieser funktioniert neben einigen anderen Sachen aber nicht. Was ich ICall genannt habe ist eine lib function des Keil compilers. Diese wird erzeugt wenn man sowas macht Bitte nicht schlagen das geht wirklich
1 | #define CALL (addr) (((void*)(void) (char Code *) addr) ())
|
2 | unit16_t addr = 0x2800; |
3 | ....
|
4 | CALL( addr); |
Ich habe entsprechendes nicht im v2 loader gefunden weshalb ich das noch nicht weiter untersucht habe. Den V2 loader source findest du z.b. auch im im Change bootloader2.zip. Dort gibt's ein a51 fille mit Kommentaren soweit ich das verstanden habe. Zum SPI Mode Eventuell geht da nur nichts weil das entsprechende Bit15 im Configword immer gesetzt ist. Ich hab das bei mir zwar schon rücksetzten können bringt aber nicht viel, das jedesmal automatisch wchisptool gesetzt wird. Antworten auf diese speziellen Fragen bekommst du von WCH übrigens nicht. Ob da eine Sprachbarriere schuld ist oder die nicht wollen mag ich nicht beurteilen. Thomas
Hallo zusammen, falls jemand mit Keil debuggen will, hier die config Dateien zum ISD51 Debugger. Damit kann man über eine ser. Schnittstelle unter uVision debuggen. ISD51 kann für beide Ports konfiguriert werden, siehe die entsprechenden defines im h File. Wer mehr zu ISD51 wissen will sollte das entsprechende Helpfile lesen. Es gibt auch ein simples Testprogramm um das debuggen zu testen. Ich habe den 2 Port mit 9600 Baud verwendet. Thomas
Hallo Ist es auf einfache Weise möglich über USB "Text" auszugeben? Viele Grüße Peter
Moin. Ist es, am einfachsten mit einem CDC example. Das ist das quasi ein simulierter uart zu usb wandler und dort lässt sich der text mit jedem Serial terminal anzeigen. Z.b. https://github.com/Blinkinlabs/ch554_sdcc/blob/master/examples/usb_device_cdc_i2c/firmware/main.c
Hallo Vor einer Weile hatte ich den Chip seriell programmieren können. Jetzt bei einem neuen Versuch, war es einfach nicht mehr möglich. Bei den vielen Programmierungen die ich durchgeführt habe, ist vermutlich die max. Anzahl (200) überschritten. Nach dem 1. Ausfall funktioniert dann auch noch der 2. CH554 nicht mehr. Beide starten noch das darauf vorhandene Blinkprogramm. Der Bootloader meldet sich aber nicht mehr - schade. Damit ist vermutlich der Ausflug mit dem CH554 beendet! Viele Grüße Peter
Mir ist bis jetzt nur ein Weg bekannt den Loader dauerhaft zu deaktivieren. Dazu muss das Bit 14 im Configword geändert werden was zwar möglich ist aber nicht einfach so zu realisieren ist. Ich glaube auch nicht dass die Überschreitung der Prg Zyklen sowas bewirken kann. Das würde wohl eher zu einzelnen kaputten Zellen führen. Wie programierte du den Chip seriell? Welche Baudrate benutzt du? Thomas
Da ich mich schon länger Mal mit dem Config Wizard von Keil beschäftigen wollte hab ich mir Mal das ISD51 cfg File vorgenommen um einen Einstieg zu wagen. Der Wizard ist leider nur sehr oberflächlich in der Hilfe beschrieben. Es war also Trial and Error angesagt. Wenn man dann Mal kapiert hat wie das Teil funktioniert kann man schöne config Menüs generieren. Im Anhang das Ergebnis für die ISD51 Configuration. Der Config Editor geht natürlich nur in uVision sonst sind das einfach Kommentare. Thomas
Hallo So nachdem beide CH554_Module den Bootloader nicht mehr gestartet haben, dachte ich mir, dann kann ich denen auch noch den Rest geben, bevor ich sie entsorge... Ich habe dann von meinem selbstgebautem ISP_Tool GND, RESET, SCK, MOSI und MISO an das CH554_Modul angeschlossen. Dann mit COM1 verbunden............ Und auf einmal meldet sich der Bootlader wieder - ich kann es kaum fassen! Haben da irgendwelche Pegel an den PIN's den Bootloader wieder auf Linie gebracht? Das 2. Modul ist damit auch gerettet. Die serielle Übertragung geht jetzt auch wieder. Ich habe die chinesische Beschreibung des Moduls bemüht und habe festgestellt, daß meine Dokumentation falsch war. Die Pins für die serielle Programmierung sind: TXD1 (P1.7) und RXD1 (P1.6). Das sind gleichzeitig die Anschlüsse für SCK und MISO. Vielleicht ist das auch der Grund, daß bei meinen Spielereien mit dem ISP_Tool, der Bootloader wieder auf die Reihe gekommen ist. @ Aaron C Ich meinte "einfach". Netter Quelltext, aber ich glaube kaum, daß ich die 2 Meter Programmcode zum laufen bringe, und vom verstehen bin ich da auch weit weg - trotzdem danke. @ Thomas (Gast) Ich habe mal "freader-2" laufen lassen. Leider läuft das Programm nicht richtig. Irgenwann hängt es, und die files werden nicht erzeugt. Ich starte natürlich den Bootloader neu, aber der letzte code ist ja noch im Speicher. Viele Grüße Peter
Peter W. schrieb: > @ Thomas (Gast) Ich habe mal "freader-2" laufen lassen. Leider läuft das > Programm nicht richtig. Irgenwann hängt es, und die files werden nicht > erzeugt. mm sollte eigendlich so nicht passieren die Files werden immer erzeugt nur halt eventuell mit Unsinn. Welcher Bootloader ist bei dir installiert? Was ich mir vorstellen könnte: wenn aus irgendeinem Grund der Dptr 0x4000 erreicht bleibt der Usbcore stehen und gibt keine Antworten mehr raus. Was passiert wenn du das dumpen mit ESC irgendwann abbrichst? Alle Chips mit geraden Nummern verwenden UART 1 Txt1 und Rxt1 für den Bootloader, das war schon immer so. Solange du nicht mit der Port cfg rumspielst ist das auch der default an den entsprechenden Pins. Thomas
Firmware ist 2.31 Mit ESC bricht das Programm ab. Die Daten werden per USB übertragen? Wo wird das file abgelegt? Peter
Ja die Daten werden per USB übertragen. Die Files werden im gleichen Ordner abgelegt wo sich auch freader2 sich befindet. Beachte die beiden Bugs zum einen sind die Quersummen im Intel Hex File falsch und das 1.byte an Addresse 0 ist immer FF. Das sollte im Normalfall 0x02 für LJMP sein. Ich hab zwar beides schon gefixt will aber noch warten bis ich auch die Einschränkung mit dem Key für v2,.31 gefixt habe. Das Tool ist allerdings meines Wissens noch nie auf einem ch554 mit v2.31 getestet worden. Solltest du das irgendwie seriell probieren dürfte das nicht funktionieren Thomas
Hi Peter, I just pushed a python version of the flash dumper that should support the bootloader v2.31. The program can flash and dump the memory. Check it out here: https://github.com/sgryco/wchprog/tree/blv2 It is still work in progress and I will continue working on it to merge it with v1 support. Cory
Thomas Z. schrieb: > Alle Chips mit geraden Nummern verwenden UART 1 Txt1 und Rxt1 für den > Bootloader, das war schon immer so. Solange du nicht mit der Port cfg > rumspielst ist das auch der default an den entsprechenden Pins. Wie kann ich den Bootloader auf auf UART (TxD/RxD) ändern, und was hat es auf sich mit den Pin Bezeichnungen: TxD_/RxD_ und TxD1_/RxD1_ ? Peter
Peter W. schrieb: > Wie kann ich den Bootloader auf auf UART (TxD/RxD) ändern Kannst du nicht das ist fest verdrahtet. Vermutlich auch deshalb weil bei der 10 Pin Version des ch554 die Portpins für TxT und RxT gar nicht rausgeführt sind. Lediglich Ch551 und ch553 benutzen Uart0 weshalb die auch den V2 loader brauchen. Beim V1 loader wird immer Uart1 verwendet. Die xx_ Bezeichnungen sind für alternative Mappings da, die du über PINF einstellen kannst. Kapitel 10 im Datenblatt beschreibt das. Die Übersetzung ist aber nicht so dolle. Thomas
Peter W. schrieb: > @ Thomas (Gast) Ich habe mal "freader-2" laufen lassen. Leider läuft das > Programm nicht richtig. Irgenwann hängt es, und die files werden nicht > erzeugt. Ich habe das gestern nachstellen können nachdem ich mit dem Serial Mode etwas rumgespielt hatte. Der Reader läuft dann in einen Timeout und bricht ab. Ein Neustart des Loaders behebt das dann. Es ist wohl so, dass ab dem Zeitpunkt wenn die ersten Bytes seriell Eintreffen der USB Mode nicht mehr funktioniert. Den Reader um einen serial Mode zu erweitern macht aber nicht so viel Sinn. Bei 57k6 würde das Auslesen sehr viel länger dauern. Da meine 2 Projekte jetzt in der Testphase sind werde ich mich wohl nochmal mit den beiden Loader beschäftigen. Ich will nochmal probieren ob ich den V1 loader überschrieben bekomme, wenn ich die Params für den ICALL setze. Thomas
@Thomas, Da ich glücklicherweise einen CH559 ausleihen konnte habe ich dort auch mal den Bootloader Ausgelesen. Vielleicht liest du ja noch mit und kannst reinschauen. Geflasht wird genauso wie beim CH552 und CH551 aber er ist trotzdem anders. Konnte mit minimalen änderungen auch mit der Android App Flashen und Dumpen. Der CH559 hat 2 USB Anschlüße und Host funktion, das konnte ich mittlweile schon erfolgreich austesten bissher aber nur mit Keil und nicht SDCC. Grüße
Schau ich mir mal an. Ich hab's inzwischen übrigens geschaft in den V1 Bootloader zu schreiben. Beim V2 loader sehe ich immer noch keinen Weg. So wie ich die Sache sehe gibt es ohne custom Erweiterung keinen Weg in den V2 loader zu schreiben. Ich arbeite im Moment an einem Konzept den Loader auszutauschen. Dazu gehört im Endausbau dann auch den Loader zu deaktivieren so dass er nicht mehr per HW contition aktiviert werden kann. Die Software Aktivierung wird aber weiterhin funktionieren. Thomas
Bist du sicher dass das binary vollständig ist? Der Code ergibt Sinn wenn man nach 0xF400 disassembliert. Dann entspricht er in der Grndstruktur dem v2.31 loader. Allerdings ist das Ende etwas seltsam. Zusätzlich geht der SerialHandler wohl nur auf uart0. Alles weitere muss sich wohl zeigen Thomas
Das Ging ja fix, Finde gut das du noch immer dabei bist :D Der CH559 hat ja 0xFFFF Flash size und der Bootloader geht von 0xF400 bis 0XFFFD also das könnte schon hinkommen, ich hatte mal den gesamten bereich ausgelesen da kommt aber nicht mehr. Sollte also komplett sein garantieren kann ich es aber nicht. Soweit ich es verstanden habe ist der serialHandler auf Uart0 und den Alternativen Pins P0.2 und P0.3
Aaron C. schrieb: > Das Ging ja fix, > Finde gut das du noch immer dabei bist :D Mit dem IDA geht es recht schnell einen ersten Disassemblerlauf zu machen. Auch weil wir mittlerweile genügend Referenzen haben. Für mich sieht es so aus, dass dieser Loader eine alte Version des v2.31 Loaders ist. Es gibt beispielsweise noch den I_CALL aus dem V1 loader. Es dürfte nicht allzu kompliziert werden den in vernünftiges Format zu bringen. Thomas
Habs nun auch mal richtig in IDA einladen können, hatte vorher noch nicht die Loading Adresse hinbekommen. Man kanns aufjedenfall erkennen, aber denke da bist du besser drin. Leider geht mit der Datei ja Kein Pseudocode, das wäre einfacher. Es scheint soweit auch vieles gleich wie bei den CH552 zu funktionieren, Also Dataflash Lesen, Key setzen und Flashen etc.
Ja die Chinesen halt.... Auch wenn sich das Ding als v2.31 meldet ich werde es V2.30 nennen schon alleine deshalb weil eine Dispatcher Funktion fehlt. Nicht Mal die API ist 100% identisch. Ich frage mich wie die das mit der Versionskontrolle hinbekommen. Wahrscheinlich wissen die selbst nicht so genau welcher Chip mit welchem Loader ausgeliefert wird. Thomas
Ich muss mich korrigieren die API ist identisch. Allerdings ist der CH559 deutlich komplexer. Auch ist die SFR Belegung an einigen Stellen abweichend. Zusätzlich gibt es einige Register im XData Bereich z.b Led und USB. Aaron kennst du ein englisches Datenblatt zum CH559? Thomas
Thomas Z. schrieb: > Ich muss mich korrigieren die API ist identisch. Allerdings ist der > CH559 deutlich komplexer. Auch ist die SFR Belegung an einigen Stellen > abweichend. Zusätzlich gibt es einige Register im XData Bereich z.b Led > und USB. > Aaron kennst du ein englisches Datenblatt zum CH559? > > Thomas Kenne da leider kein englishes Datenblatt zu, nur das chinesische. werde mich aber für die nächsten 1-2 wochen nicht mit dem Thema beschäftigen können da im verdienten Urlaub :D
Thomas Z. schrieb: > Ich frage mich wie die das mit der Versionskontrolle hinbekommen. Nach Bauchgefühl und (ein klein wenig) Erfahrung... kann es durchaus sein, dass die schlicht pro Chip einen eigenen Branch von einem eigenen Team pflegen lassen. Es stammt also von einer Codebasis ab, neue Features werden aber möglicherweise pro Chip neu entwickelt (natürlich mit Inspiration vom existierenden Code). Sowas habe ich bei unseren chinesischen Firmenteilen öfter gesehen.
Hier die v2.31 loader version vom CH559. Der Code erzeugt ein zum binär file von Aaron identisches Image. Bis auf die XSFR Referenzen sind alle magic numbers aufgelöst. Im groben entspricht die Functionalität dem was wir vom v2.31 loadern der anderen Chips wissen. Es gibt aber ein paar Unterschiede im Detail. Interessant ist, dass diese v2.31 Version noch den I_CALL enthält. Thomas
um die Sache mit den Bootloadern abzuschliesen hier noch mal die bearbeiteten Loader. bootloaderV1.a51 ist der V1.1 loader aus meinen CH552. bootloaderV2.a51 ist ein V2.31 loader und stammt von sigint aus einem CH554. Der Vollständigkeit hab ich auch nochmal das h File dazu gepackt, das hat sich aber nicht geändert. Beide Loader verfügen über identische Optionen zum Einschalten verschiedener Features. Solange die Optionen auf 0 stehen und Startaddress auf 0x3800 steht wird der Code identisch zu den Originalen sein. Bis auf die Serial Option bleibt die Funktionalität mit dem Original identisch. Die Optionen lassen sich auch bequem mit dem Config Editor von µVision ändern. Als Bespiel für eine neue Funktion hab ich ein neues cmd 0xAC definiert was so ähnlich wie der I_CALL aus V1.1 arbeitet. Die Call addresse wird dabei einfach auf den Stack gelegt und mit ret gestartet. Dies dient nur als Demo um z.b ein C Programm zu starten. Die Optionen beeinflussen sich gegenseitig nicht, man kann die je nach Bedarf nutzen. Thomas
Moin zusammen, ich melde mich nach langer Pause zurück. Ich habe leider schon seit einiger Zeit nicht mehr verstanden, was ihr so macht. ;-) Das ist weit über meinem Wissensniveau. Ich habe allerdings mal etwas mit dem Python Flash-dumper rumgespielt und ihn auf Seriell umgebastelt. https://github.com/SIGINT112/wchprog By the way: Ich hab den V2.31 Bootloader aus einem CH552G nicht dem CH554... sollte aber keinen großen Unterschied machen. Ich möchte auch noch meine Hochachtung vor allen Leuten aussprechen, die am Entschlüsseln des Chips beteiligt sind. Ihr hat echt unglaubliche Skills... ich wünschte, ich könnte ansatzweise verstehen, was ihr macht. Gruß, SIGINT
Hallo Sigint, wie lange dauert es bei dir den chip seriel zu dumpen? Im Gegensatz zu dir komme ich mit Phyton nicht gut recht. Ich überlege mir dass vieleicht doch in meinen Dumper einzubauen. Du brauchst dein Licht nicht unter den Scheffel zu stellen, immerhin war es deine Loaderversion die für mich der Einstieg war. Thomas
Hallo Thomas, die Zeit ist ein Problem. Der Dump liest leider Byte für Byte. Ich muss da immer auf das Timeout von der seriellen Schnittstelle warten. Das addiert sich. Das kann man definitiv noch verbessern, wenn man die Datenlänge beim lesen kennt. Das werd ich vielleicht am Wochenende mal einbauen. Flashen geht deutlich schneller. Mit Python bin ich erst durch den dumper in Kontakt gekommen... ich kenn mich da auch nicht aus. ;-) Mein Ziel ist es für den Dumper eine schöne GUI zu basteln... entweder direkt in Python, oder ich portiere das auf Java. Gruß, SIGINT P.S.: Ich musste überigens ein paar Bootloader Kommandos anpassen, damit der Dumper mit der seriellen Schnittstelle funktioniert. Ich hab aber nicht die geringste Ahnung, was die bewirken... ich muss mir den Bootloader mal genauer anschauen. Im Moment fehlt mir leider die Zeit, da ich Spätschicht habe. :-|
Ich habe am WE eine App gebastelt die für V1.1 den Bootloader tauschen kann. Der zu flaschende Bootloader befindet sich in Image.c. Image.c wird aus dem Hex des bootloaders gebaut. Hier die V1.1 mit allen Optionen außer serial ein. in \out gibt es auch noch test_with_loaders.hex. Das ist ein Dummy Prog mit v2.3 loader ab 0x2800 und v1.1 ab 0x3000. Der Dummy kann natürlich später mit irgendwas überschrieben werden. In\tools befinden sich exe Files u.A. eine bereinigte Version des freaders sowie ein Tool um den IAP Mode einzuschalten. Die App ist relativ einfach gestrickt und auf Aarons Stick optimiert (LEDs,Taster) Eine kurze Beschreibung findet sich in den Kommentaren. Das ganze als Keil uVision Projekt. Wie gesagt V1.1 only Thomas
Thomas Z. schrieb: > Ich habe am WE eine App gebastelt die für V1.1 den Bootloader tauschen > kann WOW das ist super cool, werde es heute abend mal austesten und rumspielen. bin gespannt! Habe nun auch rausgefunden wie WCH selber es gemeint hat mit eigenem bootloader brennen, im WCHispTool kann man eine iap datei auswählen und die position derer bestimmen, das wäre dann in diesem falle der bootloader, in dem eigenen programm springt man dann einfach dort hin um den bootloader zu starten. Es wird aber nicht der pin deaktiviert und man kommt immernoch in den echten bootloader, also die verify lücke bleibt immernoch. Hatte da ein beispiel von WCH gefunden wo auch gezeigt wird was man wie in keil einstellen muss um es zum laufen zu bekommen. Aaron.
Aaron C. schrieb: > Hatte da ein beispiel von WCH gefunden wo auch gezeigt wird was man wie > in keil einstellen muss um es zum laufen zu bekommen. Ja das Beispiel kenn ich auch, das ist ursprünglich für den CH559 geschrieben worden. Ich hab das aber nie mit dem WCHIsptool auf dem CH552 zum Laufen gebracht. Das WCHIsptool steckt voller Bugs. Es ist beispielsweise auch nicht möglich ein Hex zu flaschen was nicht bei 0x0000 startet. Hier noch ein paar Infos zum IAP Konzept: IAP muss eingeschaltet werden und danach das Run Bit gesetzt werden. 0xBA, 0x04, 0x57 0xA8 0x00 0x00 schaltet die IAP Funktion ein. 0xA5, 0x02, 0x01, 0x00 setzt das Run Bit. Danach startet das Programm automatisch ab Addresse 0x0000. Das Programm lauft dann mit gesetztem bBootLoad und erlaubt so das Schreiben im Loaderbereich. Das funktioniert so nur mit V1.1 da bei V2.31 der I_CALL in main fehlt. Das ist im wesentlichen das was Thomas T und ich weiter oben diskutiert hatten. Die Quellen des V1.1 loaders hab ich noch mal etwas modifiziert Im wesentlichen ist jetzt am Ende ein Macro drinn was bis 0x7F0 den rest mit 0xFF auffüllt. Das dient hauptsächlich zum binär Vergleich. Funktionell hat sich nichts mehr geändert. Thomas
Thomas Z. schrieb: > sowie ein Tool um den IAP Mode einzuschalten Beim Testen ist mir gestern aufgefallen dass ich den Bootloader zwar mit CALL starten kann, dieser aber sofort wieder beendet wird weil die IAP Kennung noch im Flash steht. Der Start per HW contition funktioniert jedoch problemlos. Man muss also in einem 2. Schritt die IAP Kennung wieder löschen. Schade ich hatte gehofft dass es ohne geht. Da werde ich ev den Bootloader noch anpassen, da ich diesen 2.Schritt einsparen möchte. Thomas
Thomas Z. schrieb: > Schade ich hatte gehofft dass es ohne geht. Da werde ich ev den > Bootloader noch anpassen, da ich diesen 2.Schritt einsparen möchte. um mir selbst zu antworten: Das war natürlich vollkommen um die Ecke gedacht.... Es reicht schon wenn man nach dem Verify einfach die IAP Kennung mit 0xffff,0xxffff überschreibt. Thomas
Thomas Z. schrieb: > Thomas Z. schrieb: >> Schade ich hatte gehofft dass es ohne geht. Da werde ich ev den >> Bootloader noch anpassen, da ich diesen 2.Schritt einsparen möchte. > > um mir selbst zu antworten: > Das war natürlich vollkommen um die Ecke gedacht.... > Es reicht schon wenn man nach dem Verify einfach die IAP Kennung mit > 0xffff,0xxffff überschreibt. > > Thomas Klingt gut den Programmer hat man ja eh gerade dran ohne geht's ja nicht. Was ich mich noch immer Frage ist ob man den USB Host Mode auch beim ch55 2 aktivieren kann müsste mal ch 554 Chips bestellen und sehen was für Config Bytes geschrieben werden oder hat jemand vielleicht einen ch 554?.
ich hab das Programm nochmal etwas umgestellt und lösche jetzt die IAP Kennung sofort nachdem das Programm ein gesetztes bBootLoad erkannt hat. Jetzt funktioniert alles wie ich mir das vorstelle. Im Anhang das geänderte file. @Aaron Die Bits zum aktivieren des HOST modes gibts beim CH552 nicht. Es wird also nicht funktionieren. Thomas
ich hab gestern Nacht mit den beiden Bootloadern rumgespielt. Insbesondere wollte ich meine Loader Extension testen, die hatte ich bisher nur simuliert aber noch nie auf dem Controller getestet. Funktioniert einwandfrei. Bei v2.31 kann man das als Ersatz für den fehlenden I_CALL benutzen. Ich habe mehrmals abwechselnd die Loader auf meinen CH552 geflashed. So weit so gut.... Dann bin ich auf die Idee gekommen das NOP an offset 0x3803 dazu zu verwenden die gesetztn Optionen zu codieren. Die Idee war einen einfachen Weg zu schaffen, die gesetzten Optionen per Softare auslesen zu können. Hat auch funktioniert .... Ich habe jetzt allerdings einen Controller mit deaktiviertem HW Bootloader. Per Software komm ich immer noch rein. Das NOP darf also nicht gelöscht oder verändert werden. Ich habe damit einen zusätzlichen Weg gefunden die HW Aktivierung des Loaders zu deaktivieren. Ich hätte mir das eigendlich denken können, da der Keil von sich aus keinen NOP an der Stelle plazieren würde. Der wurde absichtlich von WCH in den Startup Code plaziert. Thomas
Dies klingt stark nach debugging peripherial wobei der debuggingvector als bootloader genutzt wird. Würde bei otp Sinn ergeben da dann ein patching einfach möglichlççggx wäre. Dies ist bei otp besonders hilfreich.
Angehängte Dateien:
-
rand.png
13 KB
Einen kleinen Hinweis hab ich noch zum V2.31 Loader. Dort wird ja in main der Bootkey mit etwas seltsamen Werten initialisiert. Es ist einfach so, dass dazu die Keil rand () Funktionen genutzt wird.
1 | char Bootkey[8]; |
2 | ...
|
3 | for (i=0;l<8;i++) Bootkey[i] = rand (); |
Thomas
Moin diese Werte sind dann jedesmal gleich? Weil alles an der gleichen Stelle ist? hast du vielleicht den Source Code für dein changer_iap programm für alle ? Hatte das letztens mal ausprobiert aber nicht hundertprozentig verstanden was dort passiert Habe auch ein mehr oder weniger nützliches Projekt mit dem Chip gemacht. Eine Propeller clock die über USB programmierbar ist ist aber eher ein joke project. https://youtu.be/38hobZsm4nM minute 26:00 viele Grüße Aaron
Aaron C. schrieb: > diese Werte sind dann jedesmal gleich? ja rand() erzeugt bei jedem Start die gleiche Folge von Zufallszahlen. Das machen eigentlich alle C Compiler so. Das ist auch der Grund warum man das einfach durch eine fixe Folge ersetzen kann. Aaron C. schrieb: > hast du vielleicht den Source Code für dein changer_iap programm welchen source meinst du? Im zip sollte alles drinn sein. Lediglich compare.c solltest du im Projekt aktualisieren. Oder meinst du was ganz anderes? Thomas
Achso, sorry meite die v1_tools.exe aus dem zip file. Übrigends hatte ich auch noch die idee fals der complete flash beschrieben sein sollte das man dann ja theoretisch nicht die dump variante nutzen kann. dadurch das man aber den dataflash nach belieben schreiben kann kann man auch vorher einen bekanten werd reinschreiben und von da dumpen, auch wenn man es eigentlich eh nicht braucht weil man ja auch den bootloader kennt.
Und noch eine kleine story, es gibt den chip CH9350L von WCH der genutzt wird um usb geräte über eine serielle verbindung miteinander zuverbinden oder seriell zugänglich zu machen. https://lcsc.com/product-detail/USB_CH9350L_C109472.html Dieser kahm mir verdächtig gleich dem CH559, habe vom CH9350L welche bestellt und konnte diesen erfolgreich in Bootlaoder modus setzen und mit der App auslesen, die daraus entstandene HEX datei konnte erfolgreich auf einen CH559 geflasht werden. Auch konnte ich den CH9350L einfach umflashen ^^ Der Dump hat ca. 35Minuten gedauert bei einer dateigröße von ca.45Kb
Aaron C. schrieb: > Übrigends hatte ich auch noch die idee fals der complete flash > beschrieben sein sollte das man dann ja theoretisch nicht die dump > variante nutzen kann. nun ich kann dir versichern, das es mit Versionen die ich kommerziell benutzen werde nichts mehr wird mit dem dumpen. Zum einen benutze ich eine spezielle Version des Verify cmds das im Bootloader Bereich nur noch Error meldet, zusätzlich ist der unbenutzte Bereich im Flash mit Zufallszahlen gefüllt. Der einzige Nachteil ist dass ich zwingend auf Chips angewiesen bin die Initial den den V1.1 loader drauf haben. Es sei denn ich finde doch noch einen Weg in den Original v2.31 loader zu schreiben. Mir ist nicht klar wie du das mit dem Dataflash umgehen willst. Den source der v1_tools lade ich später hoch. Thomas
Ja das war auch eher auf den originalen Bootloader bezogen, wenn man diesen zb. nicht mehr ändern könnte ab v2.31 währe dieser wahrscheinlich auch auf Chips in freier Laufbahn. Bei einem eigenen Bootloader hat man natürlich mehr Möglichkeiten zum Schutz, man könnte bei einem fehlgeschlagenen verify den Chip bis zu einem Reboot z.b. sperren oder ähnlich. Vielen dank aber aufjedenfall!
Anbei die v1_tools. Da sind nicht so viele Komentare drin, das Prinzip sollte aber klar werden. Zusätzlich nochmal compare.c Da hab ich die Entscheidung ob tatsächlich geflashed werden muss in die Flash Routine verlegt und prüfe ab ob es sich um einen CH551 .. CH554 handelt. Thomas
Cool vielen dank! Habs nun auch endlich verstanden, du hattest es ja eigentlich schon etwas weiter oben erwähnt aber ich habe es einfach nicht gecheckt :D
Es wurde ein Test für einen Mikroe-Pascal-Compiler durchgeführt, und bei LED-Blinken und Serien-Comination wird bereits gearbeitet
Aaron C. schrieb: > Dieser kahm mir verdächtig gleich dem CH559, habe vom CH9350L welche > bestellt und konnte diesen erfolgreich in Bootlaoder modus setzen und > mit der App auslesen, die daraus entstandene HEX datei konnte > erfolgreich auf einen CH559 geflasht werden. Ja solche Applikationsprozessoren sind üblich, allerdings wird sowas normalerweise besser geschützt. Ich wette mal, dass der CH340 in Wirklichkeit auch nur ein CH55x ist. Kannst du den Code aus dem CH9350 hier einstellen? Thomas
@Thomas, Ja kann mir das beim CH340 auch vorstellen, habe da auch mal in die richtung versucht was zu finden aber die beschreibung des EEPROM im CH340, das benötigte Hühnerfutter und das Pinout spricht nicht für einen Bekannten chip. Lade die Binary vom CH9350 hier mal hoch auch wenn ich nicht weiß wie das rechtlich aussieht! Auf Hackaday war heute ein Projekt gepostet: https://hackaday.com/2019/10/10/the-next-generation-arduino-nano/ dort wird der CH551 als ISP Programmer mit Serial converter genutzt, bin da auf den Code gespannt, habe den ersteller mal angeschrieben.
Danke ich wollte eigentlich nur mal ausprobieren wie gut das Erkennen von Keil Libs in IDA funktioniert... Funktioniert gut IDA hat auf Anhieb 15 lib Funktionen (small) gefunden. Mal schauen ob's mehr werden wenn ich large wähle. Dieses Flirt ist schon eine feine Sache. Thomas
Hatte das BIN natürlich auch mal in IDA geworfen aber nicht viel gemacht, da ich das was anderes schon in arbeit habe was sehr gut funktioniert. kannst ja gerne, falls du das Programm etwas entschlüsselt hast, hier was zu posten, bin daran trotzdem sehr interessiert.
Angehängte Dateien:
-
flirt.png
110 KB
Hier ein Bildschirmfoto was Flirt auf Anhieb gefunden hat. Zumindest Teile der App sind im large Mode übersetzt. Thomas
@Max, bei welcher application meinst du das? Wenn du ein eigenes programm schreibst ist es möglich ja.
@Aaron: Der Chip wäre an einer USB Port angeschlossen der immer Strom hat. Der Chip würde dann dazu dienen um zu sehen wann das angeschl. Gerät (Notebook) an und wann aus ist (Suspend mode). . LG!
Max M. schrieb: > Der Chip wäre an einer USB Port angeschlossen der immer Strom hat. Der > Chip würde dann dazu dienen um zu sehen wann das angeschl. Gerät > (Notebook) an und wann aus ist (Suspend mode). Ja so ein Device kann man relativ einfach bauen. Es würde aber die USB Spec verletzen da ein USB Device was einen Suspend Befehl bekommt so gut wie keinen Strom mehr aufnehmen darf. Wenn ich mich richtig errinnere ist der zulässige Strom bei Suspend 500uA, zuwenig für eine LED. Thomas
Aaron C. schrieb: > kannst ja gerne, falls du das Programm etwas entschlüsselt hast, hier > was zu posten, bin daran trotzdem sehr interessiert. Ich hab mal etwas in den Code geschaut. Leider haben die Jungs bei WCH das Teil im large Mode übersetzt was die Sache ziemlich unübersichtlich macht. Man kann aber gut die Lücke erkennen, die durch einen Bug im WCH Isptool verursacht wird. Speicher der im Hex undefined ist wird vom Tool mit 0x00 initialisiert. Besser wäre 0xFF damit keine Flashzyklen verschwendet werden Ab 0x8C00 beginnt das IAP Device. Man muss den Code also aufteilen in Normaldevice und IAP device Die Descriptoren werden ins xram kopiert und dort je nach Mode gepatched. So richtig interessant ist der Chip für mich nicht. Der tunnelt einfach HID Tastatur und Maus über eine serielle Schnittstelle. Auf dem Debug Pin werden seriell mit printf ein paar Status Daten ausgegeben Thomas
Der CH559 ist leider etwas sperrig, nicht so übersichtlich wie ein CH552. Das liegt vermutlich daran dass das Teil auch Hub und Host kann. Im Ergebnis ist es so dass die gleichen SFRs unterschiedliche Namen und Bedeutungen bekommen wenn der Host Mode aktiviert wird. Das kann man auch schön im h File erkennen. Ein Beispiel: Im Device Mode gibt es UEP3_CTRL (sfr 0xD3) das gleiche Register heißt im Host Mode UH_TX_CTRL natürlich auch mit anderen bits. Ziemlich hässlich... Ich habe damit begonnen mir den Code ab 0x8c00 anzusehen (IAP im Host Mode) weil mich der Host Mode prinzipiell interessiert. Dabei sind mir ein paar böse Fallen aufgefallen. Im h.file werden die DMA Buffer Addresse explizit nach unint16_t gecastet was bei Keil in Big Endian funktioniert. Wenn ich mich richtig errinnere, ist der SDCC little endian, dort geht das schief. Das h File braucht in jedem Fall einige Anpassungen für den SDC. Zusätzlich hat WCH sehr oft long und int verwendet auch wenn das gar nicht notwendig ist. Der code ist dadurch ziemlich aufgeblasen. Thomas
Cool danke fürs genauer hinschauen. Habe mir eine platine für den CH3950 angefertigt und nutze darauf einen CH559 mit dem code und ein Funk Uart module, dadurch hat man quasi funk usb wenn auch nur HID devices also etwas lächerlich. Aber genau das sollte es auch werden, nen video darüber folgt noch. Ich habe den CH559 unter SDCC am laufen, werde dazu auch noch was veröffentlichen, aber erst später.
Du hast also eine Funk Tastatur/Maus gebaut... Hihi Thomas
Korrekt. Soll eigentlich nur nen joke fürs video sein... also das war beabsichtigt^^ Muss aber sagen, das ganze läuft ohne lags und einwandfrei von anfang an.
Ich werde wohl am Wochenende etwas Code posten. Muss mir erst Mal noch ein paar Makros schreiben damit der Umgang mit den longs übersichtlicher wird. Das ist im Moment eine einzige mov Orgie. Da kann man nichts erkennen. Thomas
Ein kleines Update zu diesem IAP Mode des CH559: Der IAP Mode enumeriert als Host ein abgeschlossenes USB Device (am Port0). Ich habe Hinweise gefunden dass es dabei um ein Diskdevice handeln muss. Class=0x08 Bei WCH heißt das wohl UDISK. Allerdings finde ich dafür keine Descriptoren, es ist also möglich dass diese dynamisch erzeugt werden. Teile des Codes entsprechen im wesentlichen dem was WCH unter usbhost.c in diversen Beispielen zeigt. Wenn ich das richtig interpretiere benutzt der PC folgenden Request um ein Byte an den IAP Host zu senden: 0xA1 0xFE 0x00 0x00 0x00 0x00 0x01 0x00 Das ist ein Class Request mit bRequest 0xFE und einem Byte Daten. Ev ist das ein Verschlüsselungskey da der Request 10 mal ausgeführt wird. Diese Daten werden jedenfalls kräftig durchgeführt. Was danach passiert ist mir noch nicht entgültig klar. Es sind 2 ziemlich lange Funktionen im Code die permanent longs schieben, addieren vergleiche, subtrahieren.... Zusätzlich ist mir aufgefallen dass UH_TX_CTRL bzw UH_RX_CTRL mit Werten beschrieben werden die nicht definierte Bits enthalten. Das halte ich für Fehler die aber wohl keine Rolle spielen. Thomas
Moin, Muss zugeben das ich dir da leider nicht ganz folgen kann. Welchen IAP mode meinst du genau? Als info falls du es noch nicht weißt der CH559 kann ja auch UDISK im Host mode ansprechen, also daten vom usb stick lesen und schreiben. Das aber nur mit einer precompilierten Library, denke aber das du das schon gesehen hast. Grüße
Aaron C. schrieb: > Welchen IAP mode meinst du genau? Der Code den du aus dem CH3950 gepostet hast besteht aus 3 Teilen HID Host Mode, HID Device Mode und eben dem IAP Mode. Ich habe mich auf den IAP Mode konzentriert ab 0x8C00. Der Code ist wohl dazu gedacht die FW zu aktualisieren. Das mit precompiled Libs ist kein Problem die kann ich konvertieren und dann in IDA mit Flirt laden. Dann habe ich die Funktionsnamen und auch Variablen drinn. Thomas
Ahhh nun wird es mir klar!. Ich hatte den Code ja über den ganz normalen Bootloader ausgelesen. Bis du dem IAP teil hatte ich mich nicht vorgewühlt. Komisch das die es dann nicht einfach mit dem Normalen Bootloader nutzen, wo es insgesammt ja nicht so auf security gebaut ist.
Naja dass der Bootloader derart einfach zu hacken ist, war den Jungs bei WCH sicher nicht klar sonst hätten sie kaum den Aufwand mit den Bootkeys getrieben. Ich habe ein PDF gefunden was von IAP Security Keys spricht und es gibt auch spezielle Update Tools. Thomas
Aaron C. schrieb: > Das aber nur mit einer precompilierten Library, Example 12 deckt sich weitgehend mit dem IAP Code und ist im Source verfügbar. Da kann man auch gut erkennen dass die Jungs den Large Mode verwenden. Thomas
Ich hab mich jetzt durch den IAP Code gewühlt und denke dass ich das auch soweit verstanden habe... Der Beispielcode von WCH war da eine große Hilfe. Das Ding funktioniert so dass der Chip im Host Mode initialisiert wird und dann einfach gewartet wird bis ein MemoryStick angesteckt wird. Dieser wird dann enumeriert und im Rootverzeichnis nach einer Datei CH9350_LE.IN oder CH9350L_KM gesucht. Diese wird gelesen und geflashed anschließend macht das Ding einen Softreset. Der Stick muss FAT32 formatiert sein. Die Auswertung des MBR ist ziemlich ineffizient gelöst die Konvertierung Von LSB zu MSB First viel zu umständlich. Gut die Hälfte des Codes macht nichts anderes als ein paar longs aus einem Diskpuffer zu lesen etwas rumzurechnen und die Ergebnisse zu speichern. Ich werde heute Abend zwei Funktionen in Assembler einstellen die Long oder Word Variablen mit Offset aus einem Buffer lesen und die Daten dann MSB First zurück liefern. Damit sollte das Auswerten von MBR und FAT wesentlich einfacher gehen. Benutzer des SDCC brauchen das nicht da der auch LSB first macht. Thomas
@thomas Schade dass die nicht dann gleich uDisk über Seriel mit einprogrammiert haben, aber ich denke das ist deutlich aufwendiger. Habe heute morgen gemerkt( anhand des Schaltplanes) das bei meinem USB-Stick scheinbar USB Plus und USB Minus vertauscht sind. Habe bisher keine Probleme damit gehabt aber musst mal ausprobieren wie es sich verhält wenn man sie vertauscht bzw richtig polt. Wenn ich in meinem autoladeadapter den USB-Stick eingesteckt habe und das Auto starte ist dieser immer in den Bootloader Modus gegangen vielleicht liegt es ja an der Verpolung. Werde es heute Abend mal ausprobieren.
Ok, da muss ich mich selber korrigieren :D Es ist ein fehler in dem Schaltplan, aber nicht auf dem Fertigen PCB. Also Auf dem "USB-Stick" ist nicht plus und minus vertauscht, aber auf dem EasyEda Schaltplan ist wohl das Bauteil nicht ganz richtig. weiß nicht genau was dort schief, bzw, richtig gelaufen ist :D, scheinbar habe ich den USB Connector gespiegelt https://easyeda.com/lolerino/ch552g
Wenn du wirklich USB+ und USB- vertauscht hättest, wäre der Stick nie gelaufen. Vermutlich das übliche Stecker Buchse Problem. Das der Stick im Auto in den Loader Mode geht, liegt vermutlich daran, dass im Ladegerät Widerstände verbaut sind um ein Ladegerät zu melden. Ich habe übrigens angefangen UDisk zu überarbeiten. Ich bin überzeugt dass man das wesentlich kürzer hinbekommt. Das Original belegt immerhin ohne Debug 6KByte Rom und sehr viel XRam. Warum der Bootloader bei 0xF400 startet und nicht bei 0xF800 hab inzwischen auch verstanden. Das liegt ganz einfach daran, dass der CH559 gelöscht werden muss (1k Blöcke) und da die ans Ende Config Infos schreiben, mussder letzte Block vorher gelöscht werden. Es stehen für den Loader also praktisch auch nur 4k zur Verfügung die restlichen 2k kann man nicht nutzen. Thomas
hier erst mal ein Assembler modul für Keil, was in der Lage ist longs / und Words in LSB first auzulesen und in MSB first zurück zu liefern. WCH macht das folgendermasen:
1 | ...
|
2 | CH559vSecMBR = ((uint32_t)UDiskTmp[offset+11]<<24) |
3 | |((uint32_t)UDiskTmp[offset+10]<<16) |
4 | |((uint16_t)UDiskTmp[offset+9]<<8) |
5 | | UDiskTmp[offset+8]; |
6 | ...
|
mit dem Asm Modul wird das wesentlich efektiver. Beim SDCC geht das ganze natürlich direkt.
1 | ...
|
2 | CH559vSecMBR = SwapReadLong(UDiskTmp,offset+8); |
3 | ...
|
Thomas
Da mir der UDisk Code von WCH dann doch etwas zu undurchsichtig war habe ich die relevanten Funktionen für den PC portiert und damit einen MemoryStick angesprochen. Funktioniert soweit ganz gut lediglich an den MBR komme ich nicht ran, da ich Fehlermeldungen erhalte wenn ich den Stick als PhysicalDrive öffnen will. Auf drive no Ebene kann ich Sektor für Sektor lesen und finde auch das File bezogen auf den Partition Start. Soweit so gut nun zu den Problemen. Die Flashfunktion IAP_PROM() ist m.M. nach Buggy. Die schreibt jeden Sektor des Fileinhalts an die gleiche Addresse. Prog_Word() ermittelt die Startadresse von Prog_Word() und justiert den Flashbefehl so dass dieser immer an einer ungeraden Adresse steht. Welchen Sinn das genau hat habe ich noch nicht rausgefunden. Mehr dazu wenn ich den Code vollständig habe. Thomas
Hier nun der Code für den PC um lowlevel auf einen Memory stick zuzugreifen. Der source ist ausführlich kommentiert, die Funktion sollte also klar sein. Der Code besteht aus 2 Teilen: Teil 1 dient der Simulation und emuliert einige Funktionen. Teil 2 enthält den Code der auch auf dem CH559 zum Einsatz kommt. Diser Teil enthält einige Optimierungen für 8 Bit Compiler. Einige dieser Stellen sind durch Kommentare gekennzeichnet. Auf einem PC würde man einiges wohl anders lösen. Alle globalen Variablen enthalten keil spezifische Modifier die auf einem PC Compiler in nichts umdefiniert werden. Die FAT32 spezifischen Buffer Offsets sind in fat32.h definiert Thomas
Das ist ziemlich cool ! Finde ich gut :) Habe es mir gerade mal grob angesehen, versucht mit mingw zu kompilieren aber das funktioniert nicht so richtig, werde es nochmal mit Borland probieren.
Du hast gesehen dass fat32.h in einem \inc directory liegen muss? Das ist Teil meiner Keil Folder Struktur. Was für Fehler bekommst du unter mingw? Der Code sollte sich übersetzen lassen solange eine windows.h existiert. Das ist notwendig damit Createfile() und SetFilePointer() funktionieren. Thomas
Noch ein Nachtrag: Wenn man den Stick an Libusb oder WinUsb bindet kann man sehr wahrscheinlich alle Funktionen Low Level abbilden. Der Stick wird sich dann aber vermutlich nicht mehr als Memory Device am PC anmelden lassen. Auf diese Art der Emulation habe ich bisher bewusst verzichtet. Das schien mir dann doch etwas zu aufwendig zumal dann auch das Installationsproblem hinzukommt. Thomas
Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller (Musikinstrument) anzuschließen und auszuwerten?
Audiomann schrieb: > Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller > (Musikinstrument) anzuschließen und auszuwerten? Ja, wenn du den Code dazu selbst schreibst. :) Aber USB-MIDI ist ein sehr einfaches Protokoll: es gibt einen Bulk-Endpoint, über den die MIDI-Nachrichten gesendet werden, verpackt in 32-Bit "USB-MIDI Event Packets" (siehe Kapitel 4 der USB-MIDI-Spezifikation).
Audiomann schrieb: > Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller > (Musikinstrument) anzuschließen und auszuwerten? Sich mit diesem Chips zu beschäftigen ist rausgeworfene Zeit. Hast du Zeit zu verplempern?
Audiomann schrieb: > Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller > (Musikinstrument) anzuschließen und auszuwerten? Das hängt davon ab ob du ein UsbMidiDevice oder einen UsbMidiHost bauen willst. Device geht auf jedem der CH5xx Controller. Host theoretisch auf dem CH554 der aber vermutlich zuwenig RAM und Flash hat. Da ist der CH559 besser geeignet. Ein Beispiel für ein UsbMidiDevice habe ich weiter oben gezeigt.
Ehrlich gesagt kann ich nicht ganz nachvollziehen warum man sich die Informationsschwierigkeiten mit einem ganz fern hergestellten Produkt antun will. Da hat man es mit Produkten westlicher Hersteller wesentlich besser. Bei uns gibt es Datenblätter, App. Notes und Debug/Programmier Tools in Hülle und Fülle. Auch besteht oft eine nützliche große User Community. Hat das wirklich sinn, oder ist das ähnlich wie "Ich habe Mt. Everest erstmal bestiegen" wo halt der Weg das eigentliche Ziel und Spass an der Freude die Hauptmotivation ist? Irgendwie will mir der Sinn des Ganzen nicht ganz in den Kopf.
Der Gespensterreiter schrieb: > Irgendwie will mir der Sinn des Ganzen > nicht ganz in den Kopf. Das wurde ganz oben im Thread schon ausgiebig diskutiert. Im Grunde hast Du Dir die Antwort aber schon selber gegeben.
Ein kleines Update zu UDisk Emulation: Ich habe heute einen alten 1GB Stick, den ich sowieso nicht mehr benutze, genommen und mal probehalber mit zadig an libusb gebunden. Wie erwartet taucht der Stick dann nicht mehr als Laufwerk auf und ich konnte LL die ersten Kommandos absetzen. Auf diese Weise kann man den kompletten Host Mode abbilden und die Firmware auf dem PC emulieren. Mal schauen was daraus wird. Thomas
@thomas. Ja die .h datei habe ich im code geändert aber trotzdem wollte es nicht. Eine richtige fehlermeldung gibt es leider nicht. GCC gibt 2 minuten lang den inhalt diverser dateien aus. Weiß noch nicht richtig was da schief läuft
Aaron C. schrieb: > GCC gibt 2 minuten lang den inhalt diverser dateien aus. Weiß noch nicht > richtig was da schief läuft Das kann eigendlich nur eine Ursache haben: CreateFile() oder SetFilePointer() macht bei dir was falsch. Bau ans Ende von UDisk_ReadOneSector() mal ein Exit() ein. Und gibt ein paar zusätzliche Statusmeldungen aus. Den Code hab ich StackOverflow geklaut. Dann sollte schnell Klarwerden was da nicht so richtig will. Alternativ kannst du die Ausgaben auch in ein Log umleiten und dann die ersten Zeilen genauer betrachten. Thomas
Götz schrieb: > Sich mit diesem Chips zu beschäftigen ist rausgeworfene Zeit. Hast du > Zeit zu verplempern? Ganz sicher nicht, daher hatte ich ja die USB-Fachmänner kurz befragt, ob sich ein Befassen mit diesem Chip lohnen könnte. Thomas Z. schrieb: > Audiomann schrieb: >> Kann man diesen Chip dazu verwenden, einen USB-MIDI-Controller >> (Musikinstrument) anzuschließen und auszuwerten? > Das hängt davon ab ob du ein UsbMidiDevice oder einen UsbMidiHost bauen > willst. Wenn schon, dann host! Der Chip muss den Musik-Controller ja erkennen und bedienen, also anfragen, Daten holen und zwischenspeichern und gfs auch welche senden. Einige haben LEDs, welche Zustände zeigen. Der Gespensterreiter schrieb: > Da hat man es mit Produkten westlicher Hersteller wesentlich > besser. Beispiel?
@thomas Hatte auch an die ersten zeilen geschaut aber selbst da war keine fehlermeldung. Nun wollte ich davon ein screenshot erstellen und siehe da, es compilliert ohne probleme. und auch das programm läuft, nun muss ich mir auch einen usb stick raussuchen. Witziger weise habe ich nähmlich genau vor einer woche damit angefangen auf dem pc gcc zu testen und dann kommst du :D @Audiomann Ein Midi Host ist machbar mit dem CH559 (wohl auch CH554, wie thomas aber schon sagte etwas wenig ram und der Preisunterschied ist nicht groß) Und der Einwand von Götz ist komisch, man hat wenn man bei einem Bare Chip anfängt die gleiche arbeit vor sich ob nun dieser oder ein anderer USB host Chip, wenn man eine Komplett Lösung kauft ist es natürlich was anderes.
@Aaron freut mich dass es jetzt bei dir tut. Ich bekomme mittlerweile meinen Stick mit libusb genauso enumeriert wie das UDisk macht. Die MaxLun Geschichte geht auch schon, ich verstehe allerdings nicht warum WCH das Kommando 10 mal absetzt. Heute habe ich das BulkOnly Cmdset implementiert das hat aber noch Fehler. @audioman Lad mal diese zip von WCH da ist auch was für Midi dabei. http://wch.**/download/CH559EVT_ZIP.html und http://www.wch.**/public/uploads/file/20180207/1517992523119473.rar **durch cn ersetzen Thomas
Eine neue Version der UDisk Emulation dieses mal für libusb Thomas
Ich habe jetzt die IAP Firmware von WCH basierend auf den Simulationsergebnissen in 5 Files aufgeteilt. Dies vor allem vor dem Hintergrund dass ich daraus auch eine Lib bauen will und Host Code vom UDisk Code trennen will. Damit sollte es dann möglich werden mit wenigen Änderungen auch etwas andere als einen Stick zu enumerieren. Speziell wenn man eine Lib bauen will ist es sinnvoll Funktionen in seperaten Files zu legen, damit später der Linker nicht unbenutzte Funktionen zum Programm linkt. Jede einzelne Funktion in ein separates File zu legen ist dann aber etwas zuviel des guten. Das klappt schon ganz gut der Code belegt im Moment um die 4Kbyte. Variablen passen gerade so ins data Segment. Das idata Segment ist noch komplett frei. Im xdata sind 2x64 Byte für USB und 512 Byte für den Sectorbuffer belegt. Wenn es bei den 4k bleibt kann also das zu flashende File max 56kbyte haben. Es würde sich folgende Memory Map ergeben: 0x0000 .. 0xDFFF Anwender Code 0xE000 .. 0xF3FF UDisk/IAP 0xF400 .. 0xFFFF Bootloader Thomas
folgender Code (Keil C51)
1 | uint8_t IAP_ProgWord(uint16_t Addr,uint16_t Data) |
2 | {
|
3 | ROM_ADDR = Addr; |
4 | ROM_DATA = Data; |
5 | if (ROM_STATUS & bROM_ADDR_OK) |
6 | {
|
7 | if ((uint8_t) &IAP_ProgWord & 0x01) |
8 | {
|
9 | ROM_CTRL = ROM_CMD_PROG; |
10 | _nop_(); |
11 | }
|
12 | else
|
13 | {
|
14 | _nop_(); |
15 | ROM_CTRL = ROM_CMD_PROG; |
16 | }
|
17 | return((ROM_STATUS ^ bROM_ADDR_OK) & 0x7F); |
18 | }
|
19 | else return(bROM_ADDR_OK); |
20 | }
|
was der Code macht ist soweit klar. Er sorgt dafür, dass ROM_CTRL = ROM_CMD_PROG; immer an einer ungeraden Addresse steht auch wenn die Funktion durch den Linker auf eine ungerade Addresse plaziert wird. Das kann man sehr gut im lst file sehen. Im Original von WCH gibts an der Stelle natürlich auch keinen Kommentar(auch keinen chinesischen). Meine Frage ist jetzt eher: Wie kommt man auf die Idee sowas zu programmieren? Kann sich jemand einen Grund vorstellen warum das Komando an einer ungeraden Addresse stehen muss? Bei allem was ich über den Chip weiss, könnte ich mir eher vorstellen dass es eine gerade Addresse sein muss. Dann wäre die Logik aber genau falsch rum. Ich habe natürlich bei WCH auch angefragt aber keine sinnvolle Antwort erhalten. Meiner Meinung nach ist es kompletter Mist sowas zu programmieren. Ohne Blick ins Assembler File kann man nicht sagen wie das übersetzt wird und bei der kleinsten Anderung der Funktion muss man wieder neu nachschauen. Ich habe keine Option gefunden dem Linker mitzuteilen eine Funktion an eine gerade Addresse zu linken. Kann sich jemand einen Reim daruf machen? Thomas
An Aaron C., bin sptiz drauf die Teile auch mal zu testen. Jetzt meine Frage: musstest du um die dinger anzuholen zum Zoll? Hätte keine wirklcihe lust da meinen Tag zu verschwenden. Es dauert immer ewig und ist echt nervtötend. Man wartet ne halbe ewigkeit und dann nervt der Zoll wegen irgendetwas rum. Grüße Frank
Frank Gießner schrieb: > Jetzt meine Frage: musstest du um die dinger anzuholen zum Zoll? Moin, ich habe sie bei lcsc per express bestellt, vor nem jahr oder so gab es mal eine änderung bei DHL das die dass für dich verzollen, wenn rechnungsbetrag größer 22€. Dieser servie kostet 12€ + mwst. Mit LCSC hatte ich noch keinerlei problem mit zoll und vorgeladen werden. Wenn du nur ein paar bestellt bist du ja eh unter der zollgrenze und raus. Wenn du aber willst kann ich dir für einen obulus welche per brief senden, habe noch ca. 370 Stück der CH552G Bootloader Version 1.1 @Thomas, bist du eigentlich auch mal Thomas(Gast) gewesen? oder irre ich mich da? etwas verwirrent :D Es wurde die Tage das M5Stack II und der M5StickC mit CH552T als USB to Seriall converter ausgemacht. https://m5stack.com/products/stick-c auf beiden Läuft dieser code: https://github.com/diodep/ch55x_esp
Nö du irrst dich nicht, ich war lange Zeit auf mc net nur als Gast unterwegs. Es gibt zwar auch noch andere Thomas Gäste aber in diesem Thread ist das nur von mir. Seit etwa einem halben Jahr poste ich fast nur noch von meinem Tablet und deshalb auch angemeldet. Thomas
Ok danke, wollte nur komische Situationen vermeiden :D
Aaron C. schrieb: > Wenn du nur ein paar bestellt bist du ja eh unter der zollgrenze und > raus. > > Wenn du aber willst kann ich dir für einen obulus welche per brief > senden, habe noch ca. 370 Stück der CH552G Bootloader Version 1.1 Hallo, danke für die schnelle Antwort! Wollte aber noch etwas anderen krimms kramms von der Seite kaufen. Also besten dank für das Angebot! Ich denke ich versuchs einmal mit ner Bestellung dort. Hab die erfahrung gemacht das zumindest hier in Bayern alles was als Päckchen aus dem Ausland ankommt - das man dann zum Zoll muss. Musste schon mal wegen einem 5 Euro (5,99 Versand) Teil zum Zoll nur weil es als Paket verschickt wurde mit "echter" Seundungsnummer. Haßt du auch erfahrung mit anderen MCs von der Seite? Grüße Frank
Hab ich gerade gefunden. Da übersetzt wohl jemand das Datenblatt zum CH559. Die Qualität scheint gut zu sein, es sind aber erst die ersten 7 Kapitel online. https://github.com/kprasadvnsi/CH559_Doc_English Thomas
Hallo Thomas, cool, aber ich Frag mich sowieso wieso die Datenblätter nur auf Chinesisch und nicht auf Englisch erhältlich sind. So als ob die Chinesen die diesen Chip entwickelten kein Englisch können. Was ich ja überhaupst nicht glaube. Grüße Frank
Du bist halt nicht die Zielgruppe. Das sind asiatische Firmen, die so Sachen für 2$ entwickeln wollen.
Hier nun meine Interpretation der UDisk sourcen von WCH. Das ganze ist noch nicht perfekt und für Keil only. Im zip befinden sich insgesamt 3 Projekte: - disk_iap was die Integration der Lib zeigt und nach 0xE000 linkt. - disk_test was alle Module include und nach 0x0000 linkt - udisklib zum compilieren der Lib. Im udisk_test ist ein globales define TESTCODE gesetzt was an alle Module weiter geleitet wird. Damit wird printf gesteuert und in IAP das flashen gesperrt. disk_Iap benutzt modifizierten startupcode und der Linker platziert den Code ab 0xE000 Es sind noch etwa 400 Bytes unbelegt. Thomas
Angehängte Dateien:
-
ch559_brkout.png
140 KB
Mein Testboard ist angekommen und ich hab gleich mal bestückt. 0.5mm Pitch ist nichts mehr für meine Augen. Einen Fehler hab ich auch gleich gefunden: Entgegen dem Datenblatt ist Der RST Anschluss high (ohne Pulldown) zumindest solange keine FW auf dem Chip ist ist also P5.7 kein frei benutzbarer Portpin sondern mit RST belegt. Der fehlende Pulldown verhindert zuverlässig das Anlaufen des Bootloaders. Abhilfe 10k gegen Gnd. Leider hab ich auch S2 an dem Port Pin hängen den kann man also nicht benutzen. Wenn das Ding getestet ist werde ich Eagle Files einstellen Thomas
ich hab mich mal etwas mit der Seriennummer des CH559 beschäftigt. Der Zugriff auf diese Nummer ist etwas seltsam. Man muss E_DIS = 1 setzen und dann 8 bytes mit MOVC ab 0x020 lesen. Das ist zumindest der von WCH dokumentierte Weg. Tatsachlich ist aber so, dass die SN über den gesammten Flashrombreich gelesen werden kann. Sie wiederholt sich alle 256 Bytes. Es sind zusätzlich auch noch ein paar undokumentierte Bytes definiert.
1 | c:0000 FF FF FF FF 0A FA 93 FF FF FF FF FF FF FF FF FF |
2 | c:0010 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
3 | c:0020 05 5A A3 54 00 00 A8 AE FF FF FF FF FF FF FF FF |
4 | c:0030 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
5 | c:0040 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
6 | ... |
7 | c:0100 FF FF FF FF 0A FA 93 FF FF FF FF FF FF FF FF FF |
8 | c:0110 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
9 | c:0120 05 5A A3 54 00 00 A8 AE FF FF FF FF FF FF FF FF |
10 | c:0130 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
11 | c:0140 FF FF FF FF FF FF FF FF F8 5A FF FF FF FF FF FF |
12 | ... |
13 | ... |
Man kann z.B auch sehen das zumindest bei mir nur 32Bit der SN definiert sind und nicht 48 Bit wie im Datenblatt beschrieben. Das ist vermutlich auch der Grund warum WCH schreibt man soll nur die ersten 32bit benutzen. Thomas
Mit Bitluni von Bitlunislab ist nun das folgende projekt rausgekommen. Mittels des CH559 ist ein uart interface entstanden an dem diverse andere controller angeschlossen werden können, im beuspiel ein esp32 und Arduino. Auch ist eine verarbeitung auf dem CH559 möglich dazu kann man den source code nach seinen bedürfnissen ändern. https://youtu.be/Th88RiSmj2w
Ich hab den Bootloader des CH559 jetzt an die anderen Loader angeglichen. Wieder lassen sich verschiedene Optionen ein und ausschalten. Der Code ist ausführlich kommentiert. Ohne Optionen entspricht der Code dem Original sofern die Startaddresse auf 0xF400 steht. Dieser Loader ist geeignet für CH558/CH559. Es gibt in main eine Abfrage auf ID 0x57 keine Ahnung was für ein CHip das ist. Ich hab bei WCH jedenfalls keinen CH557 gefunden. Das Header File ist gleich geblieben und weiter oben zu finden. Thomas
Ich find das ganz spannend was ihr hier macht. Bin nach dem heutigen Video von bitluni auf diesen Thread gestoßen. Ich hab ehrlich gesagt nur die Hälfte alle Beiträge gelesen da es inzwischen echt viele sind. Trotzdem würde ich gerne 3 Fragen stellen: 1. Welchen Vorteil hat euer eigene Bootloader? Benötigt er weniger Flash-Speicher? Funktioniert er ohne das WCHISP-Tool? 2. Kann man sich den USB-Bootloader sparen und so den freigewordenen Flash nutzen indem man die CH55x stattdessen mit einem "echten Programmiergerät" programmiert? Gibt es Informationen dazu, wie das funktioniert? Hat es schon jemand getestet? 3. Was ist der Unterschied zwischen XRAM und iRAM? Grüße
Ich antworte mal: Der Bootloader hat mmer noch die Original Funktionalität. Er wurde nur optimiert um Platz für zusätzliche (andere) Funktionen zu schaffen. Das WCHIsptool war schon immer nur eine von mehreren Möglichkeiten. So hat Aaron zB. einen Flasher für Android geschrieben. Da die API unverändert ist, kann man auch Erweiterungen realisieren. So habe ich zB ein Tool geschrieben was auch ab einer Startadresse<>0 flashen kann. Ja man könnte den Controller extern per SPI flashen. Das geht aber nur in der Theorie. WCH hat das SPI Verfahren nicht offengelegt. Praktisch existiert diese Möglichkeit also nicht. XMEM und IMEM sind Begriffe aus der x51 Welt. Etwas vereinfacht: IMEM ist der interne Controller Speicher (max 256 Bytes).XMEM ist externer Speicher. Beide Speicher existieren parallel, da sie unterschiedlich angesprochen werden. Thomas
Vielen Dank für deine Antwort Thomas! Thomas Z. schrieb: > XMEM und IMEM sind Begriffe aus der x51 Welt. Etwas vereinfacht: IMEM > ist der interne Controller Speicher (max 256 Bytes).XMEM ist externer > Speicher. Beide Speicher existieren parallel, da sie unterschiedlich > angesprochen werden. Macht das einen Unterschied für den C-Entwickler? Oder handelt das der Compiler und man hat dann insgesamt 1.25kByte?
Max M. schrieb: > Vielen Dank für deine Antwort Thomas! > > Thomas Z. schrieb: >> XMEM und IMEM sind Begriffe aus der x51 Welt. Etwas vereinfacht: IMEM >> ist der interne Controller Speicher (max 256 Bytes).XMEM ist externer >> Speicher. Beide Speicher existieren parallel, da sie unterschiedlich >> angesprochen werden. > > Macht das einen Unterschied für den C-Entwickler? Oder handelt das der > Compiler und man hat dann insgesamt 1.25kByte? Man muss schon beim Programmieren angeben welche Daten man in welchen RAM haben möchte. Man hat am Ende aber trotzdem 1,25kByte. Soweit ich das verstanden habe wird alles was nicht extra benannt wird in den internen RAM gespeichert und dort wo man __xdata mit angebt wird es im externen RAM gespeichert. So ist es zumindest bei SDCC
Max M. schrieb: > Macht das einen Unterschied für den C-Entwickler? Oder handelt das der > Compiler und man hat dann insgesamt 1.25kByte? Der C Compiler kennt erst mal nur den internen Speicher. Dieser ist noch weiter aufesplittet. Es gibt da noch mehr Segmente. In diesem Speicher liegt der Stack und die Variablen. Wenn man im Large Mode übersetzt platziert der Linker die Variablen im XMEM. Das ist aber wesentlich langsamer. Zusätzlich kann jeder Var per modifierer auch die Platzierung mitgegeben werden. Das funktioniert unabhängig vom Memory Model. Bedenke der core stammt aus den 80er Jahren. Damals hat man sich noch nicht so viele Gedanken um C gemacht. Wenn du also keine Erfahrung mit einem 8051 hast würde ich dir nicht empfehlen jetzt noch damit anzufangen. Die cores sind zwar immer noch weit verbreitet, heutzutage gibt es aber wesentlich bessere Designs. Eine der Stärken würde ich beim x51 im boolean Prozessor sehen. Es gibt Befehle um direkt mit bits zu arbeiten. Das bietet in dieser Form m. Wissens keine andere MCU. Thomas
Anbei die Eagle Files meines CH559 Breakout Boards. Das Design ist generell auf .2mm Abstand geroutet. Es gibt aber einige Engstellen wo der DRC nur mit .15mm durchläuft. USB Buchse und Taster gibt's bei Reichelt. Die Platine hab ich bei Aisler machen lassen. Das funktionierte in 2 Tagen völlig problemlos. Das nächste Mal würde ich allerdings ENIC wählen und lieber 7 Tage warten. Die gezeigte Version hat schon die korrigierte Resetbeschaltung beim Flashen muss man darauf achten, dass D+ als Bootpin eingestellt ist weil ich an P4.6 keinen Taster dran habe. Falls man das nicht umstellt muss man hinterher seriell flashen Thomas
Aaron C. schrieb: > Mit Bitluni von Bitlunislab ist nun das folgende projekt rausgekommen. > ... > Youtube-Video "Usb mouse and keyboard on Arduino, CH559 cheap usb host > chip" Danke für das Video. Woher und zu welchem Preis hast du die Controller im Tray bezogen? Ich kann nur einen einzigen Anbieter bei Ali finden, nirgendwo sonst.
Prima, vielen Dank!
Das Ganze erinnert mich übrigens an die Hacks der digitalen Bilderrahmen mit dem "AppoTech AX206" mit ähnlicher Ausstattung. http://openschemes.com/wp-content/uploads/2011/08/X206spec.pdf Es sind auch schon einige Threads hier im Forum. Vielleicht kann man auch was von den Codes in den diversen Repos wiederverwenden oder wenn es auch nur die Idee eines externen Displays für irgendeine headless black box ist.
Habe mich die tage nochmal hingesetzt und ein flashing script in Python für die CH55x Familie geschrieben. https://youtu.be/uhSHcyjUaic Dieses kann Bootlaoder version 1.11 und 2.31 Da beim entwickeln immer zwischen VirsualStudio und dem WCHISPTOOL gewechselt werden musste ist es mit dem tool nun eine ein click lösung, also compile.bat aus dem ch559 code ausführen der code wird compiliert und gleich auf den CH micros geflasht.
Sehr cool! Eine Frage von mir: Lustigerweise kostet der CH552 genauso viel wie der CH340G, der oft als USB/UART-Bridge verwendet wird. Kann man den CH552 so programmieren, dass er auch als USB/UART-Bridge fungiert und damit z.B. einen ESP8266 flashen? Dan hat man quasi immer einen kleinen uC mit an Board, USB<->UART braucht man beim ESP ja sowieso.
Max M. schrieb: > Kann man den CH552 so programmieren, dass er auch als USB/UART-Bridge > fungiert und damit z.B. einen ESP8266 flashen? Dan hat man quasi immer > einen kleinen uC mit an Board, USB<->UART braucht man beim ESP ja > sowieso. Moin, ja das funktioniert genau so. es wird auch schon bei dem M5Stack in massenproduktion eingesetzt. Eine opensource firmware gibt es hier: https://github.com/diodep/ch55x_esp
Vielen Dank für die schnelle Antwort! Sehr schön, dass es da schon was fertiges gibt. So ganz verständlich ist der Code allerdings meiner Meinung nach nicht (vor allem die Funktion "Device-Interrupt"). Ist auch mehr Code als ich ursprünglich dachte. Scheint also doch mehr Arbeit gewesen zu sein, das zu reverse engineeren.
Ja es ist wirklich schwer leserlich, der code ist aber auch sehr unordentlich und vom original WCH example nur verändert. Ich habe mich da langsam rangetastet und stückchenweise den code angepasst, also nicht diesesn speziellen code sonder grundsätzlich. Was ich gerade für die ESPs interessant finde ist die "integrierte" Reset und GPIO0(bootloader) funktion die ein paar teile einsparen kann wenn man das implementiert. Auch gibt es dieses projekt: https://hackaday.io/project/167339-a-new-nano Dort wurde eine ISP Programmer für AVR micros auf dem CH552 Gebastelt, inklusive USB zu Seriell Converter, der Code vom dem Projekt ist deutlich aufgeräumter da von null selber geschrieben.
Aaron C. schrieb: > Ich habe mich da langsam rangetastet und stückchenweise den code > angepasst, also nicht diesesn speziellen code sonder grundsätzlich. Ich denke, dass ist die beste Vorgehensweise. Bringt ja nix, wenn ich meine Features einbauen möchte, aber den restlichen Code nicht verstehe. Macht Sinn, den IC von Grund auf verstehen zu wollen. Aaron C. schrieb: > Was ich gerade für die ESPs interessant finde ist die "integrierte" > Reset und GPIO0(bootloader) funktion die ein paar teile einsparen kann > wenn man das implementiert. Das stimmt, soweit ich weiß wurde das auf den Wemos D1 Mini mit zwei Transistoren gelöst. Findet man via Google "Wemos Reset Circuit". Edit: Etwas Off-Topic, aber vielleicht interessant für die USB-Begeisterten: Von Nordic Semi gibt es einen IC, der einen 8051 uC (16MHz, 16kByte Flash 2kByte SRAM) mit einem USB-Device Controller und einem 2.4GHz RF Transceiver Modul (weder WLAN noch Bluetooth) vereint: https://www.rcscomponents.kiev.ua/datasheets/nrf24lu1-f16q32-t.pdf Programmiert werden kann der laut Datenblatt auch über einen vorprogrammierten USB-Bootloader (der ist futsch sobald das User-Program in den Bootloader-Adressbereich hineinwächst). Ansonsten wird ein PROGEN-Pin high gezogen und über ein Slave-SPI der interne Flash programmiert. Damit kann man z.B. sowas lustiges machen: https://www.bartslinger.com/electronics/nrf24lu1-usb-dongle/ Die Keil µVision IDE kennt den Chip bereits und bietet dafür eine Header-Datei an. Kostet auf Taobao 0.50€ / Stück. Gibts leider nur im QFN32-Package mit maximal 6 nutzbaren GPIOs.
Aaron C. (atc1441) hat mir ein paar CH55x zukommen lassen und ich habe mal einen Blick auf die Dies des CH551 und des CH552 geworfen: https://richis-lab.de/CH55x.htm Es scheint sich um die gleichen Dies zu handeln. Wahrscheinlich werden beim CH551 schlicht gewisse Funktionen deaktiviert. Mal sehen was in den anderen Varianten noch steckt. Grüße, Richard
Vielen vielen dank!!!
Danke! Richard K. schrieb: > Es scheint sich um die gleichen Dies zu handeln. Wahrscheinlich werden > beim CH551 schlicht gewisse Funktionen deaktiviert. Jetzt stellt sich die Frage: Sind diese Funktionen deaktiviert, und können theoretisch aktiviert werden, oder sind da Teile der Chips Produktionsbedingt bereits kaputt, und werden deaktiviert? Ich meine die Preise sind extrem tief, da könnte es doch auch sein, dass da die Fertigungsqualität schlechter ist. Da wird getestet, und wenn etwas nicht geht, wird alles deaktiviert, und als CH551 verkauft?
Andreas B. schrieb: > Danke! > > Richard K. schrieb: >> Es scheint sich um die gleichen Dies zu handeln. Wahrscheinlich werden >> beim CH551 schlicht gewisse Funktionen deaktiviert. > > Jetzt stellt sich die Frage: Sind diese Funktionen deaktiviert, und > können theoretisch aktiviert werden, oder sind da Teile der Chips > Produktionsbedingt bereits kaputt, und werden deaktiviert? > > Ich meine die Preise sind extrem tief, da könnte es doch auch sein, dass > da die Fertigungsqualität schlechter ist. Da wird getestet, und wenn > etwas nicht geht, wird alles deaktiviert, und als CH551 verkauft? Das ist die Frage... Ich vermute, dass die Prozesse mittlerweile so gut sind, dass bei so relativ kleinen Controllern der Ausschuss sehr gering ist und entsprechend schlicht verworfen wird. Hat man Ausschuss, so müsste man da ja erst mal testen was genau kaputt ist und ob sich das Die noch als CH551 eignet. Das wird sich nicht rentieren. Dann bleibt noch die Frage ob die Funktionen über HW oder SW deaktiviert wurden. Bei gröberen Strukturen hat man oftmals Fusible Links verwendet. Bei einem Mikrocontroller würde ich eher vermuten, dass es SW-Fuses, also Speicherzellen sind, die konfiguriert werden. Ob man an diese Speicherzellen noch einmal ran kommt und wie man da hin kommt müssen die SW-Cracks herausfinden... :) ...hilfreich wäre es wahrscheinlich die Metalllagen zu entfernen und das ganze Die zu analysieren. Das übersteigt aber meine Fähigkeiten...
Ich denke es währe vor allem die frage ob der CH554 auch das gleiche DIE hat, die funktionen von CH551 und CH552 unterscheiden sich ja nur minimal, beim CH554 kommt ja noch USB Host hinzu. Ich denke nur dann lohnt es sich dahinter zu schauen. P.s. Richard, du hast ein paar mal im text auf deiner website die Zahlen vertauscht wollte es nur einmal erwähnt haben
Der CH554 ist schon durch den Ofen gegangen. Fotos muss ich noch machen. :) Danke für den Hinweis zu den Schreibfehlern. Zweimal "511", richtig? Habe ich korrigiert.
Ich hab mal wieder etwas programmiert... rausgekommen ist ein kleines Konverter Tool um Intel Hex Dateien zu konvertieren. Das besondere ist, dass der Speicher mit Zufallsdaten initialisiert werden kann. Das Tool kennt alle WCH CPUs und erzeugt per Default ein Abbild des kompletten Userflashs. Das ist insbesondere dann hilfreich wenn ein modifizierter Bootloader mit abgeschaltetem Verify im Loaderbereich verwendet wird. Damit ist ein zurücklesen der Daten unmöglich Vorbereitet aber noch nicht implementiert ist das encrypting des Files(speziel für uDisk) sowie das automatische flashen. Die Größe der Ausgabedateien kann optional auch limitiert werden. Beispiel: wch_tools -iBlablub.hex -f+ -c0x52 -l0x2000 erzeugt firmware.hex und firmware.bin mit limitiert auf 8kB. Wenn euch noch was ein oder auffällt schreibt einfach. Thomas
Guten Morgen! Jetzt habe ich auch den CH554 und den CH559 online: https://www.richis-lab.de/CH55x.htm Der CH554 mit seiner USB-Host-Funktionalität nutzt tatsächlich das gleiche Die wie der CH551 und der CH552. Das bedeutet, dass höchstwahrscheinlich auch die USB-Host-Funktion bei allen Varianten grundsätzlich vorhanden ist. Der CH559 ist gänzlich anders aufgebaut. Grüße, Richard
Richard K. schrieb: > Jetzt habe ich auch den CH554 und den CH559 online: Die Bilder sind echt cool danke dafür. Bezüglich der Konfiguration: Es gibt ein Byte im Config Bereich was nicht dokumentiert ist, es ist das Byte an der Addresse 0x3FFA. Das ist bei mir (CH552) immer 0x65 und gehört nicht zur Seriennummer. Lt Doku kann der Bereich nur per SPI programmer beschrieben werden was ich persönlich nicht glaube. Es wäre interessant was dort bei einem CH551 oder beim CH554 steht. Thomas
Thomas Z. schrieb: > Richard K. schrieb: >> Jetzt habe ich auch den CH554 und den CH559 online: > > Die Bilder sind echt cool danke dafür. Gerne! Wenn ihr noch was in die Richtung braucht, dann sagt Bescheid! Von den Software-Themen halte ich lieber Abstand... :)
@Richi Vielen dank nochmals, finde deinen röhren ofen übrigends sehr interessant.
Aaron C. schrieb: > @Richi > > Vielen dank nochmals, finde deinen röhren ofen übrigends sehr > interessant. Der Ofen ist sehr hilfreich. Zwar sind die Dies überraschend robust gegenüber Hitze, aber mit einem Gasbrenner kann man sie dann doch beschädigen. Gleichzeitig brauchen aber vor allem große Packages eine ordentliche Wärmemenge und alle gängigen Produkte wie zum Beispiel Pizza- oder Reflowöfen sind zu kalt. Ein richtiger Muffelofen war mir zu teuer. So kam ich auf den Eigenbau. Damit ist der Vorgang jetzt auch einigermaßen reproduzierbar. 400°C (am Sensor), 1min und die kleinen SMD-Packages sind durch. :) Und bei problematischen Fällen (anhaftende Reste) einfach das Die noch einmal ein bisschen braten, evtl. 50°C mehr und es gibt meist immernoch keine Schäden. (Ausnahmen bestätigen die Regel...)
Ein kleines Update: zusätzlich zu einigen Bugfixes ist jetzt die Verschlüsselung mit TEA oder XTEA möglich. Beide Funktionen sind einfach genug um auch auf einem x51 annehmbare Resultate zu liefern. Bei der Verschlüsselung hat man die Wahl zwischen strong und fast. Strong braucht aber auch die 8 fache Zeit was auf einem x51 schon eine Rolle spielt. Man kann aber auch gut erkennen, dass die fast Option viel schlechter verschlüsselt, speziell wenn viele gleiche Bytes kommen. Außerdem können nun bis zu 4 Intel Hex Files, durch Komma getrennt, geladen werden (merge) und die Extension kann auch weggelassen werden. Im Archiv ist jetzt auch der Sourcecode enthalten. Thomas
Ich habe gestern mal Versuche zur Entschlüsselung gemacht. Mit XTEA strong komme ich auf ca 500 ms pro 512 Byte Block. Den Core Clock schalte ich zum dekotieren auf 48 MHz. Das ist ok für mich. Zusätzlich habe ich in UDisk-Mini eine Erkennung eingebaut ob die Firmware verschlüsselt ist. Mein Ziel UDisk im Bereich 0xE000-0xEFFF unterzubringen werde ich vermutlich nicht erreichen. Ob ich den EEProm Bereich als Code benutzen kann muss ich noch testen, das Datenblatt ist nicht ganz eindeutig. Falls das funktioniert kann die zu flashende Firmware auf dem Stick max 56kB sein. Den Stick habe ich einfach mit einem simplen OTG Adapter angeschlossen. Thomas
@Thomas Das klingt ja ziemlich vielversprechend auch von der Geschwindigkeit her geht das ja, bin gespannt.
naja noch ist das alles im Test. Ich arbeite im Moment mit einer debug Version die alles mögliche auf einem kleinen TFT mit einem umgeleiteten printf ausgibt. Später werde ich wieder auf die serial Debug Ausgabe umschalten. Der oben gezeigte UDisk Code hatte auch noch ein paar kleine Bugs. Außerdem bin ich wieder über einige seltsame Konstrukte im WCH Code gestolpert die ich mir nicht erklären kann. Hab's halt einfach mal übernommen. Die entgültige Version wird dann allerdings keine Ausgaben enthalten sondern sollte einfach funktionieren. Noch bin ich mir auch nicht sicher ob mein ENum Code nicht zu strikt ist, da muss ich mal mit modernen Sticks das Verhalten prüfen. Meine alten Gurken gehen alle. Hast du schon mal einen der CH54x in den Fingern gehabt? Thomas
Mit den CH54X hatte ich noch nichts zutun und auch nicht wirklich angeschaut, sieht aber ja sehr ähnlich aus von den Features. Das wirklich spannende für mich war ja der Preis de CH551 und CH552 dann kahmen die USB und Host funktionen des CH559 dazu.
Auch wenns es noch alles andere als fertig und perfekt ist möchte ich dennoch meinen heutigen erfolg kurz vorstellen. https://youtu.be/EMDJe7JQ76g Ich konnte erfolgreich den SDCC in der Arduino ide zum laufen bringen und das python flasher tool mit als programmer nutzen um nun aus der Arduino ide herraus zu programmieren und es auch neuligen deutlich einfacher zu gestallten. Vielen dank hierbei and Sduino( Beitrag "SDuino: Beinahe-Arduino für STM8S" ) ohne das währe es nicht so einfach geworden.
coole Sache den c51 mit dem Arduino zu verheiraten, ich verstehe allerdings nicht so recht, wie du das c++ da reinfrickelst. Mein UDisk nimmt so langsam Formen an. Nach einigen Aufräumarbeiten bekomme ich das nun in 4kb unter. Von der strong crypt Funktion hab ich mich allerdings verabschiedet. Da ich den Code diesesmal auch zu SDCC kompatibel machen will überlege ich mir auch die MSB Option zu streichen. Ich denke bis Ende der Woche steht das. Der UDisk Code kommt mit allen mir zur Verfügung stehenden Sticks klar. Thomas
Ein kleines update... Ich habe UDisk jetzt soweit fertig und auch für SDCC umgebaut. Wie erwartet ist der Code mit SDCC größer passt also nicht mehr nach 0xE000, statt 4kb sind es etwas mehr als 5kb. Ob der SDCC Code auch funktioniert muss ich noch testen. Wie schon angekündigt ist sowohl die fast Option als auch die MSB Option beim Konverter weggefallen. Die notwendigen Konvertierungen macht UDisk direkt. Die korrigierte Version werde ich morgen zusammen mit dem Projekt zeigen. Thomas
Hier nun UDisk. Es hat etwas gedauert bis mein Code auch für SDCC fehlerfrei compiliert. Im Doc Ordner gibt's ein ausführliches readme. Der debug target flashed einen Hexdumper ab 0x8000 welcher einfach per movc den Codespeicher auf TxT0 schickt. Interessant dabei ist das movc im Bootloader Bereich nur 0xFF liefert. Das unterscheidet den CH559 wesentlich vom CH552. Zum ausprobieren reicht es eines der test_udisk.hex Files auf den Controller zu flashen und FIRMWARE.BIN aus dem dumper Ordner auf den Stick zu ziehen. Dann einfach die der. Schnittstelle mit 57k6 8N1 beobachten. Der Keil Release target braucht 4032 Byte, mit LX51 und LinkerCode Packing lässt sich das auf 3800 Bytes drücken. SDCC braucht deutlich mehr, da hab ich mich aber nicht so intensiv mit dem Optimizer beschäftigt. Im Tools Ordner befindet sich der modifizierte Konverter. Achtung das Format der Kommandozeile ist etwas anders und es gibt eine neue Option für den Key. Thomas
Habe deinen code einmal überflogen, das ist ja ein ganz schöner aufwand der dort drinsteckt! Zu der CH55x Arduino C++ geschichte, es werden vor dem compilieren einfach alle cpp dateien in c umbenannt und als nur c kompiliert.
Der wirkliche Aufwand steckt darin, den Code sowohl für Keil als auch SDCC übersetzbar zu machen. Die Compiler unterscheiden sich doch etwas, viele meiner Makros die ich seit Urzeiten bei Keil verwende, musste ich erst mal anpassen. Der Hintergrund ist dass der Preprozessor im SDCC im Gegensatz zu Keil strikt std konform ist. Einige Makros hab ich immer noch nicht korrekt hinbekommen. Leider machen die ganzen Fallunterscheidungen den Code nicht übersichtlicher. Du kannst das ganze ja mal mit der ersten Version vergleichen die weiter oben gezeigte ist. Alles in allem war es mir das aber wert um etwas tiefer beim SDCC einzusteigen. SDCC ist wesentlich strikter was Warnungen angeht. Wenn jetzt noch die Code Größe vergleichbar wäre, gäbe es für Keil eigendlich keinen Grund mehr. Thomas
Ich habe gerade gemerkt dass im Keil Projekt noch meine TFT lib drin ist. uVision wird sich also beim Start über die fehlende Lib beschweren. Die kann gefahrlos entfernt werden da nicht mehr referenziert. Das ist noch ein Rest als ich printf auf ein TFT umgelenkt hatte. Thomas
Gut gemacht! Vielen Dank
Ich hatte eigentlich vor den UDisk Code auch für den Wickenhäuser Compiler und den MicroE Compiler vorzubereiten. Das wird leider nichts. Der Wickenhäuser beherrscht kein #elif und ich will da nichts mehr umstellen. Beim MicroE ist es so das MCUs nicht so ohne weiteres dazugebaut werden können. Es werden nur MCUs unterstützt die in der Liste auftauchen. Ich hätte mich also drum rum frickeln müssen, was wegen der mangelhaften Doc ziemlich aufwändig wäre. Eigentlich unbrauchbar in meinen Augen und keines wegs das Geld wert was Sie verlangen. Zusätzlich hat sich wohl seit 2013 nichts mehr getan.
Aaron C. schrieb: > Zu der CH55x Arduino C++ geschichte, es werden vor dem compilieren > einfach alle cpp dateien in c umbenannt und als nur c kompiliert. Es gibt noch eine Arduino Implementierung https://embdev.net/topic/498403#new
Angehängte Dateien:
-
YoutubeKommentar.jpg
91 KB
Danke für den Hinweis, Deqing hatte bereits Kontakt mit mir über YouTube Kommentare... Bin etwas verwirrt das die Kommentare gelöscht sind deshalb diese einmal als Anhang hier. Nicht cool soweit, weiß aber auch nicht ob ich da was falsch verstehe, hatte ihm darum gebeten wenn er was aus meinem Code nutzt dieses in der BoardManager.json Datei mit meinem Namen zu erwähnen, was mehr als fair ist.
Ich würde dem nicht so viel Bedeutung beimessen. YouTube ist in China nicht so ohne weiteres verfügbar wie ich aus eigener Erfahrung weiss. Das geht nur über Anonymisierungsdienste. Vielleicht hat dir die große Firewall einen Streich gespielt.
Scheinbar ist es tatsächlich geblockt, komisches YouTube.
Eine Frage: Kann man mit einem WCH-Controller der nur als Device fungieren kann (z.B. CH552) beim Einstecken einen USB-Stick "vorgaukeln" und sobald ein Benutzer eine Datei dahinkopiert, diese über den CH552 auf einen externen SPI-Flash schreiben? Kann man als CH552 die Geschwindigkeit auch limitieren in der Windows / Linux die Datei überträgt? Ich vermute, die SPI-Schnittstelle läuft nicht schneller als vllt. halber CPU Takt? Das reicht nicht um mit USB 2.0 mithalten zu können und der interne RAM wäre dafür zu klein.
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.