Intel Hex 파일의 이해

PC에서 타겟으로 firmware 파일 등을 전송 시 시리얼 포트를 통하여 전송할 경우, 이들 파일은 대부분 바이너리 형식을 취하기 때문에, 시리얼통신의 제어문자와 바이너리 테이터와의 구별이 불가능 합니다. 따라서 제어 문자 와 구별이 가능 하면서도 바이너리코드를 전송할 수 있는 방법이 hex 파일 포맷 입니다. hex 파일의 포맷은 다양한 방식이 존재 합니다. 인텔, 모토롤라, S레코드 등 메이져 칩벤더의 고유의 방식이 있습니다.

hex 파일의 포맷은 바이너리 데이터와 제어문자의 충돌을 피하기 위해 바이너리 데이터의 코드값을 바이트 단위의 아스키문자로 변환하여 이를 텍스트화 시킨 것 이다.

 

MARK	Length	OffSet	Type	Data	CheckSum
:	1바이트	2바이트	1바이트	0~255바이트	1바이트

① MARK

HEX파일의 모든 레코드는 ":" 문자(아스키코드 "3A")로 시작해야 한다. 이를 레코드 마크(MARK)라고 한다.

② Length

각 레코드에 포함된 바이너리 데이터의 길이이다. Length 필드의 크기가 1바이트이므로 Data 필드는 0~255바이트의 문자를 지녀야 한다. 예컨데, 레코드의 Data가 10개이면 10 = 0x0A 이므로 Length 필드에는 "0A"의 텍스트파일 형식으로 기입된다. 따라서, 실재 Length필드는 ASCII문자 2바이트를 필요로 한다. 이하, Offset, Type, Data, CheckSum 모두 마찬가지이므로 주의하도록 하자.

 ③ Offset

바이너리파일의 처음위치로부터 해당 레코드의 데이터가 위치하는 상대적 위치를 말한다. Offset은 2바이트(=16비트)의 값을 가지므로 8, 16비트 CPU의 경우 어떠한 어드레스라도 OffSet 필드를 이용해서 직접 어드레싱이 가능하다. 그러나, 20, 32비트 CPU의 경우엔 16비트의 OffSet만으로는 직접 어드레싱이 불가능하므로 간접 어드레싱해야 하는데, 이를 구별하기 위해 필요한 필드가 Type필드이다.

 ④ Type

레코드타입을 뜻함. 00의 경우 데이터 어드레스, 01의 경우 HEX파일이 종료됨을 뜻하는 레코드를 의미한다. 8, 16비트 CPU의 HEX 파일은 이 두가지 경우만 필요하지만, 20, 32비트 CPU에서는 추가적인 레코드를 필요로 한다. 이들 추가 레코드 타입에 대해서는 첨부된 자료를 참고하도록 하자.

 ⑤ Data

바이너리 데이터이다. 하나의 레코드 안에 포함될 수 있는 데이터의 개수는 0 ~255개까지이다. 그보다 데이터 수가 많을 경우에는 적당한 개수만큼 분할하여 레코드를 생성해야 한다.

 ⑥ CheckSum

HEX파일로 수신한 디바이스에서 올바른 바이너리 파일 변환을 위해 각 레코드가 오류없이 수신되었는지 체크하는 필드이다. CheckSum을 구하는 방법은 ② ~ ⑤의 필드를 바이트 단위로 쪼개어 모두 더한 다음 2의 보수(2's Complement)를 취하면 된다. 그 값이 1바이트를 넘을 경우 상위바이트의 값은 버리고 최하위 1바이트 부분만을 취한다.

 이제 바이너리 파일이 어떻게 HEX 파일로 변환되는지 실습해 보도록 하자.

 먼저, 바이너리 파일의 일부분을 열어봤다.

02 01 55 78 7F E4 F6 D8 FD 75 81 16 02 00 84 8F 0C 8E 0B 8D 0A 8C 09 ...

 

이를 HEX 파일로 변환하면 다음과 같다.

 

:03000000020155A5 :0C015500787FE4F6D8FD75811602008466 :0800C2008F0C8E0B8D0A8C09D6