El Fichero .HEX explicado

[RedPic]

Prefacio u introito

Continúo con mi costumbre de publicar lo que aprendo para que otros puedan aprender lo que yo he aprendido durante mi aprendizaje .. (demasiados aprenderes para tan poca frase así que ahí lo dejamos )

Como últimamente he estado batallando con la interpretación de estos ficheros .HEX he tenido que enterarme de cómo están construidos así que aquí tenéis un poco de información de ellos, útil sobre todo para los nuevos diseñadores de grabadores de PIC's o para los que estén entrando en el tema de los Bootloadores. Ambos deben empezar por conocer esto de los .HEX

Introducción al asunto

Cada vez que compiláis u ensambláis un programa fuente vuestro compilador u ensamblador genera un fichero .HEX cuyo contenido se corresponde exactamente con lo que ha de ser grabado en la memoria de programa (o EEPROM) del PIC.

Fijaos que he dicho "se corresponde" y no que sea exactamente lo que ha de ser grabado en el PIC, no es una "imagen" de la memoria de programa del PIC, sino una serie de instrucciones que el grabador de PIC's o el Bootloader que utilicemos sabe interpretar y por lo tanto grabar lo que corresponde exactamente en su sitio.

Es la explicación o interpretación de este formato de lo que trata este post.

En fondo un fichero .HEX no es mas que una lista de direcciones de memoria y lo que contiene cada una de estas posiciones.

Mas adelante veremos cómo están codificadas las direcciones y su contenido. Ahora vamos a ver un poco de Historia: El formato .HEX es del fabricante de micros INTEL que lo inventó allá por los años 70 del siglo pasado para usarlo exactamente para lo mismo que nosotros lo estamos usando ahora pero para sus micros 8085 y otros cacharros antediluvianos por el estilo (no reíros pero yo los he programado  ) y desde entonces está en uso. Muchos otros fabricantes lo han adoptado como propio y otros lo han copiado cambiando esto y aquello para al final hacer lo mismo (por ejemplo el SRecord de Motorola y otros)

Aunque hay tres tipos de ficheros HEX: de 8 bits, de 16 bits y de 32 bits también llamados I8HEX, I16HEX e I32HEX respectivamente vamos a ver solo el de 8 bits que es el que más utilizamos para nuestros PIC's 16F y 18F, el resto son muy parecidos pero no iguales y lo dejamos para otro momento.

Descripción

Un fichero .HEX es un fichero de texto. Por lo tanto puede ser editado con un notepad o similar.

Una muestra de su apariencia es:

:020000040000FA
:1000000043EF00F0EA6A070EE96EEF500DE0060ECE
:10001000016E006A002EFED7012EFBD77B0E006E0C
:10002000002EFED7EF2EF3D7000C0990099208524C
:1000300002E0098001D0098207C003F00650D8B45D
:100040000706060603101EE0000E0AB2010E0B6E34
:10005000000E09B0010E0B24016EE8B002D0819CA5
:1000600001D0818C000E0AB2010E0B6E000E09B297
:10007000010E0B24016EE8B002D0819C01D0818C6E
:100080000A2ADAD7000CF86AD09EEA6AE96AC150F7
:10009000C00B0F09C16E070EB46E040E066EFA0E89
:1000A000076EB0DF062EFBD7076A190E066E086AC8
:1000B000BCDF040E066EFA0E076EA4DF062EFBD719
:1000C000076A190E066E010E086EAFDFE6D7030051
:020000040030CA
:0E000000000C1E1F008381000FC00FE00F4098
:00000001FF
;PIC18F4550


Consiste en una serie de líneas consecutivas que empiezan siempre por el carácter ":" (dos puntos) salvo los comentarios que usan ";" (punto y coma) y terminadas en [0x0D][0x0A] (Fín de línea, Retorno de Carro)

Todos números: Longitudes, direcciones y datos están expresados en HEXADECIMAL mediante sus caracteres ASCII correspondientes.

La estructura de una línea es:

