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

Navega tus respuestas
4

Tengo un diseño con 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 a los dispositivos. Ahora necesito programar muchos dispositivos y estoy buscando un método más rápido.

El software Utilidad ST-LINK parece ser una buena opción. Puede apuntarlo a un archivo .hex y configurarlo en "modo automático". A continuación, detecta cuando un dispositivo está conectado al programador y lo escribe. 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. 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 al programador. El código no se ejecuta , incluso después de reiniciar el dispositivo.
  4. Utilizo la utilidad ST-LINK para leer el código (en funcionamiento) directamente desde el Dispositivo # 1.
  5. Utilizo la utilidad ST-LINK para programar este código en el Dispositivo # 2. Ahora, Dispositivo # 2 funciona correctamente .

Bien, 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 es necesario)

Finalmente,mispreguntas:

¿Porquéelarchivo.hexgeneradoesincorrecto?¿QuizásEclipseusagccparacrearelhexyluegolomodificaenrutaaldispositivo?¿CómopuedohacerqueEclipsegenereunarchivohexquecoincidaconelcódigoqueprogramaenundispositivoreal?

Tengaencuentaqueestoyconstruyendolaconfiguración"Depurar". Cuando Eclipse se conecta al dispositivo de destino, programa el código y me permite depurar. Si quito el hardware del depurador, el dispositivo todavía funciona. Es decir, el código funciona bien sin el depurador adjunto.

    
pregunta bitsmack

1 respuesta

3
  

Quizás Eclipse usa gcc para crear el hex, y luego lo modifica en   ruta al dispositivo?

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

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

Sin embargo, el depurador funciona con el .elf del 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 de cerca al paso 3, y quizás también al archivo .elf .

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 otros signos sospechosos. ¿Se regenera cuando lo eliminas y construyes el proyecto? ¿Y cuando eliminas el .elf ? ¿Son correctas las marcas de tiempo del archivo? Intenta repetirlo desde la línea de comandos. Para que funcione, deberá especificar la ruta completa a arm-none-eabi-objcopy en su cadena de herramientas, o incluirla en su PATH . Asegúrese de que la ruta de la cadena de herramientas esté configurada correctamente en eclipse, y que no haya otras versiones de objcopy por ahí, especialmente en su PATH .

Puedes examinar el .elf con arm-none-eabi-objdump . Lista 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 LMA y Size para cada sección. ¿Hay una superposición? Vuelque el contenido con -s y examínelo alrededor de la dirección del problema.

    
respondido por el berendi

Lea otras preguntas en las etiquetas

por qué los teléfonos inteligentes no causan ruido en los altavoces cercanos ¿Las resistencias dependientes de la luz son estables al tiempo de escritura?