CH32V003: Probleme mit Bootloaderspeicherbereich

[Ralph S. (jjflash)]

Ich möchte einen UART-Bootloader für den CH32V003 unter Linux haben. 
Zuerst dachte ich: aktiviert man den Bootloader, der im 
Auslieferungszustand gespeichert ist und es ist gut.

Nein, es ist nicht gut: denn wie es aussieht, wahrscheinlich mache ich 
einiges falsch), muß man den Bootloader aktivieren und aus der Firmware 
heraus starten.

Ich möchte aber einen Bootloader haben, an den ich eine serielle 
Schnittstelle anschließe (über USB2UART-Bridge) und mit dem ich dann den 
Chip flashen kann.

Also habe ich mich an's Werk gemacht, weil ich dachte, dass das nicht so 
schwierig sein kann, für AVR und STM8 habe ich so etwas ja auch schon 
gemacht (wobei: der Optiboot für den AVR nicht zu toppen ist).

Meine gemachten Schritte:
- Hostprogramm für andere Controllerfamilie zur Steuerung eines 
Bootloaders anpassen
- Bootloader Linkerscript von CH32FUN verwenden
- Kommunikationsfunktionen im Bootloader schreiben, läuft mit 48MHz int. 
Takt, 115200 Baud
- entsperren des Flashspeicherschreibschutz
- zur Fehlersuche im Bootloader eine kurze Hexdump-Funktion integrieren 
damit ich sehen kann, was im Flashspeicher passiert ist.
- Funktion zum löschen des Flashspeichers (Testweise gesamten Speicher 
löschen, Sektoren zu je 1 kByte löschen)
- Entgegennahme von zu schreibenden Bytes und schreiben dergleichen im 
Flashspeicher

Was funktioniert:
- Nach Poweron startet der Bootloader
- aktuell zur Fehlersuche gibt der Bootloader nach Nichteingehen des 
Kommandos zum Schreiben einer neuer Firmware einen (kurzen) 
Hexdump-Ausschnitt aus einem wählbaren Speicherbereich aus
- nach der Ausgabe des Hexdumps startet das Userprogramm

So, jetzt wird es "schwierig"
- es kann jeder Speichersektor mit Bytes beschrieben werden und werden 
dort auch korrekt abgelegt, Bootloader bleibt aktiv

Mit einer sehr fatalen Ausnahme: Ich kann die Programmbytes NICHT ab 
Adresse 0x8000000 (Bootvektor des Userprogramms) ablegen. Hierfür muß 
ich den Flashspeicher eben ab Adresse 0x8000000 löschen und das Programm 
dort hinschreiben. Lösche ich den Speicher dort bleibt der Bootloader 
hängen und der Chip macht nichts mehr.

Das Kuriose hier ist jetzt: Flashe ich ein x-beliebiges Programm (nicht 
den Bootloader) mittels RVSWDIO ist der Bootloader wieder da.

Gleiches gilt, wenn ich mittels minichlink -E den gesamten 
Firmwarespeicherbereich lösche, hängt sich der Bootloader auf. Wird ein 
x-beliebiges Programm aufgespielt, ist der Bootloader wieder da.

Wie bekomme ich das hin, dass ich den Speicherbereich ab 0x8000000 
löschen und dann beschreiben kann und ein installierter Bootloader aktiv 
bleibt (damit das Userprogramm dann startet)?

Versuche (aber eben eher verzweifelte Versuche) mit den Optionbytes die 
bspw. einen Bootloader erst aktivieren, haben nichts gebracht. Außerdem: 
wird einfach ein neues Userprogramm aufgespielt ohne die Optionbytes zu 
verändern, ist der Bootloader ja wieder aktiv.

Im Anhang:
- Screenshot der Terminalausgabe des Bootloaders, wenn ein 
Blinklichtprogramm an die Adresse 0x8002000 geschrieben wird (natürlich 
ist das ein Programm für 0x8000000, mir ging es hier nur darum zu sehen, 
ob auch alles richtig geschrieben wurde)
- die Funktionen die ich benutze um Flashspeicher zu löschen und zu 
schreiben.