• Start code Un caracter, ":" para líneas con contenido, ";" para comentarios.
• Byte count Dos caracteres HEX que indican el número de datos en Data.
• Address Cuatro caracteres HEX para la dirección del primer dato en Data.
• Record typeDos caracteres HEX que indican el tipo de línea, de 00 a 05. (ver mas abajo)
• Data Secuencia de 2 * n caracteres HEX correspondientes a los Byte count datos definidos antes.
• ChecksumDos caracteres HEX de Checksum calculado según el contenido anterior de la línea en la forma: El byte menos significativo del complemento a dos de la suma de los valores anteriores expresados como enteros los caracteres hexadecimales  (sin incluir ni el Start code ni al él mismo)

Cada línea puede expresar según su Record type:

• 00 data record: Línea de datos, contiene la dirección del primer dato y la secuencia de datos apartir de ésa.
• 01 End Of File record: Línea de Fin del Fichero HEX. Indica que se han acabado las líneas de datos. Usualmente es ":00000001FF"
• 02 Extended Segment Address Record: Usado para procesadores 80x86 (No nos interesa aquí)
• 03 Start Segment Address Record: Usado para procesadores 80x86 (No nos interesa aquí)
• 04 Extended Linear Address Record: Si las líneas de datos que sigan a ésta necesitan una dirección mayor que la de 16 bits ésta línea aporta los otros 16 bits para completar una dirección completa de 32 bits. Todas las líneas que sigan a esta deben completar su dirección con hasta los 32 bits con el contenido de la última línea de tipo 04
• 05 Start Linear Address Record: Usado para procesadores 80386 o superiores (No nos interesa aquí)

Nuestro Ejemplo

Podemos así entonces interpretar nuestro ejemplo anterior de la siguiente forma:

: 02 0000 04 0000 FA
-> Línea relevante, con dos bytes de información, de tipo 04 : luego las direcciones siguientes se complementan a 32 bits con 0x0000, 0xFA es el checksum.
: 10 0000 00 43 EF 00 F0 EA 6A 07 0E E9 6E EF 50 0D E0 06 0E CE
-> Línea relevante, con 16 bytes de información, de tipo 00 : así que hay que escribir 0x43 (en 0x00000000), 0xEF (en 0x00000001), ... , 0x0E (en 0x0000000F). 0xCE es el checksum.
: 10 0010 00 01 6E 00 6A 00 2E FE D7 01 2E FB D7 7B 0E 00 6E 0C
-> Línea relevante, con 16 bytes de información, de tipo 00 : así que hay que escribir 0x01 (en 0x00000010), 0x6E (en 0x00000011), ... , 0x6E (en 0x0000001F). 0x0C es el checksum.
...
...
...
: 02 0000 04 0030 CA
-> Línea relevante, con dos bytes de información, de tipo 04 : luego las direcciones siguientes se complementan a 32 bits con 0x0030, 0xCA es el checksum.
: 0E 0000 00 00 0C 1E 1F 00 83 81 00 0F C0 0F E0 0F 40 98
-> Línea relevante, con 14 bytes de información, de tipo 00 : así que hay que escribir 0x00 (en 0x00300000), 0x0C (en 0x00300001), ... , 0x40 (en 0x0030000D). 0x98 es el checksum.
:00000001FF
-> Línea relevante. Fin de Fichero HEX
;PIC18F4550
-> Línea irrelevante. Comentario.

Bueno, y eso es todo por hoy. Espero que os aproveche. 

[doppel]

exelente DON DIEGO!!! gracias por compartir este tipo de información  el articulo está muy interesante.-

saludos

Hernán

[MLO__]

MUCHISIMAS GRACIAS MAESTRO DIEGO !!!!!!!!

Saludos

[Cryn]

Gracias Maestro Rojo, muy buena explicación, y ademas de util, es muy bueno aprender con ud.

muchas gracias

[migsantiago]

Hola Redpic

Estoy estudiando tu tutorial para ver si puedo generar un programa que convierta archivos hex a una lista de instrucciones dadas en binario, pero me atoré en la parte en donde dices...

