avr-gdb no se detiene en el punto de interrupción

Navega tus respuestas
0

Estoy intentando depurar el código en un microcontrolador AVR de 8 bits (Atmega328P) a través de debugWIRE utilizando AVaRICE, avr-gdb y el depurador JTAGICEmkII.

Estoy haciendo los siguientes pasos:

Compile el código con g2 información de depuración en formato stabs sin optimizaciones:

avr-gcc -Wall -g2 -gstabs -O0 -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega328p -DF_CPU=1000000UL

Crear hexadecimal:

avr-objcopy -R .eeprom -O ihex lambda.elf lambda.hex

hex de carga:

avrdude -pm328p -cjtag2isp -B10 -Uflash:w:lambda.hex:a

Inicia AVaRICE: 

avarice -2 -w -B10 -j usb :4242
AVaRICE version 2.11, Jan 17 2014 02:51:59

JTAG config starting.
Found a device: JTAGICEmkII
Serial number:  07:00:00:00:5c:3c
Reported debugWire device ID: 0x950F
Configured for device ID: 0x950F atmega328p
JTAG config complete.
Preparing the target device for On Chip Debugging.
Waiting for connection on port 4242.

Inicia avr-gdb:

avr-gdb lambda.elf 

Reading symbols from lambda.elf...done.
(gdb) target remote localhost:4242
Remote debugging using localhost:4242
0x00000000 in __vectors ()

Establezca un punto de interrupción dentro del bucle principal en main () 

(gdb) break lambda.c:74
Haltepunkt 1 at 0x2ae2: file ../lambda.c, line 74.

Y continúe, esperando que el programa se detenga en el punto de interrupción: 

(gdb) continue
Continuing.

El programa comienza bien pero nunca se detiene. Puedo detenerlo con CTRL+C : 

^C
Program received signal SIGINT, Interrupt.
0x00002d2e in getTime () at ../interrupts.c:51
51                      time = ints >> 5;

Lo que me desconcierta entonces es que si miro la información de depuración que se ha volcado con

avr-objdump -g lambda.elf > debug.txt

en la misma línea de código, hay otra dirección:

/* file ../interrupts.c line 51 addr 0x2d10 */

e incluso si establezco un punto de interrupción exactamente en esa dirección 0x00002d2e donde se interrumpió el programa (la función getTime () se llama repetidamente): 

(gdb) break *0x00002d2e
Haltepunkt 2 at 0x802d2e

el programa nunca se detendrá, ¿por qué el punto de interrupción está establecido en 0x802d2e ?

¿Es normal que las direcciones no coincidan o podría ser la razón por la que los puntos de interrupción no funcionan? ¿Necesito establecer algún desplazamiento de dirección?

Originalmente traté de depurar desde Eclipse con el complemento avr-eclipse, y muestra exactamente el mismo comportamiento, lo que supongo que no es sorprendente ya que usa las mismas herramientas detrás de escena.

    
pregunta Torsten Römer

1 respuesta

1

Por lo tanto, intentaré responder mi pregunta (por ahora).

ACTUALIZACIÓN: Como se menciona en este tutorial , compilar con la opción -ggdb debería resolver el problema, pero no he podido probarlo hasta ahora.

Parece que las instrucciones BREAK que provocan que la CPU del AVR ingrese en el modo detenido no están insertadas, tal vez AVaRICE no pueda hacer eso.

Para las pruebas, inserté un punto de interrupción "permanente" utilizando un ensamblador en línea al final de la línea de código donde quiero romper:

asm("break");

Y ver allí, la ejecución se detiene: 

(gdb) target remote localhost:4242
Remote debugging using localhost:4242
0x00000000 in __vectors ()
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
measure () at ../sensors.c:110
110             asm("break");

cuando intentas pisar: 

(gdb) next
measure () at ../sensors.c:110
110             asm("break");
The program is stopped at a permanent breakpoint, but GDB does not know
how to step past a permanent breakpoint on this architecture.  Try using
a command like 'return' or 'jump' to continue execution.

y jump ing a la siguiente línea de código funcionan, por lo que es al menos una solución alternativa, también utilizable en Eclipse:

AsíqueahoraestáapuntodedescubrirporquénoseinsertaronesasinstruccionesBREAK...

Encuantoaladiscrepanciadedirecciones,parecequehahabidounproblemaenelprocesodecompilación.ComencéaconstruirenlaconfiguracióndedepuraciónenEclipse,ydealgunamaneraelcomando"avr-objcopy" para crear el .hex para destellar tenía el prefijo "-" en la configuración de Eclipse y por lo tanto fallaba, y probablemente estaba destellando una versión anterior.

Por ahora creé el .hex manualmente, ahora las direcciones en gdb y el desmontaje coinciden.

    
respondido por el Torsten Römer

Lea otras preguntas en las etiquetas

Elección del condensador de salida para la conversión de energía Evaluación cualitativa de las características del dominio de tiempo de un diagrama de Bode