Forum: Mikrocontroller und Digitale Elektronik OOCD Debugging in GnuArmEclipse startet nicht


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
ich verzweifle hier gerade am openOCD Debugging in Eclipse mit dem 
GnuArmEclipse Plugin.
Target ist ein nrf51822 BLE Chip, App eine mbed iBeacon Demo. Wenn ich 
das Programm manuell per OOCD flashe funktioniert es. Aber das starten 
über den Debugger lefert gerade immer folgenden Fehler:
1
GNU MCU Eclipse 64-bits Open On-Chip Debugger 0.10.0+dev-00139-g654d06db (2017-08-26-18:25)
2
Licensed under GNU GPL v2
3
For bug reports, read
4
  http://openocd.org/doc/doxygen/bugs.html
5
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
6
cortex_m reset_config sysresetreq
7
adapter speed: 1000 kHz
8
Started by GNU MCU Eclipse
9
Info : Listening on port 6666 for tcl connections
10
Info : Listening on port 4444 for telnet connections
11
Info : CMSIS-DAP: SWD  Supported
12
Info : CMSIS-DAP: JTAG Supported
13
Info : CMSIS-DAP: Interface Initialised (SWD)
14
Info : CMSIS-DAP: FW Version = 1.10
15
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
16
Info : CMSIS-DAP: Interface ready
17
Info : clock speed 1000 kHz
18
Info : SWD DPIDR 0x0bb11477
19
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
20
Info : Listening on port 3333 for gdb connections
21
Info : accepting 'gdb' connection on tcp/3333
22
Info : nRF51822-QFAA(build code: H1) 256kB Flash
23
undefined debug reason 7 - target needs reset
24
Info : dropped 'gdb' connection

Das nervige ist das es schonmal funktioniert hat, ich dann aber evtl. 
irgendwas wichtiges verstellt habe. Warum wird die Verbindung einfach 
wieder geschlossen?

es poppt noch ein Dialog mit Fehlermeldung auf:
1
Error in final launch sequence
2
Failed to execute MI command:
3
-target-select remote localhost:3333
4
Error message from debugger back end:
5
Remote failure reply: E0E
6
Failed to execute MI command:
7
-target-select remote localhost:3333
8
Error message from debugger back end:
9
Remote failure reply: E0E
10
Remote failure reply: E0E

: Bearbeitet durch User
von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Bin einen Schritt weiter, habe wieder auf die oocd Version 0.10.0, 
kompiliert von F. Chopin, umgeschaltet und der Debugger startet wieder.
Ich hatte alles mögliche probiert weil das Debuggen selber Probleme 
macht, das liegt aber vermutlich doch eher an dem nrf51822 oder der 
Software.
Wenn ich das Programm im Debugger startet hält es im main an:
1
int main(void)
2
{
3
    ble.init(bleInitComplete);
4
    
5
    printf("Jojos BLE iBeacon\n");

laufen lassen ohne Breakpoint funktioniert, die printf() Ausgabe ist im 
Terminal zu sehen. Aber im Single Step geht es nur über das ble.init(), 
ein Step über printf() landet im Hardfault :-( Kennt sich hier jemand 
mit den nrf51 aus?

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> . Aber im Single Step geht es nur über das ble.init(),
> ein Step über printf() landet im Hardfault :

Sobald das Softdevice an ist darf der Debugger das Programm nicht mehr 
anhalten. Es werden diverse Timings streng überwacht - sonst 
funktioniert BLE schlicht nicht. Und ja, das ist vom Hersteller so 
dokumentiert.

Hier ist also eher printf()-style Debugging z.B. über UART gefragt.

Ich habe hier beispielsweise einfach einen Breakpoint im fault_handler:
1
void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info)
2
{
3
  asm volatile ("bkpt #1");
4
}

Dann sieht man sofort im Debugger wenn was klemmt. Muss in der Release 
Version alledings raus oder z.B. durch NVIC_SystemReset() ersetzt 
werden.

Wenn ich im OpenOCD debugge habe ich immer ein Teminal vom OpenOCD Port 
3333 offen -  um schnell ein "reset run" oder "reset halt" eingeben zu 
könnnen, wenn doch mal ein Breakpunkt nötig war.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
danke, sowas habe ich schon vermutet. Das sind meine ersten Schritte mit 
dem nrf51, da habe ich noch nicht soviel gelesen.
Das Softdevice ist in den mbed Quellen nur als kompiliertes .hex drin, 
darüber bin ich auch erst gestolptert. Das exportierte eclipse Project 
fügt die Anwendung und das S130 nicht zusammen, das lief erst nachdem 
ich das Programm aus dem Online Compiler in den nrf geflasht hatte.
Da das Softdevice und die App eigene Bereiche belegen sollte es doch 
gehen einmal das S130.hex zu flashen und dann jeweils nur die App zu 
ändern? Jedenfalls solange der gdb keinen mass erase auslöst, oder? Der 
online Compiler macht ein srec_cat der beiden hex files, das müsste ich 
sonst noch als post build step einbauen. Da die beiden .hex files ja 
eigene Bereiche beschreiben müsste ein zusammenkopieren der hexfiles 
auch reichen?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.