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

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

El software ST-LINK Utility parece ser una buena elección. Puede apuntarlo a un archivo .hex y configurarlo en "modo automático". Luego detecta cuando un dispositivo está conectado al programador y escribe en él. Luego, conecta otro dispositivo que se escribirá automáticamente. Muy suave.

Así que aquí está el problema: parece que el firmware escrito en el dispositivo por Eclipse es en realidad diferente al archivo hexadecimal generado por Eclipse .

Esto es lo que estoy viendo:

  1. Programo el dispositivo n. ° 1 a través de Eclipse. Quito 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. Quito el programador. El código no se ejecuta , incluso después de reiniciar el dispositivo.
  4. Uso la utilidad ST-LINK para leer el código (en funcionamiento) directamente desde el dispositivo n.º 1.
  5. Uso la utilidad ST-LINK para programar este código en el dispositivo #2. Ahora, el dispositivo #2 funciona correctamente .

Bien, entonces el archivo .hex generado debe ser incorrecto. 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 es necesario)

hexadecimal

Por último, mis preguntas:

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

Tenga en cuenta que estoy creando la configuración de "Depuración". Cuando Eclipse se conecta al dispositivo de destino, programa el código y me permite depurar. Si elimino el hardware del depurador, el dispositivo aún funciona. Es decir, el código funciona bien sin el depurador adjunto.

Parece que tienes un problema de comunicaciones con bits/bytes caídos/insertados. Parece un problema clásico de almacenamiento en búfer/control de flujo, con el búfer de entrada desbordándose después de que se hayan transferido 48 bytes. ¿Puede ejecutar el programador a una velocidad más lenta? Además, asegúrese de tener un terreno común en todo momento.
"Tenga en cuenta que estoy creando la configuración de "Depuración"." - ¿Qué sucede si construye con la configuración de 'lanzamiento'?
@Mick Gracias por eso. Veo los valores cambiados de los que estás hablando. Sin embargo, el archivo que funciona es el que leí de un dispositivo y escribí en otro. El archivo que no funciona proviene directamente del IDE y nunca se ha transmitido...
@BruceAbbott: No había configurado una configuración de 'lanzamiento', así que me tomó un tiempo probar esto. Adivina qué; ¡funcionó! Si desea convertir su comentario en una respuesta, me gustaría aceptarlo. Aparentemente, Eclipse programa el código de 'depuración' (usando el archivo .elf) de tal manera que puede ejecutarse sin el depurador adjunto, aunque el archivo hexadecimal de 'depuración' no puede ejecutarse por sí solo.

Respuestas (1)

¿Quizás Eclipse usa gcc para crear el hexágono y luego lo modifica en el camino hacia el dispositivo?

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

  1. los archivos individuales se compilan en .oarchivos de objetos
  2. los archivos de objetos y las bibliotecas están vinculados a un .elfarchivo
  3. objcopygenera un .hexarchivo de.elf
  4. y finalmente se imprime el tamaño por size, pero este último paso es puramente informativo.

Sin embargo, el depurador funciona con el .elfdel paso 2, porque tiene símbolos y otras ayudas de depuración, que se pierden al convertir a .hex. Por lo tanto, echaría un vistazo muy de cerca al paso 3, y quizás .elftambién al archivo.

Así es como debería verse el paso 3 en la ventana de la consola de compilació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

Primero, verifique si hay advertencias u otras señales sospechosas. ¿Se regenera cuando lo elimina y compila el proyecto? ¿Y cuando quitas el .elf? ¿Son correctas las marcas de tiempo del archivo? Intenta repetirlo desde la línea de comando. Para que eso funcione, deberá especificar la ruta completa arm-none-eabi-objcopyen su cadena de herramientas o incluirla en su archivo PATH. Asegúrese de que la ruta de la cadena de herramientas esté configurada correctamente en Eclipse y de que no haya otras versiones objcopy, especialmente en su archivo PATH.

Puede examinar el .elfcon arm-none-eabi-objdump. Enumere el "directorio" con -h, se ve así

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

Verifique los campos LMAy Sizepara cada sección. ¿Hay una superposición? Vuelque el contenido -sy examínelo alrededor de la dirección del problema.

¿Por qué este archivo hexadecimal es diferente al código programado en el dispositivo?
RespuestasAquíPolítica de privacidad1y, 0v