Etwas zum Schluß noch:

Erstelle ich ein Linkerscript für ein Userprogramm ab 
Flashspeicheradresse 0x8000800
und schreibe ein Programm (an Adresse 0x8000000) das nichts anders 
macht, als das Userprogramm anzuspringen und schreibe ich mittels 
Bootloader eben an die Adresse 0x8000800 ein neues Programm wird dieses 
ausgeführt (solange ich keine Interrupts verwende, die müßten dann im 
Startprogramm angepasst werden).

Allerdings mag ich nicht wirklich mit 2 unterschiedlichen Linkerscripts 
arbeiten, die unterscheiden, ob ein Programm mittels SWDIO oder 
Bootloader geflasht wurde.

Das das Flashen über Bootloader grundsätzlich gehen muß ist an dem V-USB 
Bootloader in

https://github.com/cnlohr/rv003usb

zu sehen. Dieser Bootloader (habe ich im Einsatz) funktioniert super. 
Allerdings mag ich eben eine Schaltung haben, die nicht 2 USB-Buchsen 
hat (eine für den Bootloader und eine für die serielle Kommunikation). 
Außerdem wären hier dann insgesamt 4 (statt 2) der wenigen GPIO-Pins 
weg.

Natürlich habe ich auch versucht, mittels V-USB einen virtuellen 
tty-Port zu programmieren, aber da bin ich noch sehr weit davon entfernt 
dass das funktioniert, außerdem wäre das relativ langsam, belastet ein 
User-Programm und nimmt zudem auch noch Flashspeicher weg.

----------------------------------------------------

@an_alle_standard_negativ_bewerter: tut euch keinen Zwang an. Wenn nur 
ein einziger mir hier weiterhelfen kann ist das zig-millionenfach 
wertvoller als es euer Negativbewertungszwang einen ärgert

[Vanye R. (vanye_rijan)]

Nicht das ich es fuer den CH32V003 selber schon gemacht habe, ich frage 
mich sogar warum man das machen sollte, aber benutze ja auch nur die 
Teile mit moeglichst wenig Pinnen, aber ich vermute mal das deine 
Flashsoftware im Ram laufen muss wenn du das Flash selber bearbeiten 
willst.

Vanye

[Harald K. (kirnbichler)]

Ralph S. schrieb:
> Natürlich habe ich auch versucht, mittels V-USB einen virtuellen
> tty-Port zu programmieren, aber da bin ich noch sehr weit davon entfernt
> dass das funktioniert, außerdem wäre das relativ langsam, belastet ein
> User-Programm und nimmt zudem auch noch Flashspeicher weg.

Der rv003-USB-Bootloader macht doch genau das, kannst Du nicht die 
Routinen des Bootloaders aus Deinem Programm heraus nutzen? Du weißt, an 
welchen Stellen im Speicher das Ding liegt, also sollte es doch möglich 
sein, Funktionen daraus aufzurufen. Das würde dann keinen zusätzlichen 
Speicher benötigen und auch keine zusätzliche USB-Buchse.

[Thomas Z. (usbman)]

Vanye R. schrieb:
> aber ich vermute mal das deine
> Flashsoftware im Ram laufen muss wenn du das Flash selber bearbeiten
> willst.

das denke ich auch. Bei allen Sektor orientierten Flashs müssen Erase 
und Flash Routinen normalerweise aus dem Ram gestartet werden.
Ich kenne nor wenige Systeme wo das nicht so ist.

also zumindest

- uint8_t flash_is_busy()
- void flash_wait_until_not_busy()
- void fmem_writeword(uint32_t addr, uint16_t data)
- void flash_erase_sector(uint32_t addr)

solten im Ram liegen.

An welcher Adresse liegt dein Bootloader?

Usb CDC zu implementieren kannst du vergessen, das braucht mindestens 
Fullspeed. Lowspeed Bulk Eps sind nicht durch die Spec abgedeckt.

[Ralph S. (jjflash)]

