HEX BIN文件分析介绍

总结：

HEX文件：由一条条具有规定格式、由16进制的数据表示特定特定信息的HEX文本记录组成的可烧写文件，每条记录中的数据包含有地址与要烧写的数据以及检验码等信息。每条烧写文本记录中若包含数据记录，那么16进制的数据与BIN文件【16进制表示时】是一样的，HEX每条文本记录多出来的就是地址与检验信息等....

BIN文件，就是直接可以烧写到存储器中的二进制文件，程序运行后，对应地址的数据与BIN是一摸一样的.我们可以打开KEIL软件，软件调试时，可以看到，C对应汇编【硬件调试时用的是反汇编】，汇编再对应相应的机器码，最左边的存储空间地址，过来就是对应的机器指令，因为这里的ARM都是Thumb指令所以每一条指令对应的是16位，两个字节，而ARM指令是32位的，4个字节，BIN文件就是这些机器码的集合，HEX文件中的数据记录也是这些机器码得集合，不过HEX文件中除了这些数据记录还有地址信息等

Thumb指令可以看做是ARM指令压缩形式的子集，是针对代码密度^【¹^】的问题而提出的，它具有16为的代码密度。Thumb不是一个完整的体系结构，不能指望处理程序只执行Thumb指令而不支持ARM指令集。因此，Thumb指令只需要支持通用功能，必要时，可借助完善的ARM指令集，例如：所有异常自动进入ARM状态。

在编写Thumb指令时，先要使用伪指令CODE16声明，而且在ARM指令中要使用BX指令跳转到Thumb指令，以切换处理器状态。编写ARM指令时，可使用伪指令CODE32声明。

代码密度：单位存储空间中包含的指令的个数。例如

ARM指令是32位的，而Thumb指令时16位的，如果在1K的存储空间中，可以放32条ARM指令，就可以放64条Thumb指令，因此在存放Thunb指令时，代码密度高。

arm存储格式有小端结尾（低字节存储在低位，即由小到大）、大端结尾（最高字节存储在低位，即由大到小）。arm存储以字节为单位，地址空间为2^32个字节共4G空间。arm存储访问由对齐访问和非对齐访问。arm指令长度固定为一个字长，即32位

截图从反汇编，红色部分也是BIN文件的内容

HEX文件截图
可以从上面的两幅图片上的两种颜色框的对应关系看出其中的关系

Intel HEX文件是记录文本行的ASCII文本文件，在Intel HEX文件中，每一行是一个HEX记录，由十六进制数组成的机器码或者数据常量。

Intel HEX文件经常被用于将程序或数据传输存储到ROM、EPROM，大多数编程器和模拟器使用Intel HEX文件。

很多编译器的支持生成HEX格式的烧录文件，尤其是Keil c。但是编程器能够下载的往往是BIN格式，因此HEX转BIN是每个编程器都必须支持的功能。

HEX格式文件以行为单位，每行由“：”（0x3a）开始，以回车键结束(0x0d,0x0a)。

行内的数据都是由两个字符表示一个16进制字节，比如”01”就表示数0x01；”0a”，就表示0x0a。

对于16位的地址，则高位在前低位在后，比如地址0x010a，在HEX格式文件中就表示为字符串”010a”。

下面为HEX文件中的一行：:10 0000 00 FF0462FF051EFF0A93FF0572FF0A93FF BC

“：”表示一行的开始。

“：”后的第1，2个字符“10”表示本行包含的数据的长度，这里就是0x10即16个。

第3，4，5，6个字符“0000”表示数据存储的起始地址，这里表示从0x0000地址开始存储16个数据，其中高位地址在前，低位地址在后。

第7，8个字符“00”表示数据的类型。该类型总共有以下几种：

00 ----数据记录

01 ----文件结束记录

02 ----扩展段地址记录

04 ----扩展线性地址记录这里就是0x00即为普通数据记录。

自后的32个字符就是本行包含的数据，每两个字符表示一个字节数据，总共有16个字节数据跟行首的记录的长度相一致。

最后两个字符表示校验码。

每个HEX格式的最后一行都是固定为：:00000001FF 以上的信息其实就足够进行HEX转BIN格式的程序的编写。

首先我们只处理数据类型为0x00及0x01的情况。0x02表示对应的存储地址超过了64K，由于我的编程器只针对64K以下的单片机，

因此在次不处理，0x04也是如此

什么是Intel HEX格式?

回答:

Intel HEX文件是记录文本行的ASCII文本文件,在Intel HEX文件中,每一行是一个HEX记录

