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.
Such mal nach ‚Lernbetty‘, da ist das Verfahren beschrieben. Duck und wech...
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.
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.