Nachdem ich durch Aufspielen der Segger-Firmware auf das FRDM-KL05z
Board und Verwenden des J-Link Debugservers anstelle von OpenOCD &
CMSIS-DAP-Firmware einen Geschwindigkeitszuwachs beim Debuggen von
** außerirdischen **
Ausmaßen beobachtet habe gehe ich davon aus das es tatsächlich so ist
daß der Debugserver von SEGGER die Instruktionen emuliert anstatt sie
auf der MCU ausführen zu lassen.
Aber: Meine LED blinkt nun nicht mehr. Zumindest nicht im Einzelschritt.
Die KLxx Prozessoren von Freescale haben eine BME und spezielle
zusätzliche Register an separaten Adressen, die wenn sie beschrieben
werden den soeben geschriebenen Wert nehmen und damit eine atomare
lesen/ändern/schreiben Operation am eigentlichen Zielregister ausführen.
Da ist zum Beispiel für jedes GPIO-Register folgendes definiert:
1
/** GPIO - Register Layout Typedef */
2
typedefstruct{
3
__IOuint32_tPDOR;/**< Port Data Output Register, offset: 0x0 */
4
__Ouint32_tPSOR;/**< Port Set Output Register, offset: 0x4 */
5
__Ouint32_tPCOR;/**< Port Clear Output Register, offset: 0x8 */
6
__Ouint32_tPTOR;/**< Port Toggle Output Register, offset: 0xC */
7
__Iuint32_tPDIR;/**< Port Data Input Register, offset: 0x10 */
8
__IOuint32_tPDDR;/**< Port Data Direction Register, offset: 0x14 */
9
}GPIO_Type;
Dann kann man also zum Beispiel sagen:
1
PTB->PCOR=(1<<4)|(1<<5);
Und die Bits für Pins 4 und 5 werden gelöscht, in einer einzigen
Schreiboperation.
Es scheint nun aber so daß die PCOR Register nicht korrekt emuliert
werden vom jlink. PSOR scheint zu gehen, die anderen hab ich noch nicht
getestet. Die LED geht aus aber nie wieder an, es sei denn ich verlasse
den Einzelschrittmodus und lass es wieder normal laufen, dann gehts
wieder.
Ist das ein bekannter Bug?
Hab ich jetzt einen J-Link gewonnen? Code kann ich am Montag
nachreichen, ich hab das ganze Zeug in der Firma liegen gelassen.
Bernd
Bernd K. schrieb:> Verwenden des J-Link Debugservers anstelle von OpenOCD &> CMSIS-DAP-Firmware einen Geschwindigkeitszuwachs beim Debuggen
CMSIS-DAP verwendet USB HID IIRC, da wundern mich
Geschwindigkeitsprobleme nicht wirklich. IMO gibt oder gab es da Patches
für, aber eventuell nur in OpenOCD Gerrit.
OpenOCD kann JTAG (SWD mit neurem Git Master) auch mit einem JLINK
Adapter - man muss aber den LibUSB-Win32 Filtertreiber installieren
(z.B. mit Zadig).
Bernd K. schrieb:> davon aus das es tatsächlich so ist> daß der Debugserver von SEGGER die Instruktionen emuliert anstatt sie> auf der MCU ausführen zu lassen.
Nö, nur die USB Kommunikation hat weniger Latenzen. Die Instruktionen
werden von der MCU ausgeführt.
Bernd K. schrieb:> Aber: Meine LED blinkt nun nicht mehr.
Zeig Deinen Code. Der obige Schnipsel schaltet aus, aber nicht ein.
Jim Meba schrieb:> Nö, nur die USB Kommunikation hat weniger Latenzen. Die Instruktionen> werden von der MCU ausgeführt.
Da hab ich aber was anderes gelesen. Und das Symptom (extremer geradezu
unwirklichrer Performancegewinn, manche Instruktionen werden nicht mehr
korrekt ausgeführt) passt dazu. Oder hast Du eine andere Erklärung?
Bernd K. schrieb:> Da hab ich aber was anderes gelesen.
Wo genau hast du das gelesen?
> Und das Symptom (extremer geradezu> unwirklichrer Performancegewinn, manche Instruktionen werden nicht mehr> korrekt ausgeführt) passt dazu. Oder hast Du eine andere Erklärung?
Das Segger zeugs ist bei mir u.a. bei Flashen auch schneller als FTDI
(Jtagkey2) + OpenOCD.
Bei CMSIS-DAP ist noch ein Patch für OpenOCD offen, der die
Geschwindigkeit stark steigern soll:
http://openocd.zylin.com/#/c/2356/
Es wird normalwerweise alles auf dem MCU ausgeführt, deshalb haben die
Cortex M ja die schicke Debug-Schnittstelle von ARM spendiert bekommen.
Jim Meba schrieb:> Bernd K. schrieb:>> Da hab ich aber was anderes gelesen.>> Wo genau hast du das gelesen?
Hier bin ich drüber gestolpert und anschließendes Googeln hat auch noch
vereinzelte Hinweise darauf ergeben, leider hab ich kein Dokument
gefunden das präzise erläutert was denn nun tatsächlich genau abläuft
beim single-stepping:
https://www.segger.com/admin/uploads/userfiles/file/PressReleases/091016_Flash_breakpoints_IQ_magazine.pdf> Bei CMSIS-DAP ist noch ein Patch für OpenOCD offen, der die> Geschwindigkeit stark steigern soll:> http://openocd.zylin.com/#/c/2356/>> Es wird normalwerweise alles auf dem MCU ausgeführt, deshalb haben die> Cortex M ja die schicke Debug-Schnittstelle von ARM spendiert bekommen.
OpenOCD verwende ich momentan 0.9.0-dev weil 0.8.0 es geschafft hat das
FRDM-KL05z-Board zu "bricken". Der Befehl "program foo.elf" scheitert
mit einem write error und anschließend ist das Board tot. "flash
write_image foo.elf" hingegen funktioniert einwandfrei. Das passiert
zwar mit der 0.9.0 immer noch (wenn man vergisst die neue target/klx.cfg
aus dem master-branch zu verwenden) aber zumindest kann man es mit
0.9.0-dev wiederbeleben ohne vorher wieder die orginal openSDA-Firmware
auf den onboard debug-Adapter auspielen zu müssen.
Die Geschwindigkeit beim Debugging mit openocd war jetzt nicht unbedingt
unerträglich langsam, es war in etwa vergleichbar mit dem was ich zuvor
auch bei openocd/st-link auf einem stm32f4 beobachtet habe, halt eben
eine spürbare Latenz aber noch nicht wirklich störend.
Am Freitag hab ich dann in Feierabendlaune nur mal spaßeshalber die von
Segger bereitgestellte jlink-Firmware auf den onboard-Adapter des
FRDM-Boards gespielt und in Eclipse den jlink-gdbserver anstelle von
openocd verwendet und der sodann folgende Geschwindigkeitsrausch war
jenseits von nur "ein bisschen schneller", es war ungefähr so als würde
ich eine lokale Anwendung direkt auf dem PC debuggen, es war überhaupt
keine Latenz beim Einzelschritt mehr spürbar. Das Erlebnis war
überwältigend.
Nur das Nicht-Funktionieren des PCOR Registers beim single-step.
Die Ursache dafür würd ich gerne verstehen. Ansonsten macht das J-Link
Zeugs einen stabilen Eindruck und auch die explizite J-Link
Unterstützung im Eclipse-GNUARM-Plugin gefällt mir sehr gut und ein
stand-alone JTAG-Adapter muss ohnehin angeschafft werden. Nur dieser
eine Wermutstropfen trübt momentan noch die Stimmung.
Die Kombination j-link Firmware auf dem Adapter und openOCD als
Debugserver hab ich noch nicht getestet, das mach ich am Montag.
PS:
Der Code auf dem ich aufbaue beruht darauf:
https://github.com/0xc0170/kinetis_klxx_gcc/blob/master/gpio_demo_frdmkl05z/main.c
In der main() habe ich bisher lediglich das Toggeln mit PTOR durch ein
abwechselndes PSOR und PCOR aller drei Farben ersetzt, das läuft auch
wunderbar, auch mit openOCD im Einzelschritt, nur mit jlink gehen die
LED aus (PSOR denn die RGB-LED hat gemeinsame Anode) aber nicht mehr an
(PCOR).
Er überspringt ganze Programmblöcke!
Ich hab mal mit Sternchen kenntlich gemacht wo er im Einzelschritt
langläuft. Die erset Spalte ist mit r4=5, da ist alles noch ok, unten
wird r4 dann weitergezählt und ist wieder auf 0 (oben gehts dann mit den
Sternchen in der zweiten Spalte weiter), dann müsste das erste if()
zutreffen (tuts auch) und dann plötzlich bei 7ec anstatt nach 800 zu
springen bin ich urplötzlich in 688.
Wenn ich in den Eclipse J-Link Einstellungen "enable semihosting"
deaktiviere dann passiert das nicht.
Strange... :-/
Wer könnte schuld sein? GDB oder JLinkGDBServerCL oder Eclipse?
John-eric K. schrieb:> Wie wäre es, dass du denen einfach mal schreibst.> info@segger.com
Hab ich jetzt mal gemacht. Leider kann man auch nicht einfach in deren
Forum posten, nicht mal nach erfolgter Anmeldung dort, also der einzige
Weg scheint wirklich E-Mail zu sein.
Wenn man in alten Threads hier auf µC.net herumstöbert stolpert man über
vereinzelte Postings von SEGGER-Leuten die hier sogar in offizieller
Eigenschaft unterwegs waren und Hilfe leisteten, aber scheinbar haben
die sich mittlerweile verzogen oder wurden vergrault.
Hallo,
wir (SEGGER) besuchen mikrocontroller.net in der Regel nur, wenn wir
entsprechende Supportanfragen erhalten.
Bei Problemen mit dem J-Link oder anderen SEGGER-Produkten empfehlen wir
folgende Kontaktmöglichkeiten:
- Für Produkte die noch im Support sind (z.B. 1 Jahr für J-Link
Base/PLUS, 2 Jahre für J-Link ULTRA+/PRO) per e-Mail an
support@segger.com
- Für Produkte ohne Support (z.B. J-Link EDU/OB/LITE) über unser Forum
(http://forum.segger.com)
Die Freischaltung im Forum erfolgt manuell und kann daher bis zu 24
Stunden dauern.
Wegen des oben geschilderten Problems sind wir bereits per e-Mail in
Kontakt und werden eine Lösung finden.
Johannes - J-Link Develpment / Support
Ich lese gerade in meiner Inbox daß das Problem reproduziert und auch
bereits behoben werden konnte und ein dementsprechendes baldiges (diese
Woche) Bugfix-Release schon in Vorbereitung ist.
Das hört sich doch schon mal gut an :-)
Wir konnten das Problem reproduzieren und beheben.
Bei dem Step auf 0x800 wurde diese Instruktion fälschlicherweise als
Semihostingfunktion interpretiert, was dazu führte, dass sie
übersprungen (PTB->PCOR wurde nicht beschrieben) und das Target
anschließend laufen gelassen wurde.
Der Fix ist bereits im aktuellen Beta enthalten (V4.97f,
https://www.segger.com/jlink-software-beta-version.html) und wird heute
auch im neuen Release (V4.96g,
https://www.segger.com/jlink-software.html) enthalten sein.
Zur Geschwindigkeit sei folgendes zu sagen:
Der J-Link kann durch verschiedene Optimierungen eine sehr hohe
Performance erreichen, dazu gehören unter anderem das Simulieren von
Instruktionen bei Instructionsteps sowie der integrierte Flashdownload
für die meisten Devices.
Für die beste Performance empfehlen wir den J-Link mit der J-Link
Software (J-Link GDB Server) an Stelle des OpenOCD zu verwenden um von
allen Optimierungen gebrauch machen zu können.
Johannes - J-Link Development / Support
Thread beobachten
Seitenaufteilung abschalten