由十六进制数组成的机器码或者数据常量,Intel HEX文件经常被用于将程序或数据传输

存储到ROM.EPROM,大多数编程器和模拟器使用Intel HEX文件.

记录格式

一个Intel HEX文件可以包含任意多的十六进制记录,每条记录有五个域,下面是一个记录的格式.

:llaaaatt[dd...]cc

每一组字母是独立的一域,每一个字母是一个十六进制数字,每一域至少由两个十六进制数字组成,下面是字节的描述.

:冒号是每一条Intel HEX记录的开始

ll 是这条记录的长度域,他表示数据(dd)的字节数目.

aaaa 是地址域,他表示数据的起始地址<如果是数据记录,这表示将要烧录的这条记录中的数据在EPROM中的偏移地址,

对于不支持扩展段地址和扩展线性地址的,如89C51,这就是此条记录的起始地址>

tt 这个域表示这条HEX记录的类型,他有可能是下面这几种类型

00 ----数据记录

01 ----文件结束记录

02 ----扩展段地址记录

04 ----扩展线性地址记录

dd 是数据域,表示一个字节的数据,一个记录可能有多个数据字节,字节数目可以

查看ll域的说明

cc 是效验和域,表示记录的效验和,计算方法是将本条记录冒号开始的所有字母对

<不包括本效验字和冒号> 所表示的十六进制数字

<一对字母表示一个十六进制数,这样的一个十六进制数为一个字节>

都加起来然后模除256得到的余数最后求出余数的补码即是本效验字节cc.

<例如:

:0300000002005E9D

cc=0x01+NOT((0x03+0x00+0x00+0x00+0x02+0x00+0x5E)%0x100)=0x01+0x9C=0x9D

C语言描述:

UCHAR cc;

cc=(UCHAR)~(0x03+0x00+0x00+0x00+0x02+0x00+0x5E);

cc++;

数据记录

Intel HEX文件由若干个数据记录组成,一个数据记录以一个回车和一个换行结束

<回车为0x0d换行为0x0a>

比如下面的一条数据记录

:10246200464C5549442050524F46494C4500464C33

10 是此行记录数据的字节数目

2462 是数据在内存<将要烧写的eprom地址>中的起始地址

00 是记录类型00(是一个数据记录)

464C 到 464C 是数据

33 是此行记录的效验和

扩展线性地址记录(HEX386)

扩展线性地址记录也可称为 32位地址记录和 HEX386记录,这个纪录包含高16(16-31位)位数据地址,这种扩展的线性记录总是有两个字节数据,像下面这样:

:02000004FFFFFC

02 是记录的数据字节数目

0000 是地址域这在扩展地址记录中总是0000

04 是记录类型04(扩展地址记录)

FFFF 是高16位地址

FC 是记录效验和,计算方法如下:

01h + NOT(02h + 00h + 00h + 04h + FFh + FFh)

当一个扩展线性地址记录被读到后,扩展线性地址记录的数据区域将被保存

并应用到后面从Intel HEX文件中读出的记录,这个扩展线性记录一直有效,

直到读到下一个扩展线性记录.

绝对内存地址 = 数据记录中的地址 + 移位后的扩展线性地址

下面举例说明这个过程

从数据记录的地址域得到地址 2462

从扩展线性地址记录的地址域得到地址 FFFF

绝对内存地址 FFFF2462

扩展段地址记录 (HEX86)

扩展段地址记录也被称为 HEX86记录, 包含 4-19位的数据地址段,

这个扩展段地址记录总是有两字节数据,如下:

:020000021200EA

02 是记录中的数据字节数目

0000 是地址域,在扩展段地址记录中,这个域总是0000

02 是记录类型02(扩展段地址的标示)

1200 是该段的地址

EA 是效验和

计算如下:

01h + NOT(02h + 00h + 00h + 02h + 12h + 00h).

当扩展段地址记录被读后,扩展段地址将被存储并应用到以后从Intel HEX文件读出的记录,这个段地址一直有效直到读到下一个扩展段地址记录

绝对内存地址 = 数据记录中的地址 + 移位后的扩展段地址

数据记录中的地址域移位后扩展段地址记录中的地址域

下面举例说明这个过程

从数据记录的地址域得到地址 2 4 6 2

从扩展段地址记录的地址域得到地址 1 2 0 0

绝对内存地址 0 0 0 1 4 4 6 2

文件结束记录(EOF)

一个Intel HEX文件必须有一个文件结束记录,这个记录的类型域必须是01,

