avr-gdb nicht identische Map

[D a v i d K. (oekel)]

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?!

[Oliver S. (oliverso)]

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

[D a v i d K. (oekel)]

Aber wie komme ich dann "optisch" zum Haltepunkt 1?

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

[Oliver S. (oliverso)]

Das gdb-„Hello World“ dürfte in etwa so aussehen:

b main
continue

Oliver

[D a v i d K. (oekel)]

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.

[D a v i d K. (oekel)]

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...

[D a v i d K. (oekel)]

Lösung:
Beitrag "Anleitung JTAGICE3 Downgrade"