-> Línea relevante, con 16 bytes de información, de tipo 00 : así que hay que escribir 0x43 (en 0x00000000), 0xEF (en 0x00000001), ... , 0x0E (en 0x0000000F). 0xCE es el checksum.

Me atoré porque comentas que se escribe 1 byte de información (0x43) en la primera dirección y luego otro byte de información en la segunda dirección.

El pic16 tiene instrucciones de 14 bits de largo, las cuales son mayores que un byte, ¿0x43 correspondería al byte menos significativo de la primera dirección y 0xEF al byte más significativo de la primera dirección? Es decir...

Dirección - Contenido
0x0000      0xEF43

¿o es al revés?

Dirección - Contenido
0x0000      0x43EF

Parece tener más sentido en la última combinación ya que los bits 15 y 14 de una instrucción de pic16 no existen y se consideran como ceros, por lo que 0xef43 no existe como instrucción pic.

Gracias 

[RedPic]

Ufff Santiago .. me pillas en fuera de juego.

Lo que si puedo decirte es que el bootloader trata es información exactamente como la describo: escribe el byte correspondiente en la dirección dada.

Así "trasladado" a C de bootloader esta línea

:1000000043EF00F0EA6A070EE96EEF500DE0060ECE

sería

int8 buffer[0x10] = {0x43, 0xEF, 0x00, 0xF0, 0xEA, 0x6A, 0x07, 0x0E, 0xE9, 0x6E, 0xEF, 0x50, 0x0D, 0xE0, 0x06, 0x0E}
write_program_memory(0x0000, &buffer, 0x10);

sabiendo que write_program_memory admite como parámetros Address, dataptr y Count y entonces escribe consecutivamente, a partir de la dirección Address, un número Count de bytes tomados a partir de dataptr.

Lo que signifique cada byte escrito en esas posiciones y como se conjugan para dar instrucciones de mas de un byte en los PIC's simplemente lo desconozco. Mi experiencia con estos temas es con otros tipos de micros en los que las instrucciones son solo de un byte seguidos por el número oportuno de argumentos ( Z80, 8081 y otros por el estilo) y la implementación en PIC's no la he estudiado (por ahora). Lo siento.

[migsantiago]

No hay problema Diego. 

Esto amerita una investigación más profunda. Estoy simulando un pic16 con código vhdl y para el banco de pruebas (memoria de programa) debo crear un archivo de texto con los códigos de operación en binario.

Voy a ver si puedo aportar algo después de hacer ingeniería inversa a un hex. 

[migsantiago]

Dando una revisión rápida a un ejemplo que compilé...

Código ASSEMBLER

efe equ 0x00
org 0x0000
nop
return
retfie
movwf efe
clrw
clrf efe
subwf efe,1
decf efe,1
iorwf efe,1
andwf efe,1
xorwf efe,1
addwf efe,1
movf efe,1
comf efe,1
incf efe,1
decfsz efe,1
rrf efe,1
rlf efe,1
swapf efe,1
incfsz efe,1
bcf efe,1
bsf efe,1
btfsc efe,1
btfss efe,1
call 0
goto 0
movlw efe
retlw efe
iorlw 0
andlw 0
xorlw 0
sublw 0
addlw 0
end


Código Máquina (checado con winpic800)

nop    0000
return 0008
retfie 0009
movwf  0080
clrw   0103
clrf   0180
subwf  0280
...


Código .HEX generado con mplab

:020000040000FA
:1000000000000800090080000301800180028003D5
:10001000800480058006800780088009800A800BA4
:10002000800C800D800E800F801080148018801C42
:10003000002000280030003400380039003A003C2D
:02004000003E80
:00000001FF


Código .HEX separado por bytes

:02 0000 04 0000FA
:10 0000 00 00 00 08 00 09 00 80 00 03 01 80 01 80 02 80 03 D5
:10001000800480058006800780088009800A800BA4
:10002000800C800D800E800F801080148018801C42
:10003000002000280030003400380039003A003C2D
:02004000003E80
:00000001FF

