El programa solo se ejecuta cuando se depura en GDB - usando Open OCD y Olimex arm-usb-ocd-h jtag para programar at91sam3su

Estoy tratando de hacer que mi chip de brazo Atmel at91sam3u cortex-m3 haga que un LED parpadee. Tengo un programador jtag Olimex ARM-USB-OCD-H y estoy usando Open OCD en OS X para programar mi chip. Estoy usando los scripts de inicio de Open OCD provistos para el programador jtag y mi chip. No tengo problemas para compilar y vincular el programa, y ​​parece que puedo cargar correctamente el programa en el chip. Sin embargo, el LED solo parpadea cuando ejecuto el programa a través de gdb. Funciona ya sea que paso a través de él o lo ejecuto continuamente.

Para que funcione en gdb, primero ejecuto 'openocd' y luego en otra terminal (se omiten los comentarios de gdb):

$ arm-none-eabi-gdb blinky/blinky.elf
(gdb) target remote :3333
(gdb) load
(gdb) cont

Esto funciona sin problemas y el LED parpadea. Por supuesto, cuando salgo de gdb, el programa se detiene y el LED permanece en el estado que tenía en ese momento. Si hago clic en el botón de reinicio del chip, el LED pasa a un estado neutral (ligeramente encendido).

Para intentar simplemente programar el chip, ejecuto 'openocd' y luego en otra terminal:

$ telnet localhost 4444
> halt
target state: halted
target halted due to debug-request, current mod
xPSR: 0x81000000 pc: 0x00080107 msp: 0x20000598
> flash write_image blinky/blinky.elf
wrote 3044 bytes from file blinky/blinky.elf in 0.314594s (9.449 KiB/s)
> reset run
TAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

No hay errores, pero el LED no parpadea, permanece en un estado neutral.

El script del enlazador configura el programa (.text) para que se coloque en la memoria flash0. Por lo tanto, he intentado configurar gpnvm bit 1, ya que es el bit de selección de arranque sram vs flash de acuerdo con la hoja de datos at91sam3. Esto no ayudó, y parecía haber impedido que el formulario gdb se ejecutara correctamente.

¿Necesito flashear la placa con algún tipo de gestor de arranque que pueda cargar programas desde el banco flash0? Supuse que el chip venía con esto.

Todavía no he podido cargar el .text en sram en lugar de flash0 porque he tenido problemas para cambiar el script del enlazador. Tengo que hacer esto.

Nota: El chip at91sam3u está en una placa de circuito impreso personalizada diseñada como parte de un proyecto de diseño de estudiante. Por lo tanto, es posible que se haya cometido un error durante el diseño de la pcb... sin embargo, pensaría que en ese caso tampoco funcionaría correctamente en gdb.

Gracias.

Tuve este problema hace un tiempo con IAR y un SAM7X. En ese caso, resultó que el depurador estaba haciendo lo que debería haber hecho el código de inicio y, por lo tanto, no funcionaría por sí solo. Miraría la sección de inicio para ver si falta algo. El SAM3U tiene un código de secuencia de inicio mucho más simple, por lo que tal vez verifique la inicialización del reloj y las cosas de PMC, y más importante, cosas como los vectores de interrupción y reinicio.
¡Has producido un HeisenBug! Es un error de software que desaparece cuando intentas observarlo.

Respuestas (3)

$ telnet localhost 4444
> halt
target state: halted
target halted due to debug-request, current mod
xPSR: 0x81000000 pc: 0x00080107 msp: 0x20000598
> flash write_image blinky/blinky.elf

Por lo general, necesita reset initantes de un borrado / escritura flash, haltpuede no ser suficiente. en gdbel esta monitor reset init.

El flash también debe borrarse antes de escribir:flash write_image erase unlock blinky/blinky.elf

Hmm, cuando hago un reset initen gdb oa través de telnet, obtengo esto: (gdb) monitor reset JTAG tap: sam3.cpu ... \ Halt timed out, wake up GDB \ timed out while waiting for target halted \ TARGET: sam3.cpu - Not halted \ in procedure 'reset'individualmente, sin embargo, los comandos funcionan bien... No estoy seguro si esto es un problema, o simplemente sucede reset initdemasiado rápido.
Esto me sucede cuando reset_configno coincide con el cableado real de las líneas de reinicio. Puedes reset_config noneprobar

Diste una pista bastante grande cuando dijiste que el LED estaba en un estado "neutral". No existe un estado "neutro" para una salida digital que funcione correctamente, por lo que probablemente quiso decir que el LED está débilmente iluminado. Y eso generalmente significa que el pin que impulsa el LED se enciende y apaga tan rápido que no puede ver el parpadeo. No mostró su código, por lo que no podemos juzgar su bucle de retraso, y es posible que su depurador haya ralentizado la ejecución del código lo suficiente como para que parezca funcionar.

Otra cosa a considerar es que el depurador JTAG puede haber tomado el control de la entrada RESET. Si ese es el caso, deberá desconectar el depurador para ver el funcionamiento "normal". Supongo que ha escrito los valores adecuados para el puntero de pila inicial y el valor de PC en las ubicaciones 0x0 y 0x4, por supuesto.

Pensé lo mismo sobre mi bucle de retardo... pero cuando hago un programa que simplemente deja el LED encendido o apagado, el resultado es el mismo. Funciona correctamente en gdb, pero no sin él. En cuanto al puntero de pila y la PC, mi vector_table.c es el mismo que proporciona Atmel para este chip en su manual de inicio y, hasta donde he podido entender, están configurados correctamente. Además, supongo que el programa tampoco se ejecutaría correctamente en gdb, ¿no?

Aunque la sesión de depuración se ha detenido, puede suceder que su depurador de hardware aún tenga el control de señal de RESET.

Una solución poco elegante es desconectar el depurador de su objetivo y aplicar un reinicio en frío (fuente de alimentación apagada y luego encendida).