¿Por qué este archivo hexadecimal es diferente del código programado en el dispositivo?

Question

Tengo un diseño que utiliza un STM32F105 . Mi aplicación escrita en C; usando Eclipse y gcc. He estado usando Eclipse (con OpenOCD y un ST-LINK/V2 programador) para escribir el firmware en los dispositivos. Ahora necesito programar muchos dispositivos y estoy buscando un método más rápido.

El Utilidad ST-LINK El software parece ser una buena opción. Puedes apuntar a un archivo .hex y ponerlo en "modo automático". Entonces detecta cuando un dispositivo está conectado al programador y escribe en él. Luego conectas otro dispositivo que se escribirá automáticamente. Muy suave.

Este es el problema: Parece que el firmware escrito en el dispositivo por Eclipse es realmente diferente al archivo hexadecimal generado por Eclipse .

Esto es lo que estoy viendo:

1. Programo el Dispositivo#1 a través de Eclipse. Retiro el programador, reinicio el dispositivo y funciona bien.
2. Encuentro el archivo .hex generado por Eclipse (.../Debug/application.hex).
3. Programo el Dispositivo#2 usando la Utilidad ST_LINK y este archivo. Retiro el programador. El el código no se ejecuta incluso después de un reinicio del dispositivo.
4. Utilizo la Utilidad ST-LINK para leer el código (que funciona) directamente desde el Dispositivo#1.
5. Utilizo la Utilidad ST-LINK para programar este código en el Dispositivo#2. Ahora, El dispositivo #2 funciona correctamente .

OK, entonces el archivo .hex generado debe estar equivocado. Puedo usar la utilidad ST-LINK para comparar los dos archivos hexadecimales (de los pasos 2 y 4). Muestra que los archivos son idénticos hasta el final:

(haga clic para ampliar si lo necesita)

---

Por último, mis preguntas:

¿Por qué el archivo .hex generado es incorrecto? ¿Quizás Eclipse utiliza gcc para crear el hexágono, y luego lo modifica de camino al dispositivo? ¿Cómo puedo hacer que Eclipse emita un archivo hexadecimal que coincida con el código que programa en un dispositivo real?

---

Tenga en cuenta que estoy construyendo la configuración "Debug". Cuando Eclipse se conecta al dispositivo de destino programa el código y me permite depurar. Si quito el hardware de depuración, el dispositivo sigue funcionando. Es decir, el código funciona bien sin el depurador conectado.

Answer 1

Tal vez Eclipse utiliza gcc para crear el hexágono, y luego lo modifica en camino al dispositivo?

No, es al revés. Cuando compilas un proyecto en Eclipse,

1. los archivos individuales se compilan en .o archivos de objetos
2. Los archivos de objetos y las bibliotecas se enlazan en un .elf archivo
3. objcopy genera un .hex archivo de .elf
4. y finalmente el tamaño se imprime mediante size pero este último paso es puramente informativo.

Sin embargo, el depurador funciona con el .elf del paso 2, porque tiene símbolos y otras ayudas para la depuración, que se pierden al convertir a .hex . Por lo tanto, yo miraría muy de cerca el paso 3, y quizás el .elf también.

Así es como debería verse el paso 3 en la ventana de la consola de construcción de eclipse

Finished building target: app.elf

Invoking: Cross ARM GNU Create Flash Image
arm-none-eabi-objcopy -O ihex "app.elf"  "app.hex"
Finished building: app.hex

Invoking: Cross ARM GNU Print Size

En primer lugar, comprueba si hay avisos u otros signos sospechosos. ¿Se regenera cuando lo quitas y construyes el proyecto? Y cuando eliminas el .elf ? ¿Son correctas las marcas de tiempo de los archivos? Intenta repetirlo desde la línea de comandos. Para que eso funcione, tendrás que especificar la ruta completa a arm-none-eabi-objcopy en su cadena de herramientas, o incluirlo en su PATH . Asegúrese de que la ruta de la cadena de herramientas está correctamente configurada en eclipse, y que no hay otras versiones de objcopy por ahí, especialmente en su PATH .

Puede examinar el .elf con arm-none-eabi-objdump . Enumerar el "directorio" con -h , tiene el siguiente aspecto

app.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .isr_vector   0000013c  08008000  08008000  00008000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         0000b4cc  08008140  08008140  00008140  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata       0000b1c0  08013610  08013610  00013610  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .ARM          00000008  0801e7d0  0801e7d0  0001e7d0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .init_array   00000008  0801e7d8  0801e7d8  0001e7d8  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  5 .fini_array   00000004  0801e7e0  0801e7e0  0001e7e0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .data         00000a60  20000000  0801e7e4  00020000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  7 .noinit       00000004  20000a60  0801f244  00020a60  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .bss          0000cbf8  20000a68  0801f248  00020a68  2**3
                  ALLOC

Compruebe el LMA y Size campos para cada sección. ¿Hay un solapamiento? Vuelque el contenido con -s y examinarla en torno a la dirección del problema.