Harald K. schrieb:
> Der rv003-USB-Bootloader macht doch genau das, kannst Du nicht die
> Routinen des Bootloaders aus Deinem Programm heraus nutzen? Du weißt, an
> welchen Stellen im Speicher das Ding liegt, also sollte es doch möglich
> sein, Funktionen daraus aufzurufen.

Das ist einer der Ansätze, warum ich mir dieses Ding ganz genau ansehe 
... und Asche über mein Haupt, ich bin noch nicht dahinter gekommen, wo 
denn jetzt das Schreiben des Flashs mit diesem USB-Bootloader 
funktioniert. Allerdings (und da studiere ich jetzt eben sehr genau den 
Code) ist das so meine Hoffnung, dass ich daraus schlau werde und da 
davon dann etwas adaptieren kann.

Vanye R. schrieb:
> ch frage
> mich sogar warum man das machen sollte,

Weil ich gerne sehr kleine Teile habe... und weil man dann daraus im 
Stile eines "CH32V003 nano" für das Steckbrett machen kann... oder als 
Modul für eine Schaltung (wie auch immer).

Vanye R. schrieb:
> aber ich vermute mal das deine
> Flashsoftware im Ram laufen muss wenn du das Flash selber bearbeiten
> willst.

Die Idee hatte ich auch schon (denn bspw. beim STM8 war das auch so), 
allerdings: ich kann das Flash ja schreiben nur hängt sich dann eben der 
Bootloader beim Start auf, wenn du den Flash ab 0x8000000 beschreibst 
(umkopieren der Codebytes ins Ram um von dort aus das Programm laufen zu 
lassen wird angesichts der 1920 Bytes die man zur Verfügung hat etwas 
"knapp").

Thomas Z. schrieb:
> An welcher Adresse liegt dein Bootloader?

Bootloader liegt an Adresse 0x00000000 !

Und wie ich jetzt festgestellt habe, kann ich von dort auch alles im 
Flash-Bereich schreiben... nur funktioniert der Loader nicht, wenn ich 
Sektor 0 Beschreibe (der liegt auf 0x8000000).

Außerdem: beim CH32V003 ist der Bootloaderbereich ein vom USER-Flash 
getrennter Bereich. Wird "angeblich" der gesamte Chip gelöscht, wird der 
Bootloader dennoch nicht gelöscht.

[Ralph S. (jjflash)]

Harald K. schrieb:
> Der rv003-USB-Bootloader macht doch genau das, kannst Du nicht die
> Routinen des Bootloaders aus Deinem Programm heraus nutzen? Du weißt, an
> welchen Stellen im Speicher das Ding liegt, also sollte es doch möglich
> sein, Funktionen daraus aufzurufen. Das würde dann keinen zusätzlichen
> Speicher benötigen und auch keine zusätzliche USB-Buchse.

Die Idee war bestimmt keine Schlechte. Also habe ich mir den Quellcode 
noch einmal vorgenommen ... und stelle fest, dass dieser (zumindest in 
meinen augen) sowas von fürchterlich formatiert ist.

Manche Einrückungen sehr "interessant" gemacht (um es vornehm 
auszudrücken).... und um es nicht vornehm auszudrücken: Das 
Bootloaderprogramm ist schon sehr gut... die Formatierung des 
Quelltextes und die Art der bedingten Compilierung (Präprozessorangaben 
halt) sind schlicht fürchterlich. Wie es aussieht (weil die Formatierung 
des Textes nicht einheitlich ist) haben daran mehrere Menschen 
gearbeiet, und jeder hat seinen eigenen Stil, wie Quelltexte auszusehen 
haben.

Also habe jetzt ein paar Stunden aufgewendet um die Source in etwa den 
Stil zu bekommen, wie ich das lesen kann.

Und was muß ich beim "beautyfing" feststellen? Für meinen eigenen 
Bootloader nutzt mir der Code nichts, denn der Bootloader ist schlicht 
nichts anderes als ein dummer USB-Befehlsempfänger auf Low-Level Ebene. 
Die komplette "Intelligenz" wird dem Host überlassen, der Bootloader 
selbst erhält nur die Anweisung, welches Word an welcher Adresse 
geschrieben wird.

