mikrocontroller.net

Forum: Compiler & IDEs avr-gdb nicht identische Map


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.
Autor: D a v i d K. (oekel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich versuche mich gerade mit dem Debuggen vertraut zu machen, komme aber 
mit der Terminalausgabe nicht zurecht.

Meine Vermutung (Weil ich es auch nicht hin bekomme die ersten 
Breakpoints mit Clion anzufahren, nachdem er sich via gdb-remote 
verbunden hat) ist, dass das Compilat noch nicht deckungsgleich mit 
meinen Sourcen ist.

Hier erstmal meine Bedienung:
  bin git:(feature/Clion_Atmega644)  avr-gdb                         
GNU gdb (GDB) 7.11.1
.....
Type "apropos word" to search for commands related to "word".
0x00000000 in __vectors ()
Loading section .eeprom, size 0xf lma 0x810000
Loading section .text, size 0x759e lma 0x0
Loading section .data, size 0x62 lma 0x759e
Start address 0x0, load size 30223
Transfer rate: 2 KB/sec, 47 bytes/write.
Haltepunkt 1 at 0x2e8: file /home/dk/CLionProjects/test/main.c, line 28.
(gdb) list
14  
15  #include "inits.h"
16  #include "controlSystem/buffer.h"
17  #include "controlSystem/closedLoopSystem.h"
18  
19  #include "controlSystem/errorHandling.h"
20  #include "input/adc.h"
21  #include "configChange/properties.h"
22  #include "configChange/menueStructure.h"
23  #include "output/displays.h"
(gdb) list
24  #include "input/modeDetection.h"
25  #include "input/buttons.h"
26  
27  int main() {
28      wdt_reset();//needet before reset on this MCU?
29      wdt_disable();
30      loadEEValues();//eeDisplayDimming for init
31      inits();
32      emergencyStop();//to be sure!
33      initBuffers();
(gdb) until inits
Anmerkung: Hardware-Haltepunkte für Nur-Lesen-Adressen werden automatisch benutzt.
warning: Error removing breakpoint 0
warning: Error removing breakpoint 0
Remote Verbindung wurde beendet
(gdb) 


Und folgende Compiler-Flags habe ich gesetzt:
add_compile_options(-Wall -Wextra)#all Warnings
    #add_compile_options(-std=gnu99)


    SET(COMMON_FLAGS -mmcu=${DEVICE} -DF_CPU=${FREQ}UL -Wl,--gc-sections)
    if (CMAKE_BUILD_TYPE MATCHES Debug)
        add_compile_options(-O0 -g ${COMMON_FLAGS}) #(__AVR_ATmega??__)
        add_link_options(-O0 -g ${COMMON_FLAGS})
    elseif(CMAKE_BUILD_TYPE MATCHES Release)
        add_compile_options(-Os ${COMMON_FLAGS})
        add_link_options(-Os ${COMMON_FLAGS})
    endif ()

Kann man dort aus der Ferne bereits etwas zu sagen?
"avarice -4 -P atmega644 -d :4242"

Grüße David

PS: parallel versuche ich es noch mit einem Simulator (und scheitere) 
dachte mir aber mit echter Hardware muss es zuerst funktionieren?!

Autor: Oliver S. (oliverso)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wenn das, was du auf den Prozessor lädst, aus den Quellen kompiliert 
wurde, dann geht es nicht „deckungsgleicher“.

Wenn nicht, sind weitere Diskussion eh sinnlos.

Oliver

Autor: D a v i d K. (oekel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber wie komme ich dann "optisch" zum Haltepunkt 1?

(gdb) until inits
scheint ja auch nicht das zu tun, was ich erwarte.

Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das gdb-„Hello World“ dürfte in etwa so aussehen:

b main
continue

Oliver

Autor: D a v i d K. (oekel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Das gdb-„Hello World“ dürfte in etwa so aussehen:
>
> b main
> continue

Und jetzt bitte das ganze mit avarice und avr-gdb für einen atmega644 
erweitern ;)

Also ich flashe erfolgreich über denselben JTAG, über den ich debuggen 
will, und nach dem setzen des Breakpoints bei main bekomme ich keinernei 
Breakpoints angespielt. Ich kann lediglich von vector__000 mit next und 
step weiter gehen, jedoch nicht b-orientiert und somit ist es witzlos.

Autor: D a v i d K. (oekel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang noch mal die Prozedur.

#############################
--program hätte ich weglassen können, da eh deprecated und ich zuvor die 
hex auf den chip gebraten habe.

Könnte es noch sein, dass beim extrahieren der ihex aus der elf Dinge zu 
beachten sind? (Also dem chip Infos fehlen?)
#############################

Grüße David, der jetzt ohne Debugger wieder blind programmieren muss :(
Oh wie ich es hasse...

Autor: D a v i d K. (oekel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.

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