Interpretación
Segunda línea
:10 0000 00 00 00 08 00 09 00 80 00 03 01 80 01 80 02 80 03 D5

16 bytes de info
Dirección de inicio 0x0000
Data record
Dir 0x0000 00
dir 0x0001 00
dir 0x0002 08
dir 0x0003 00
dir 0x0004 09
dir 0x0005 00
...

Interpretando para el pic (14 bits por dirección)...

dir 0x0000 0000
dir 0x0001 0008
dir 0x0002 0009
dir 0x0003 0080
dir 0x0004 0103
dir 0x0005 0180
dir 0x0006 0280

Sólo hay que invertir la posición de los bytes. El primero que aparece es el menos significativo; el segundo que aparece es el más significativo.

El programa para la conversión parece simple, espero poder escribirlo en estos días. 

Gracias Diego

[migsantiago]

Ya terminé el programa para la conversión de .hex a .txt.

El programa recibe un .hex generado con mplab o ccs y extrae la memoria de programa y la vuelca en un archivo .txt en código ascii.

Por ejemplo, si se tiene el programa:

Código:

efe equ 0x00
org 0x0000
nop
return
retfie
movwf efe
clrw
clrf efe
subwf efe,1
decf efe,1
iorwf efe,1
andwf efe,1
xorwf efe,1
addwf efe,1
movf efe,1
comf efe,1
incf efe,1
decfsz efe,1
rrf efe,1
rlf efe,1
swapf efe,1
incfsz efe,1
bcf efe,1
bsf efe,1
btfsc efe,1
btfss efe,1
call 0
goto 0
movlw efe
retlw efe
iorlw 0
andlw 0
xorlw 0
sublw 0
addlw 0
end

El archivo.txt que genera el programa es el siguiente:

Código:

00000000000000
00000000001000
00000000001001
00000010000000
00000100000011
00000110000000
00001010000000
00001110000000
00010010000000
00010110000000
00011010000000
00011110000000
00100010000000
00100110000000
00101010000000
00101110000000
00110010000000
00110110000000
00111010000000
00111110000000
01000010000000
01010010000000
01100010000000
01110010000000
10000000000000
10100000000000
11000000000000
11010000000000
11100000000000
11100100000000
11101000000000
11110000000000
11111000000000
11111111111111
11111111111111

En donde cada línea representa la instrucción del pic16 en modo binario, teniendo por ejemplo a NOP = 00000000000000 o teniendo a SUBLW 0x00 = 11110000000000. Se respeta la posición en la memoria como en org 0x05, dejando las líneas sin código como 11111111111111, que equivale a un pic nuevo o a una instrucción ADDLW 0xFF.

¿Qué no hace el programa? No lee la EEPROM ni los fusibles de configuración del pic; tampoco identifica al pic para el que fue ensamblado.

Al programa se le puede meter más mano, incluso teniendo el txt ya convertido se puede hacer un desensamblador muy básico, pero eso ya existe en otros programas como en Winpic800.

Adjunto el código fuente y el programa para quiénes lo vean útil. 

http://www.4shared.com/file/70640741/6ec22da6/Hex2TxtSan.html

Hay un bug que no supe corregir: si generan un archivo.txt con el mismo nombre por segunda vez les marca error. Solo hay que quitarle la propiedad de Solo Lectura al archivo y listo

[MLO__]

 

Felicitaciones mig .... eres grande!!!!

Saludos

[RedPic]

Muy bueno, Santiago, tu análisis. Me gusta. 

[migsantiago]

Gracias compañeros. 

[Cryn]

una pregunta, como están los fuses dentro del .hex??

saludos

[migsantiago]

Leyendo la guía de Diego los puedes encontrar.

Te adjunto las últimas líneas del HEX de un PIC16F88:

Código:

:1003B000831605118312E029831605158312E0299F
:1003C000952963000A148A100A118207CA29D029C4
:0403D000D629DC2925
:04400E00222EFF3F20
:00000001FF
;PIC16F88
;CRC=AB3F  CREATED="05-Jul-09 11:39"