一个EOF记录总是这样:

:00000001FF

00是记录中数据字节的数目

0000这个地址对于EOF记录来说无任何意义

01记录类型是01(文件结束记录标示)

FF是效验和计算如下

01h + NOT(00h + 00h + 00h + 01h).

========================

总结

形如

:BBAAAATTHHHH...HHHHCC

BB: Byte

AAAA:数据记录的开始地址,高位在前,地位在后

因为这个格式只支持8bits,地址被倍乘

所以,为了得到实际的PIC的地址,需要将地址除以2

TT: Type

00 数据记录

01 记录结束

04 扩展地址记录(表示32位地址的前缀,当然这种只能在 INHX32)

HHHH:一个字(Word)的数据记录,高Byte在前,低Byte在后

TT之后,总共有 BB/2 个字的数据

CC: 一个Byte的CheckSum

因为PIC16F873A只有4K的程序空间

所以,不会有 TT=04的 Linear Address Record

而Bin文件是最纯粹的二进制机器代码,没有格式,或者说是"顺序格式"按assembly code顺序翻译成binary machine code.

由于分析出来Hex文件中的数据域ASCII码表示的十六进制与二进制一一对应,而且我公司DSP又是16位的,以一个word为最小单位,

所以四个十六进制ASCII码代表一条机器指令单位或者地址.借于上面分析,编写了工具代码.

大体原理是用fscanf函数在每行的数据域读入四个 ASCII码,以短整形(short int 16bit)形式储存,在把这个短整形变量顺序fwrite到文件流中去即可.

举一例说明：

表1

ORG 0000H

LJMP START

ORG 040H

START：

MOV SP，#5FH ;设堆栈

LOOP：

NOP

LJMP LOOP ；循环

END ；结束

表2

:03000000020040BB

:0700400075815F000200431F

表3　　　　　　　　　

02 00 40 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

FF FF FF FF FF FF FF FF FF FF FF FF 75 81 5F 00 02 00 43

表1为源程序，表2是汇编后得到的HEX文件，表3是由HEX文件转换成的目标文件，也就是最终写入EPROM的文件，它由编程器转换得到，

也可以由 HEXBIN一类的程序转换得到。学过手工汇编者应当不难找出表3与表1的一一对应关系，

值得注意的是从02 00 40后开始的一长串‘FF’，直到75 81，这是由于伪指令：ORG 040H造成的结果。

copy from:http://tieba.baidu.com/f?kz=271526661

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

FILE *fp_read;

FILE *fp_write;

unsigned long start_adr;

unsigned short cur_base;

unsigned short cur_offset;

unsigned char read_buf[16];

unsigned char write_buf[48];

void

calc_start_adr (char *buf)

{

unsigned int len;

len = strlen(buf);

if ((buf[len-1] != 'k') && (buf[len-1] != 'K')) {

printf ("Invalid argument.\n");

exit (-1);

}

buf[len-1] = 0;

start_adr = atoi (buf);

start_adr = start_adr * 1024;

cur_base = start_adr >> 16;

cur_offset = (unsigned short)start_adr;

}

void

start_convert (void)