Wenn ich also Teile davon für mein eigenes Projekt verwenden will, muß 
ich mich mit dem Programm des Hosts auseinandersetzen, denn dort wird 
bestimmt, welches Byte an welcher Stelle im speicher geschrieben wird.

Das ist eine Ecke umfangreicher, aber min. genauso wildFormatiert wie 
der Bootloader selbst.

Den minichlink zu verändern oder zu erweitern, käme in etwa dem 
verändern von AVRDUDE gleich. Ohne Einarbeitung, ohne ein Zeigen dessen 
was geht und was nicht, ist das ein zähes Unterfangen. Mal sehen, ob ich 
daran noch Spaß finde.

[Harald K. (kirnbichler)]

Ralph S. schrieb:
> und stelle fest, dass dieser (zumindest in
> meinen augen) sowas von fürchterlich formatiert ist.

Du meinst z.B. 
https://github.com/cnlohr/rv003usb/blob/master/bootloader/bootloader.c?


Du hast noch nicht viel mit fremdem Sourcecode gearbeitet. Das ist, wenn 
man eine brauchbare IDE mit syntaxhighlighting verwendet, durchaus noch 
lesbar; ich hab' schon viel schlimmeres gesehen (und musste damit aktiv 
arbeiten, d.h. massive Fehler darin beseitigen, aber dafür hat man mich 
auch gut bezahlt ...)
Und ja, da gibt es Dinge, die ich so auch gar nicht sehen mag 
(Leerzeichen nach öffnenden oder vor schließenden Klammern, fehlende 
Leerzeichen nach if/for etc., keine Leerzeichen zwischen Operatoren 
(a+b*c statt a + b * c) etc.

Fürs Umformatieren gibt es "beautfier"-Tools, das muss man nicht von 
Hand machen.

Ich kann die Faszination eines Bootloaders nicht so recht 
nachvollziehen, aber vielleicht liegt das auch daran, daß ich mehrere 
WCHLinkE habe, und es gewohnt bin, die zu benutzen. Braucht nur einen 
I/O-Pin ... und ich kann debuggen. Einen Bedarf, ein Binary ohne weitere 
Softwareunterstützung zu "flashen", habe ich einfach noch nie verspürt.

Ich hab' mir bislang auch nur die "low-level"-Controller von WCH 
angesehen, demnächst spiele ich auch mal mit einem CH32V002 und einem 
CH32V006 herum, von denen hier jeweils ein Gurtabschnitt eingetrudelt 
sind.

Es gibt aber auch deutlich größere Brüder mit dedizierter USB-Hardware, 
die ich mir noch gar nicht angesehen habe; wenn die gut gemacht sind, 
haben sie die Art von "Bootloader", die man im RP2040 kennt: Mass 
Storage Device, d.h. an einen Host anstecken, Datei draufkopieren, 
fertig. Kein Geraffel mit seriellen Schnittstellen und irgendwelcher 
Zusatzsoftware.
Mir ist klar, daß das mit den kleinen Controllern nicht gehen kann; mit 
"V-USB" ist Mass Storage nicht drin, und die Dinger haben außerdem viel 
zu wenig RAM.

[Ralph S. (jjflash)]

Harald K. schrieb:
> Du meinst z.B.
> https://github.com/cnlohr/rv003usb/blob/master/bootloader/bootloader.c?

genau den

Harald K. schrieb:
> Fürs Umformatieren gibt es "beautfier"-Tools, das muss man nicht von
> Hand machen.

Ich habe auch "Beautifier-Tools", aber ich dachte mir, wenn ich das von 
Hand mache, erschließt sich mir das eher weil ich es dann wirklich 
wirklich wirklich Zeile für Zeile lesen muß (außerdem habe ich das dann 
in meinem mir eigenen "Stil").

Harald K. schrieb:
> Du hast noch nicht viel mit fremdem Sourcecode gearbeitet. Das ist, wenn
> man eine brauchbare IDE mit syntaxhighlighting verwendet, durchaus noch
> lesbar;

Smile, jetzt kann man sich darüber streiten, was "viel mit fremdem 
Sourcecode" bedeutet. Habe ich schon öfters gemacht. Im Vorliegenden 
Falle hat mich schlicht die Verschachtelung des Präprozessors 
"geärgert".

Ich gehe z.Bsp. niemals her und mache etwas in der Art:

register = variable1 & #ifdef blafusel blafusel #else blafusel 2
           #endif | ((variable2 | #if (def1 == 2) blafusel 2 #endif;

Harald K. schrieb:
> Ich kann die Faszination eines Bootloaders nicht so recht
> nachvollziehen, aber vielleicht liegt das auch daran, daß ich mehrere
> WCHLinkE habe, und es gewohnt bin, die zu benutzen.

Jetzt mußte ich lachen (sorry, das ist nicht böse gemeint): Die 
Faszination für einen Bootloader muß man nicht wirklich teilen. Es ist 
eher die Faszination dafür, mit wie wenig Hardware man auskommen kann. 
Ich kann es nicht so recht erklären. Vielleicht liegt es auch daran, 
dass ich - immer noch - ab und an, wenn ich etwas auf die Schnelle 
ausprobieren mag einfach einen Arduino nano (nein, ich programiere nicht 
in Arduino aber ich mag bisweilen die Hardware oder besser: ich mochte 
die Hardware)... oder meine eigenen STM8 nano und STM32F030 nano in ein 
Steckbrett stecke und das anschließe. Alle "großen" EVAL-Boards sind 
manchmal schlicht unhandlich (selbst meine eigen erstellten).

Aber (pro Bootloader): Ich habe ein paar Meßgeräte / Steuergeräte 
dienstlich gebaut, bei denen ich ganz froh war, dass ich einen 
Bootloader implementiert hatte, weil es dadurch möglich war, den Ablauf 
des Gerätes zu ändern, ohne das Gerät öffnen zu müssen (was nebenbei 
auch noch den Effekt hat, dass nach einer Öffnung eines Gerätes auch 
jedesmal eine DGUV3 Sicherheitsprüfung erfoderlich ist ... die ich nun 
seit mittlerweile auch 3 Jahren auch selbst durchführen darf / muß )

Außerdem ist es ja (wie jetzt hier in meinem Fall) so, dass man sich 
selbst Herausforderungen stellt, die man selbst und kaum ein anderer 
braucht. Einfach weil es eine Herausforderung ist. Am hier einen 
Bootloader zu programmieren bin ich so oft in den Datenblättern 
unterwegs, dass ich die Möglichkeiten vom Chip besser kennenlerne und 
außerdem staubt mein eh schon schlechtes Englisch nicht noch weiter ein.

Harald K. schrieb:
> CH32V002 und einem
> CH32V006 herum, von denen hier jeweils ein Gurtabschnitt eingetrudelt
> sind.

V002 habe ich hier auch einen V203 und ein V006 sollte irgendwann auch 
eintrudeln

Harald K. schrieb:
> Ich hab' mir bislang auch nur die "low-level"-Controller von WCH
> angesehen,

Aber auch hier bin ich bei dir, aus mir nicht erklärbaren Gründen reizen 
die anderen Chips mich nicht so sehr. Vielleicht bin ich da der 
STM32-Serie zu sehr verhaftet.

Harald K. schrieb:
> haben sie die Art von "Bootloader", die man im RP2040 kennt: Mass
> Storage Device

Das kann ich jetzt im Gegenzug nicht nachvollziehen, denn die 
Nucleo-Boards von ST haben alle dieses Mass Storage Device (wird von 
einem STM32F103 verwaltet) dass ich außer zum Ausprobieren noch nie 
verwendet habe.

So hat jeder seine "Amositäten".

Harald K. schrieb:
> und die Dinger haben außerdem viel
> zu wenig RAM.

Leider... nur 2 Kbyte (wirklich etwas arg dürftig... andererseits kostet 
das Dingelchen ja auch nur 25 Ct ... oder auch weniger)

[Ralph S. (jjflash)]

... ich hänge hier mal einen Codeschnippselauszug aus oben erwähntem 
Programm an ... und dass es genau so ein Teil ist, den ich höchst 
unleserlich empfinde !

[Harald K. (kirnbichler)]

Ralph S. schrieb:
> Das kann ich jetzt im Gegenzug nicht nachvollziehen

Aber damit ist "im Feld" mit Abstand am einfachsten ein Firmwareupdate 
möglich. Das wird auch real genutzt; mir ist das schon mehrfach bei 
verschiedenem Photozubehör begegnet. Sowas hat den Vorteil, daß 
keinerlei zusätzliche Software benötigt wird und somit ein Update auch 
komplett betriebssystemagnostisch durchgeführt werden kann.
Gut, bei diesen Dingen (Objektive und -Adapter dafür) ist die USB-Buchse 
ausschließlich dafür da, aber bei z.B. einem Messgerät o.ä. könnte man 
eine Taste o.ä. vorsehen, die beim Einschalten gedrückt sein muss, um 
diesen Mechanismus zu aktivieren, damit die USB-Buchse sonst anderweitig 
genutzt werden kann.

Damit kann man Firmwareupdates auch durch relativ unbeleckte Personen 
durchführen lassen.

Ralph S. schrieb:
> Ich gehe z.Bsp. niemals her und mache etwas in der Art:
>
> register = variable1 & #ifdef blafusel blafusel #else blafusel 2
>            #endif | ((variable2 | #if (def1 == 2) blafusel 2 #endif;

Was das, und das in deinem nächsten Post gezeigte Beispiel angeht:

Ja, das kann man anders machen, indem man sich die verschieden 
zusammengestoppelten Teile mit einem #define zu einem im Code bei der 
Zuweisung verwendeten Wert kombiniert.

Ein Grund für derartig aufgebauten Code ist oft, daß der unter sehr 
verschiedenen Bedingungen verwendet wird; ich habe gerade die letzten 
zwei Jahre damit verbracht, Code von einem auf ein anderes 
Echtzeitbetriebssystem zu portieren, und dabei aber auf 
Rückwärtskompatibilität achten zu müssen, weil der Code selbst /während 
der Portierung/ auch noch weiterentwickelt wurde und immer noch mit dem 
alten Betriebssystem verwendbar bleben musste.
Und dabei entsteht halt ein ganzer Haufen bedingter 
Compilierungsanweisungen.

Glaub' mir, das geht noch viel, viel hässlicher als das, was Du da 
'rausgepickt hast.

(Oh, und das, was Du da in zwei Zeilen zitiert hast, das würdest Du 
selbst doch wohl nie so schreiben, oder? Denn das wäre wirklich brutal 
und komplett unlesbar.

[Thomas Z. (usbman)]

Ralph S. schrieb:
> Und was muß ich beim "beautyfing" feststellen? Für meinen eigenen
> Bootloader nutzt mir der Code nichts, denn der Bootloader ist schlicht
> nichts anderes als ein dummer USB-Befehlsempfänger auf Low-Level Ebene.
> Die komplette "Intelligenz" wird dem Host überlassen, der Bootloader
> selbst erhält nur die Anweisung, welches Word an welcher Adresse
> geschrieben wird.

Das ist halt ein HID Device, so ziemlich das einzige was mit lowspeed 
out of the Box funktioniert. Die Datenübertragung geht über einen 8 Byte 
Interrupt Endpoint, Im Hid Descriptor ist festgelegt, dass eine 
Übertragung immer aus 128 Bits besteht. Um ehrlich zu sein habe ich die 
Stelle wo geflasht wird auch noch nicht 100% identifiziert.

Vermutlich ist ein Grund für den komplizierten Code auch die 1920 Byte 
Grenze.

[Ralph S. (jjflash)]

Harald K. schrieb:
> (Oh, und das, was Du da in zwei Zeilen zitiert hast, das würdest Du
> selbst doch wohl nie so schreiben, oder? Denn das wäre wirklich brutal
> und komplett unlesbar.

Im Leben würde ich das so niemals schreiben!

Thomas Z. schrieb:
> Vermutlich ist ein Grund für den komplizierten Code auch die 1920 Byte
> Grenze.
Sehr wahrscheinlich ist das dem begrenztem Platz in der 
Bootloader-Section geschuldet.

Vielleicht (oder eher wahrscheinlich) kennst du auch den 
usbtiny-Programmer für AVR Controller. Dort ist in der Ursprungsversion 
V-USB mittels ATtiny2313 gemacht gewesen und wenn man sich den Code 
angesehen hatte, war das ähnlich auch nur ein Umsetzer von USB nach SPI.

[Thomas Z. (usbman)]

Ralph S. schrieb:
> Vielleicht (oder eher wahrscheinlich) kennst du auch den
> usbtiny-Programmer für AVR Controller. Dort ist in der Ursprungsversion
> V-USB mittels ATtiny2313 gemacht gewesen und wenn man sich den Code
> angesehen hatte, war das ähnlich auch nur ein Umsetzer von USB nach SPI.

nicht im Detail. Ich habe aber Erfahrungen mit V-USB gemacht. Auch wenn 
ich das für eine herausragende Leistung halte ist das Ergebnis doch in 
vielen Fällen nicht so toll. Ich persönlich will nur noch natives USB 
haben.

Ich habe im Projekt Bereich schon mal eine Portierung von Fischls usbasp 
auf einen CH552 vorgestellt. Da arbeite ich gerade an einer erweiterten 
CDC Implementation. (als Compount Device mit automatischer winusb 
Erkennung)

[Ralph S. (jjflash)]

Thomas Z. schrieb:
> Ich habe im Projekt Bereich schon mal eine Portierung von Fischls usbasp
> auf einen CH552 vorgestellt. Da arbeite ich gerade an einer erweiterten
> CDC Implementation. (als Compount Device mit automatischer winusb
> Erkennung)

:-) die Portierung habe ich gesehen.

Thomas Z. schrieb:
> nicht im Detail. Ich habe aber Erfahrungen mit V-USB gemacht. Auch wenn
> ich das für eine herausragende Leistung halte ist das Ergebnis doch in
> vielen Fällen nicht so toll.

Aber manchmal halt super praktisch. Im Moment allerdings hab ich hier 
mein Testaufbau mit einem CH340N (ohne Quarz). Funktioniert.

Außerdem muß ich an der Hardware hier noch etwas spielen. Seit vllt. 2 
Stunden funktioniert mein Bootloader grundsätzlich. Allerdings noch 
etwas langsam, weil ich Bytes noch einzeln und nicht Pageweise schreibe. 
Aber es funktioniert.

Thomas Z. schrieb:
> Bei allen Sektor orientierten Flashs müssen Erase
> und Flash Routinen normalerweise aus dem Ram gestartet werden.
> Ich kenne nor wenige Systeme wo das nicht so ist.
>
> also zumindest
>
> - uint8_t flash_is_busy()
> - void flash_wait_until_not_busy()
> - void fmem_writeword(uint32_t addr, uint16_t data)
> - void flash_erase_sector(uint32_t addr)
>
> solten im Ram liegen.

Irgendwie war mir klar, dass das nicht aus dem Ram gestartet sein mußte, 
aber getestet hatte ich das dennoch und daran lag es dann auch nicht 
(ich hatte alle Programmteile aus dem RAM laufen). Hier kann ich dir 
definitif sagen, dass CH32V003 dann eines der wenigen System ist, "wo 
das nicht so ist" und eben nicht aus dem Ram laufen muß (wahrscheinlich 
deshalb, weil es sowieso ein vom normalen Flash abgetrennter 
Speicherbereich ist, der auf Adresse 0x00000000 gemappt wird).

Nein, mein Fehler war wesentlicher, trivialerer Art und natürlich sucht 
man immer an der falschen Stelle. Mein Fehler lag im Linker-Script. Ich 
hatte das modifiziert gehabt, ein Interrupt lag im normalen Flash und 
den habe ich mir mit einer Löschaktion natürlich weg gelöscht.

So, jetzt fängt das Spielen an und mal sehen wie das "page oriented fast 
programming" funktioniert, weil: 42s Flashzeit für 16289 Bytes sind dann 
doch ein wenig lange, auch wenn das immerhin in etwa doppelt so schnell 
ist wie ArduLink.