Viendo la datasheet del mismo te indica que los configuration bits están en 0x2007 y 0x2008.

Sabiendo que las palabras del PIC en su memoria de programa toman 14 bits, entonces cada palabra toma 2 bytes. Hay que multiplicar 0x2007 por 2.

0x2007 * 2 = 0x400E

Buscando la palabra se encuentra al final...

Código:

:04400E00222EFF3F20

Lo que dice es:

04 bytes de datos
400E dirección de inicio
00 data record
222E es el contenido de 0x2007 (invertidos)
FF3F es el contenido de 0x2008 (invertidos)
20 Checksum de la línea

Y si aún así no lo puedes encontrar, puedes usar WinPic800 para corroborarlo:

[Cryn]

ok entendido, supongo q siempre los fuses o config siempre están en la ultima linea antes de terminar con 1FF

y en un bootloader quizá no siempre sea necesario cambiarlos no?

saludos, gracias por la respuesta

[migsantiago]

Los fuses pueden estar en cualquier lugar del archivo hex, pero los compiladores acostumbran colocarlos al final. Solo busca la dirección hexadecimal y multiplícala por 2 para encontrarlos. Esa dirección debe aparecer en el 4to, 5to, 6to y 7o caracter de una línea:

:04400E00222EFF3F20

Nunca he usado bootloaders, no sabría contestarte.

[Cryn]

y lo mismo con la EEPROM verdad? multiplicar por 2 y se verían los datos a continuación

como es que funciona el Record type 04? no lo logro entender

[RedPic]

Cryn, los registros de tipo 00, de datos, tienen el Address inicial del primer byte a colocar con solo 16 bits, cuatro dígitos en hexadecimal ... sin embargo hay direcciones en los PIC's mayores que 0xFFFF por lo que entonces se usan los registros de tipo 04, sirven para completar direcciones mayores, hasta 32 bits. Es como añadirle un Offset a todas las direcciones de los registros que vengan a continuación.

Así si tenemos dos registros como estos (separo los dígitos significativos):

:02 0000 04 0030 CA
:0E 0000 00 00 0C 1E 1F 00 83 81 00 0F C0 0F E0 0F 40 98

El primero, el de tipo 04, indica que la dirección de los que le siguen deben completarse con  0030 para formar una dirección de 32 bits.

El siguiente registro, el de tipo 00, indica que hay que poner 0E bytes a partir de la dirección 0000, pero como tenemos un offset anterior dado por el registro de tipo 04, la dirección real será 00300000 para el primer byte, 00300001 para el segundo, 00300002 para el tercero .... etc.

Fíjate que los HEX acostumbran a empezar por un registro de tipo 04 en la forma:

:020000040000FA

que indica que lo que viene a continuación debe empezar en 0000. Esto sirve para prevenir que el PIC pueda haberse quedado con un offset anterior y que al recibir una nueva linea de datos lo envíe a cualquier sitio. Es como inicializar el puntero de memoria para empezar a recibir datos.  
  


  

[migsantiago]

y lo mismo con la EEPROM verdad? multiplicar por 2 y se verían los datos a continuación

como es que funciona el Record type 04? no lo logro entender

Según una prueba que hice con un hex, es cierto, se multiplica también por 2...

Código:

:10 4200 00 6400 6600 6700 6800 6A00 6B00 6C00 FF00 D5

y desperdician un byte poniéndolo a 0x00. Esto equivale a:



en donde 0x2100 es donde empieza la memoria eeprom en los PIC16.

Sobre el 04 creo que Redpic ya te lo explicó muy bien. El 04 no hace falta en ningún PIC16 porque no superan las 2^16 direcciones en ninguna de sus memorias.

[Cryn]

aaaah ok,entonces un  04 viene de la mano con un 00, si hay un 04 se usa la siguiente linea con ese offset, ahora si. Gracias redpic

ok, entonces con la EEPROM, gracias mig

ahora a meterle mano al bootloader, que no se esta dejando

saludos amigos.