{

unsigned char cnt;

unsigned char read_num;

unsigned char cksum, highc, lowc;

highc = cur_base >> 8;

lowc = (unsigned char)cur_base;

cksum = 2 + 4 + highc + lowc;

cksum = 0xFF - cksum;

cksum = cksum + 1;

sprintf (write_buf, ":02000004xx", cur_base, cksum);

write_buf[15] = 0x0D; write_buf[16] = 0x0A;

fwrite (write_buf, 1, 17, fp_write);

read_num = fread (read_buf, 1, 16, fp_read);

while (read_num == 16) {

highc = cur_offset >> 8;

lowc = (unsigned char)cur_offset;

cksum = 0x10 + highc + lowc;

for (cnt=0; cnt<16; cnt++) {

cksum += read_buf[cnt];

}

cksum = 0xFF - cksum;

cksum = cksum + 1;

sprintf (write_buf, ":10xx00xxxxxxxxxxxxxxxxx",

highc, lowc,

read_buf[0], read_buf[1], read_buf[2], read_buf[3],

read_buf[4], read_buf[5], read_buf[6], read_buf[7],

read_buf[8], read_buf[9], read_buf[10], read_buf[11],

read_buf[12], read_buf[13], read_buf[14], read_buf[15],

cksum);

write_buf[43] = 0x0D; write_buf[44] = 0x0A;

fwrite (write_buf, 1, 45, fp_write);

if (cur_offset == 65520) {

cur_offset = 0;

cur_base ++;

highc = cur_base >> 8;

lowc = (unsigned char)cur_base;

cksum = 2 + 4 + highc + lowc;

cksum = 0xFF - cksum;

cksum = cksum + 1;

sprintf (write_buf, ":02000004xx", cur_base, cksum);

write_buf[15] = 0x0D; write_buf[16] = 0x0A;

fwrite (write_buf, 1, 17, fp_write);

} else {

cur_offset += 16;

}

read_num = fread (read_buf,1,16,fp_read);

}

if (read_num) {

highc = cur_offset >> 8;

lowc = (unsigned char)cur_offset;

cksum = read_num + highc + lowc;

for (cnt=0; cnt<read_num; cnt++) {

cksum += read_buf[cnt];

}

cksum = 0xFF - cksum;

cksum = cksum + 1;

sprintf (write_buf, ":xxx00", read_num, highc, lowc);

for (cnt=0; cnt<read_num; cnt++) {

sprintf (&write_buf[9 + cnt * 2], "x", read_buf[cnt]);

}

sprintf (&write_buf[9 + cnt * 2], "x", cksum);

write_buf[11 + read_num * 2] = 0x0D;

write_buf[12 + read_num * 2] = 0x0A;

fwrite (write_buf, 1, 13 + read_num * 2, fp_write);

}

sprintf (write_buf, ":00000001FF");

write_buf[11] = 0x0D; write_buf[12] = 0x0A;

fwrite (write_buf, 1, 13, fp_write);

}

int

main (int argc, char *argv[])

{

if (argc != 4) {

printf ("Usage : %s -b address filename.xxx\n", argv[0]);

printf ("-b : indicate the starting address convert to.\n");

printf ("address : starting address.\n");

printf ("filename.xxx : file to be converted.\n");

printf ("output : filename.hex\n");

printf ("example : %s -b 64k rom.bin\n", argv[0]);

return -1;

}

if (strcmp (argv[1], "-b")) {

printf ("Invalid argument.\n");

return -1;

};

fp_read = fopen (argv[3], "rb");

if (fp_read == NULL) {

printf ("Can't open file %s", argv[3]);

return -1;

}

fp_write = fopen ("rom.hex", "w");

if (fp_write == NULL) {

printf ("Can't create file rom.hex");

return -1;

}

calc_start_adr (argv[2]);

start_convert ();

fclose (fp_read);

fclose (fp_write);

printf("Convert Seccessfully!\n");

return 0;

}

简单介绍一下这2种文件格式的区别：

1 － HEX文件是包括地址信息的，而BIN文件格式只包括了数据本身

在烧写或下载HEX文件的时候，一般都不需要用户指定地址，因为HEX文件内部的信息已经包括了地址。而烧写BIN

文件的时候，用户是一定需要指定地址信息的。

3 － BIN文件格式

对二进制文件而言，其实没有”格式”。文件只是包括了纯粹的二进制数据。

4 － HEX文件格式

HEX文件都是由记录（RECORD）组成的。在HEX文件里面，每一行代表一个记录。记录的基本格式为：

+---------------------------------------------------------------+

+---------------------------------------------------------------+

+---------------------------------------------------------------+

记录类型包括：

'00' Data Rrecord：用来记录数据，HEX文件的大部分记录都是数据记录

'01' End of File Record: 用来标识文件结束，放在文件的最后，标识HEX文件的结尾

'04' Extended Linear Address Record: 用来标识扩展线性地址的记录

'02' Extended Segment Address Record: 用来标识扩展段地址的记录

在上面的后2种记录，都是用来提供地址信息的。每次碰到这2个记录的时候，都可以根据记录计算出一个“基”地址。

对于后面的数据记录，计算地址的时候，都是以这些“基”地址为基础的。

数据记录的具体格式：

+---------------------------------------------------------------+

+---------------------------------------------------------------+

+---------------------------------------------------------------+

看个例子：

:020000040000FA

:10000400FF00A0E314209FE5001092E5011092E5A3

:00000001FF

对上面的HEX文件进行分析：

第1条记录的长度为02，LOAD OFFSET为0000，RECTYPE为04，说明该记录为扩展段地址记录。数据为0000，校验和为

FA。从这个记录的长度和数据，我们可以计算出一个基地址，这个地址为0X0000。后面的数据记录都以这个地址为基

地址。

第2条记录的长度为10（16），LOAD OFFSET为0004，RECTYPE为00，说明该记录为数据记录。

