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.
$ 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 init
antes de un borrado / escritura flash, halt
puede no ser suficiente. en gdb
el esta monitor reset init
.
El flash también debe borrarse antes de escribir:flash write_image erase unlock blinky/blinky.elf
reset init
en 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 init
demasiado rápido.reset_config
no coincide con el cableado real de las líneas de reinicio. Puedes reset_config none
probarDiste 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.
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).
Shashank de Chintalagiri
connor lobo