푼수의 임베디드

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

 

megaboot 입니다. AVR의 Bootloader 라 보시면 됩니다.

예전 프로젝트시 원격 업그레이드 기능이 필요하여 외주 처리를 하였는데 한 300 정도
든 것 같았습니다.
인터넷 서핑 을 하다 발견하여 열어보니 프로토콜 처리 부분 빼고 동일하더군요 ㅡㅡ;;;
저와같은 실수를 하지 마세요ㅜㅜ

//===========================================================================
// CRC 체크 표준
//===========================================================================
// KS초안_KSCIEC62056-61 에 정의된 표준 CRC 16 계산 테이블 입니다.
// 유용하게 사용하세요.

//---------------------------------------------------------------------------
// 계산식
#define SCrcCal(data) SCRC = ( (SCRC>>8) ^ Crc16Tbl[ (SCRC^data) & 0xFF ] )
U16 SCRC = 0xFFFF;

//---------------------------------------------------------------------------
// 표준 CRC 테이블
U16 Crc16Tbl[256] = {
    0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241, 0xC601, 0x06C0, 0x0780,
    0xC741, 0x0500, 0xC5C1, 0xC481, 0x0440, 0xCC01, 0x0CC0, 0x0D80, 0xCD41, 0x0F00, 0xCFC1,
    0xCE81, 0x0E40, 0x0A00, 0xCAC1, 0xCB81, 0x0B40, 0xC901, 0x09C0, 0x0880, 0xC841, 0xD801,
    0x18C0, 0x1980, 0xD941, 0x1B00, 0xDBC1, 0xDA81, 0x1A40, 0x1E00, 0xDEC1, 0xDF81, 0x1F40,
    0xDD01, 0x1DC0, 0x1C80, 0xDC41, 0x1400, 0xD4C1, 0xD581, 0x1540, 0xD701, 0x17C0, 0x1680,
    0xD641, 0xD201, 0x12C0, 0x1380, 0xD341, 0x1100, 0xD1C1, 0xD081, 0x1040, 0xF001, 0x30C0,
    0x3180, 0xF141, 0x3300, 0xF3C1, 0xF281, 0x3240, 0x3600, 0xF6C1, 0xF781, 0x3740, 0xF501,
    0x35C0, 0x3480, 0xF441, 0x3C00, 0xFCC1, 0xFD81, 0x3D40, 0xFF01, 0x3FC0, 0x3E80, 0xFE41,
    0xFA01, 0x3AC0, 0x3B80, 0xFB41, 0x3900, 0xF9C1, 0xF881, 0x3840, 0x2800, 0xE8C1, 0xE981,
    0x2940, 0xEB01, 0x2BC0, 0x2A80, 0xEA41, 0xEE01, 0x2EC0, 0x2F80, 0xEF41, 0x2D00, 0xEDC1,
    0xEC81, 0x2C40, 0xE401, 0x24C0, 0x2580, 0xE541, 0x2700, 0xE7C1, 0xE681, 0x2640, 0x2200,
    0xE2C1, 0xE381, 0x2340, 0xE101, 0x21C0, 0x2080, 0xE041, 0xA001, 0x60C0, 0x6180, 0xA141,
    0x6300, 0xA3C1, 0xA281, 0x6240, 0x6600, 0xA6C1, 0xA781, 0x6740, 0xA501, 0x65C0, 0x6480,
    0xA441, 0x6C00, 0xACC1, 0xAD81, 0x6D40, 0xAF01, 0x6FC0, 0x6E80, 0xAE41, 0xAA01, 0x6AC0,
    0x6B80, 0xAB41, 0x6900, 0xA9C1, 0xA881, 0x6840, 0x7800, 0xB8C1, 0xB981, 0x7940, 0xBB01,
    0x7BC0, 0x7A80, 0xBA41, 0xBE01, 0x7EC0, 0x7F80, 0xBF41, 0x7D00, 0xBDC1, 0xBC81, 0x7C40,
    0xB401, 0x74C0, 0x7580, 0xB541, 0x7700, 0xB7C1, 0xB681, 0x7640, 0x7200, 0xB2C1, 0xB381,
    0x7340, 0xB101, 0x71C0, 0x7080, 0xB041, 0x5000, 0x90C1, 0x9181, 0x5140, 0x9301, 0x53C0,
    0x5280, 0x9241, 0x9601, 0x56C0, 0x5780, 0x9741, 0x5500, 0x95C1, 0x9481, 0x5440, 0x9C01,
    0x5CC0, 0x5D80, 0x9D41, 0x5F00, 0x9FC1, 0x9E81, 0x5E40, 0x5A00, 0x9AC1, 0x9B81, 0x5B40,
    0x9901, 0x59C0, 0x5880, 0x9841, 0x8801, 0x48C0, 0x4980, 0x8941, 0x4B00, 0x8BC1, 0x8A81,
    0x4A40, 0x4E00, 0x8EC1, 0x8F81, 0x4F40, 0x8D01, 0x4DC0, 0x4C80, 0x8C41, 0x4400, 0x84C1,
    0x8581, 0x4540, 0x8701, 0x47C0, 0x4680, 0x8641, 0x8201, 0x42C0, 0x4380, 0x8341, 0x4100,
    0x81C1, 0x8081, 0x4040
};