数据为FF00A0E314209FE5001092E5011092E5，共16个BYTE。这个记录的校验和为A3。此时的基地址为0X0000，加上OFFSET，

这个记录里的16BYTE的数据的起始地址就是0x0000 + 0x0004 = 0x0004.

第3条记录的长度为00，LOAD OFFSET为0000，TYPE ＝ 01，校验和为FF。说明这个是一个END OF FILE RECORD，标识

文件的结尾。

在上面这个例子里，实际的数据只有16个BYTE：FF00A0E314209FE5001092E5011092E5，其起始地址为0x4

4 － HEX文件和BIN文件大小有区别

HEX文件是用ASCII来表示二进制的数值。例如一般8-BIT的二进制数值0x3F，用ASCII来表示就需要分别表示字符'3'

和字符'F'，每个字符需要一个BYTE，所以HEX文件需要 > 2倍的空间。

对一个BIN文件而言，你查看文件的大小就可以知道文件包括的数据的实际大小。而对HEX文件而言，你看到的文件

大小并不是实际的数据的大小。一是因为HEX文件是用ASCII来表示数据，二是因为HEX文件本身还包括别的附加信息。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/studyvcmfc/archive/2009/05/30/4225282.aspx

HEX BIN文件分析介绍相关推荐

bin文件分析发现的问题（1）
1.有一个bin文件test_053102.bin,大小为561.4KB,如图: 2.hexdump这个文件,看下内容文件大小为0x0089120,本来自己计算的0x89120 = 561440,按 ...
Linux学习笔记---烧写bin文件分析
在看正点原子 I.MX6U 嵌入式 x Linux 驱动开发指南时,在第九章分析了启动文件的组成,但是通过文档中介绍的HEX文件查看器查看 load.imx文件时感觉不是很方便,于是就在Notepad ...
J-Flash的Hex/Bin文件的烧录
一.安装JLink 二.打开软件J-Flash 三.软件设置 1.设置软件工程(3种方法) 2.文件烧录一.安装JLink 官网下载地址二.打开软件J-Flash 三.软件设置 1.设置软件工程( ...
KEIL的hex与bin文件自动生成到指定目录
由于每次生成查找HEX BIN文件不方便,借鉴网上的文章拼出了下面的BAT文件,分享一下使用方法见注释 :: @File Name: HEXBIN.bat :: @Version : 1.0 :: ...
STM32的烧录和Hex/bin烧录文件解析
一.STM32的烧录 1. 用IDE工具烧录可以配置IAR或Keil,用IDE下载.硬件工具需要使用ST-Link(分为SWD或Jtag方式,SWD连线少,比较常用于调试)或J-Link连接到板子的 ...
.s19 文件转换为 .hex 和 .bin文件的方法
使用STVD开发时,编译后产生的是 .s19 文件,与Keil 和 IAR常见的.hex .bin文件不同,那么如何将.s19文件转换为常见的文件格式呢? 一.获取工具 burner ...
Keil5-MDK 使用编译步骤及异常与修改（生成axf文件和bin文件）
其实我是比较触头硬件编程这个事情的,因为我没学汇编计组还挂了,重修也没学明白,因为课时间重了办的免听,最后还是靠我的学弟们,贡献了他们老师给画的重点.结果毕业后找工作,就c++熟一些,急乎乎的找了c+ ...
（转载）bin文件格式分析
xip 的 bin 文件分析一个bin 文件在存储上是按下面的结构存储的组成:标记(7)+Image开始地址(1)+Image长度(1) 记录0地址+记录0长+记录0校验和+ ...
HEX文件和BIN文件总结及hex文件流转bin文件流示例代码
这几天在写STM32的ISP烧录工具,因此有涉及到输入hex文件或bin文件进行烧录的问题,所以对hex文件和bin文件进行了些总结. 1 hex介绍 Hex 全称 (Intel HEX)文件是由一行 ...
hex文件和bin文件区别
HEX文件和BIN文件是我们经常碰到的2种文件格式.因为自己也是新手,所以一直对这两个文件懵懵懂懂,不甚了解,最近在做STM32单片机的IAP更新,其中要考虑HEX文件和BIN文件,所以需要学习下这两 ...

HEX BIN文件分析介绍

HEX BIN文件分析介绍相关推荐

最新文章

热门文章

HEX BIN文件 分析介绍

HEX BIN文件 分析介绍相关推荐

最新文章

热门文章

HEX BIN文件分析介绍

HEX BIN文件分析介绍相关推荐