So Leute,
heut komme ich mal mit einem Problem daher.
Also, derzeit befasse ich mich mal wieder mit einem M0516 von Nuvoton.
Das ist eigentlich ein ganz netter Cortex-M0. Der Chip hat keinen fest
eingebauten Bootlader, weswegen man ihn per SWD brennen muß. Der
zugehörige Nu-Link tut das auch zufriedenstellend, aber...
Nun ja, sowohl der Nu-Link als auch das zugehörige Brennprogramm sind
ein wenig eigentümlich, eben chinesisch. Deshalb hab ich mal
leichtsinnigerweise versucht, den Seggerschen JLink zu benutzen. Das
geht auch, aber nur zur Hälfte sozusagen.
Hintergrund:
Die M051er haben mehrere Flash-Speicher. Der normale APPROM ist der, wo
die Firmware hineinkommen soll. Daneben gibt es noch einen LDROM von 4 K
Größe, wo man nach eigenem Gusto sich einen eigenen Bootlader
hineinsetzen kann (so man sich einen selbst geschrieben hat).
Der Unterschied zu den hier gebräuchlichen Chips von NXP und ST besteht
darin, daß es keine "BOOT"-Pins gibt, man also nicht von außen festlegen
kann, von welchem Flash der Chip denn booten soll. Dafür gibt es mitten
im Adreßvolumen bei $0030.0000 ein Konfigurationswort, wo u.a. die
Boot-Selektion festgelegt wird.
In diesem Punkt gibt es eine entfernte Ähnlichkeit mit den AVR Chips und
deren "verfusen".
Während der chinesische Brenner diese Konfiguration beherrscht, habe ich
beim Ausprobieren des JLink etwas derartiges nicht gesehen. Den
gewöhnlichen APPROM kann der JLink problemlos brennen, aber das
Konfigurationswort hab ich damit nicht reingekriegt. Auch nicht mit
einem kurzen auf 0x300000 gebundenen Stück Hexfile.
So, jetzt meine Frage: Gibt es hier jemanden, der die Chips von Nuvoton
verwendet UND selbige per JLink programmiert? Und der darüber, wie's
geht mal ein Wort posten kann?
W.S.
W.S. schrieb:> Dafür gibt es mitten> im Adreßvolumen bei $0030.0000 ein Konfigurationswort, wo u.a. die> Boot-Selektion festgelegt wird.
Was sagt denn das Datenblatt dazu?
Kann man dieses Konfigurationswort ganz normal schreiben oder muss man
da vielleicht erst einen speziellen Register-Tanz aufführen, bevor das
freigeschaltet wird?
Gerd E. schrieb:> Kann man dieses Konfigurationswort ganz normal schreiben
Durch die übliche Benutzung der HW-Register des Flashmemory-Controllers,
eben genauso wie alle anderen Schreibvorgänge im Flash per Standard
ISP-Procedere (RefMan, Seiten 154 ff.)
W.S.
Ist doch ganz einfach, man liest in der Doku von Segger wie man Flash
Bereiche hinzufügt, oder eigene Scripte schreibt, welche auf die
Register zugreifen. Man kann ja sogar Module für die Firmware schreiben.
Heute kann aber auch keiner mehr Datenblätter lesen, ts ts.
Debugger sind übrigens generell unnötig, Profis debuggen im Kopf.
Nach dem Überfliegen kann ich jetzt nicht erkennen, was der Debugger
damit zu tun haben soll. Da muß wohl zur Laufzeit erst was unlocked
werden (0x59, 0x16 und 0x88 in REGWRPROT schreiben). Der Erfolg läßt
sich im Register auslesen.
Wenn man das beim Flashen machen will, kann man das mit dem schon
erwähnten Script machen.
Lutz schrieb:> Nach dem Überfliegen kann ich jetzt nicht erkennen, was der Debugger> damit zu tun haben soll.
Na, er benutzt einen J-link Debugger, erklärt aber bei jeder unpassenden
Gelegenheit, dass Debugger Teufelswerk sind und echte Schotten im Kopf
Debuggen können.
Dr. Sommer schrieb:> Na, er benutzt einen J-link Debugger, erklärt aber bei jeder unpassenden> Gelegenheit, dass Debugger Teufelswerk sind und echte Schotten im Kopf> Debuggen können.
Gut; scheine nicht der einzige zu sein, dem dies aufgefallen ist.
Fühle mich jedesmal klein, dumm und haesslich, wenn jemand behauptet, er
brauche beim Programmieren keinen Debugger.
In dieselbe Kategorie faellt bei ihm übrigens auch RTOS. Soll mit Flags
in der Main-Loop genauso gut gehen. Und wieder fühle ich mich klein,
dumm und haesslich.
Mehmet K. schrieb:> Fühle mich jedesmal klein, dumm und haesslich, wenn jemand behauptet, er> brauche beim Programmieren keinen Debugger.
Jaja, Programme von solchen Leuten haben wir alle schon mal gesehen.
Rufus Τ. F. schrieb:> Jaja,..
Tut mir wirklich leid, daß auch du dich "klein, dumm und häßlich" zu
fühlen scheinst. Aber dabei solltest du mal bedenken, daß hier niemand
nach einem Debugger nachgefragt hat.
Es geht auch garnicht darum, den Code in den Chip zu flashen, denn das
kann der JLink. Das reicht aber nicht.
Also lies nochmal, dann wirst du sehen, daß es geht mir darum geht,
anstelle des NuLink's auch mal den ansonsten im Regal sedimentierenden
JLink zu benutzen. Der Chip hat ja keinen residenten Bootlader drin.
Exakt DAS ist der zentrale Punkt.
Selbst wenn ich mich hinsetzen würde, um dafür nen Bootlader zu
schreiben, bliebe immer noch das Henne-Ei-Problem.
Gerd E. schrieb:> Kann man dieses Konfigurationswort ganz normal schreiben oder muss man> da vielleicht erst einen speziellen Register-Tanz aufführen, bevor das> freigeschaltet wird?
Ich bin grad dabei, mir die Codeblöcke näher anzusehen, die beim
NuLink-Programmer für die diversen Chips von Nuvoton dabei sind. So, wie
es derzeit aussieht, läuft es tatsächlich auf einen "Registertanz"
hinaus.
Aber der muß in dem Code-Stück drin stehen, was vom JTAG-Adapter in den
betreffenden Chip befördert wird, um dort die eigentlichen
Programmier-Abläufe durchzuführen. Na, mal sehen.
W.S.
W.S. schrieb:> Aber der muß in dem Code-Stück drin stehen, was vom JTAG-Adapter in den> betreffenden Chip befördert wird, um dort die eigentlichen> Programmier-Abläufe durchzuführen. Na, mal sehen.
Im Endeffekt läuft doch so bei den Cortexen auch der Flashvorgang per
SWD ab.¹ Prinzipiell wird ein kleines Programm nebst den zu flashenden
Daten ins SRAM geladen, der PC auf eben diese Routine gesetzt und Feuer
frei. Das gleiche kannst du eben auch für die Umschaltung der Boot-Modi
machen.
¹So ist es jedenfalls bei OpenOCD und - mit an Sicherheit grenzender
Wahrscheinlichkeit - wohl auch bei Segger, denn auch die kochen nur mit
Wasser.
Christopher J. schrieb:> Prinzipiell wird ein kleines Programm nebst den zu flashenden> Daten ins SRAM geladen,
Ja, ist bekannt. Eben deshalb will ich mir diese kleinen Programmstücke
ja angucken - aus schierer Neugier. Den NuLink, der es für mich ja tut,
hab ich ja.
Aber wie ich aus dem bisherigen Verlaufe dieses Threads sehe, ist
Nuvoton hier ein m.E. viel zu stiefmütterlich behandeltes Thema. Diese
Firma hat einiges an guten Cortexen zu moderaten Preisen im Angebot.
Aber kaum einer hat dafür nen NuLink zur Hand, wohingegen STLink's und
Onboard-JLinks und zu JLinks umgeflashte Onboard-STLinks geradezu eine
Schwemme sind.
Deshalb meine Frage eingangs, ob sich hier jemand wirklich und selber
mit Nuvoton und JLink dazu auskennt.
Denk mal an die gerade laufende Diskussion um billige OTP-µC von Padauk.
Billige Nuvoton-Cortexe wären mMn etwas viel interessanteres.
Ich hatte seit der ersten Vorstellung der M051, NUC100, NUC120, NUC140
auf der Embedded den Nuvoton-Leuten jedes Jahr in den Ohren gelegen, daß
man sowas nicht nur auf der Messe vorstellen darf, sondern auch den
geneigten Bastlern eine benutzbare Bezugsquelle bieten muß, inzwischen
haben sie ihren Onlineshop aufgemacht. Soweit so gut.
Vielleicht muß man den Leuten auch in den Ohren liegen, daß sie auf den
LDROM ihrer Chips ab Werk nen Bootlader via UART0 draufbrennen. Das
würde so einiges erleichtern. Aber ich bin mittlerweile ein bissel müd
geworden, mir den Mund fusslig zu reden. Guck dir doch die bellende
Ignoranz gegen Bootlader in diesem Forum an.
W.S.
W.S. schrieb:> Guck dir doch die bellende> Ignoranz gegen Bootlader in diesem Forum an.
So würde ich das nicht sagen.
Bei der Programmentwicklung - ob nun geschaeftlich oder privat - habe
ich den Debugger angeschlossen. Den Onboard-Bootloader selbst habe ich
noch nie benutzt. Nicht 'mal aus Neugierde.
Sobald die Entwicklung abgeschlossen ist und die Geraete an die Kunden
ausgeliefert werden, wird ein Bootloader "für den Fall aller Faelle"
aufgespielt. Denn die Onboard-Bootloader, die mir bekannt sind, haben
keine Verschlüsselung.
D.h., ob die MCUs nun einen Bootloader haben oder nicht, ist mir
eigentlich egal. Nur bootload-faehig müssen sie sein.
Früher, als die Debugger noch mehrere 1.000 DM gekostet haben, waere der
Bootloader vermutlich für Leute mit Steckenpferd MCU ein Argument
gewesen.
Aber heute? Wieso sich mit einem Bootloader herumschlagen, wenn das mit
einem Debugger um ein Vielfaches einfacher geht.