/*
 SCRC = 0xFFFF;
 SCrcCal(0x30);
 SCrcCal(0x31);
 SCrcCal(0x32);
 SCrcCal(0x33);
 SCrcCal(0x34);
 printf("SCRC = 0x%02X%02X\n",(unsigned char)(SCRC>>8),(unsigned char)SCRC); // "SCRC = 0x10DE"
 SCrcCal(0xDE);
 SCrcCal(0x10);
 printf("SCRC = 0x%02X%02X\n",(unsigned char)(SCRC>>8),(unsigned char)SCRC); // "SCRC = 0x0000"
*/

AVR 타이머 / UART 레지스트리 세팅의 계산을 편하게 해주는 툴 입니다.

AVR이나 ARM을 이용한 제품 개발시 디버깅을 할 수 있는 방법이 있느냐 없느냐는 매우 큰 차이를 가지게 됩니다.
(전 ARM쪽은 프로젝트를 그리 많이 해보지 않았기에 아직 기초적인 단계에 머물러 있습니다.
대충 이런이런 방법으로 개발하면 되겠구나 하는 것은 알겠지만 실제 구현에 있어서는 막막합니다.)

ARM은 ARM전용 디버깅 장비인 Multi ice 나 RealView ICE를 이용하여 디버깅을 합니다.
하지만 여타 8Bit Mcu의 디버깅 툴에 비해 매우 고가에 거래가 됩니다.
실 예로 avr jtag ice 구입시 약 55만원에 구입을 하였습니다. arm jtag ice 구입시에는 근 400만원이 넘는 돈을 주고 구입을 하였습니다. 이처럼 전용 디버깅 장비를 개인이 구매하기엔 매우 큰 돈을 사용하게 됩니다. 물론 많은 기능이 지원되고 다양한 플랫폼이 지원되기는 하지만 개인이 사용하기엔 큰 부담이 될 수 밖에 없는 것 같습니다.
그래서 전 다른 방법을 사용하여 개발시 디버깅에 사용을 합니다.
여기서는 AVR을 중점적으로 디버깅 하는 방법을 기술하고자 합니다.

1. 오실로 스코프를 이용한 펌웨어 디버깅
  가장 단순하면서도 그리 많은 디버깅이 필요치 않을 경우 사용하는 방법 입니다.
mcu를 사용하다보면 남는 포트가 몇몇개 있을 것 입니다. 전 그 포트에 TP를 뽑아 오실로스코프와 연결 한 후 펌웨어 작업시 알맞은 루틴에 정확히 로직대로 입력이 되는지 혹은 정확한 타이밍에 정확한 데이터가 출력이 되는지를 포트의 High / Low 를 이용하여 확인 합니다. 별다른 하드웨어 수정 없이도 가능한 방법이기에 간단한 디버깅용으로 사용하기엔 알맞춤입니다.

2. JTAG를 이용한 펌웨어 디버깅
 가장 이상적인 방법입니다만 문제는 돈이 든다는 것 입니다. 중국산의 저가 장비나 국내 업체의 저가 JTAG가 있긴 합니다. 하지만 atmel 사의 디버깅 장비에 비해 많은 chip을 지원하지는 않습니다.
국내 연구소 및 교육시설의 경우 atmel사의 디버깅 툴을 추천 하며 개인의 경우 많이 사용하는 mcu를 지원하는 저가 툴을 사용하는 것을 추천 합니다.
 디버깅 장비를 이용시 각 각 펌웨어의 포인트에 브레이크 포인트를 잡아 어느 변수에 무슨 값이 들어가는지 레지스터가 제대로 세팅 되었는지 확인이 가능합니다. 하지만 이러한 jtag를 이용한 디버깅에도 한가지 큰 단점이 있습니다. atmega 시리즈의 디버깅 툴 이용 방법은 두가지를 제공합니다. 적은 핀 수를 가진 칩을 위한 디버그 와이어 모드와 jtag 모드 입니다. 이 두가지 방법 모두 퓨즈 비트를 세팅시 프린터포트를 이용한 하이볼테이지 프로그래밍을 이용하지 않는 이상 다시는 isp를 이용하여 펌웨어를 다운로드 시키지 못합니다.

3.  UART / RS232를 이용한 펌웨어 디버깅
  제가 가장 추천하는 방법 중의 하나 입니다. 전 제품의 하드웨어 설계시 남는 uart 포트를 이용하여 max232 칩의 pad를 하나 만들어 둡니다. 제품의 샘플 단계에서는 232칩을 이용하여 pc와 통신하며 rprintf 기능을 이용하여 디버깅에 사용합니다. 제가 보고자 싶은 함수의 리턴 값이나 변수값을 uart 포트를 이용하여 pc와 통신하여 확인하며 사용합니다. 사용법도 간단하며 많은 돈을 들이지 않고도 쉽게 디버깅을 할 수 있어 매우 유용합니다. 제품 양산시에는 232 관련 부분은 pad만 남겨두고 부품은 실장하지 않아 제품의 mc에도 영향이 매우 미비합니다. 다음번 글은 uart / 232를 이용하여 디버깅을 하는법을 써보고자 합니다.^^