UDS 진단 통신으로 하는 소프트웨어 업데이트 4 - 소프트웨어 전송 (계속)

소프트웨어 전송 (계속)

• 아래 그림의 빨간 테두리 부분에 관한 설명이다.

0x34(RequestDownload), 0x36(TransferData), 0x37(RequestTransferExit) 부분을 설명한다.

 

• 이와 관련한 설정은 Request and Transmit Data 탭에서 한다. 설정 화면은 아래 그림과 같다.
• 설정 항목들은 DataFormat Identifier of Request Transmit Data(0x), Enable User Define MaxNumOfBlockLength(0x), Delay Time after Transfer Request, Delay Time after Transfer Data이다.

SW (데이터) 전송을 설정하는 화면

 

 

Data Format Identifier

• Data Format Identifier of "Request Transmit"을 설명하려면 먼저 "Request Transmit" 서비스의 포맷을 설명해야 한다. 포맷은 아래와 같다.

SID	DFI	ALFI	Memory Type	Address Byte-1	Address Byte-2	Address Byte-3	Address Byte-4	Memory Size Byte-1	Memory Size Byte-2	Memory Size Byte-3	Memory Size Byte-4
34	10	45	01	40	00	00	00	00	00	08	00
B1	B2	B3	B4	B5	B6	B7	B8	B9	B10	B11	B12

 

• 서비스 아이디는 0x34이다. B1 자리이다.
• B2 자리가 Data Format Identifier이다. 하위 니블(아래 4 bit)은 암호화 여부를 표시한다. 상위 니블은 압축 여부를 표시한다. 암호화 방법과 압축 방법은 OEM이 정한다. 예를 들면, 아래의 의미이다. 1이 아닌 값들로 암호화 방법이나 압축 방법을 지정할 수 있을 것이다. 

0x00: 비압축, 비암호화
0x01: 비압축, 암호화
0x11: 압축, 암호화

• B3 자리는  Address Length & Format Identifier (ALFI)이다.
  • 하위 니블은 메모리 주소의 길이이다.
  • 메모리 주소의 길이는 프로세서가 8 비트인 경우 1 바이트, 16 비트인 경우 2 바이트, 32 비트인 경우 4 바이트, 64 비트인 경우 8 바이트의 관계를 갖고 있다.
  • 예제에서는 이 값이 5이다. 40 bit 프로세서??
  • 제어기는 주로 마이크로콘트롤러를 갖고 있고, 마이크로콘트롤러는 저장 용도로 내부 플래시 메모리를 갖고 있다. 내부 플래시 메모리로 부족한 경우 외부 저장 메모리를 갖는다. 내부 메모리와 외부 메모리에 동일 주소가 있을 수 있다. 주소를 지정할 때, 내부 메모리와 외부 메모리를 구분해야 한다. 메모리 주소 길이가 홀수인 경우 내부 메모리를 의미한다. 홀수는 5 - 1 = 4와 같이 메모리 주소 길이를 구한다. 예제의 메모리 주소 길이는 4 바이트이다. 32 비트 프로세서인 것을 유추할 수 있다.    
  • 상위 니블의 4는 데이터 크기를 4 바이트로 표시한다는 의미이다. 
• B4 자리는 Memory Type이다. 외부 메모리도 여러 개나 여러 종류(플래시, EEPROM, SD Card 등)가 있을 수 있다. 어떤 값이 어떤 메모리를 가리키는 지는 OEM이 정한다. 대부부 OEM은 0x01을 내부 메모리로 한다. 외부 메모리가 없는 경우 Memory Type은 필요없다.
• B5-B8 (0x40000000)는 다운로드한 데이터를 기록할 시작 주소이다.
• B9-B12 (0x00000800): 다운로드할 데이터의 크기이다. 0x800 = 2,048 바이트이다. 

 

Enable User Define MaxNumOfBlockLength

• 실험을 해보지 않았다.  
• 다운로드할 소프트웨어는 블록으로 나눠져있다. 한 블록의 최대 길이를 이야기하는 것인가? 

소프트웨어(저장용 메모리 영역)는 블록들로 구분되어 있다.

• 데이터 전송은 0x36 TransferData 서비스를 반복해서 이뤄진다. 한 번의 0x36 서비스로 전달하는 데이터 단위를 블록이라고 한다면 (Transport Protocol에 Blcok Size라고 하니까), 이 블록 크기의 최대값을 설정하는 것일 수 있다. 기본값이 0x202인 것을 보면 이럴 가능성이 높다고 생각한다. 0x202는 514이다. 514는 소프트웨어의 블록의 최대값으로는 너무 작은 값이라고 생각한다.  

 

 

Delay Time after Transfer Request

• 역시 실험해보지 않았다. 다음과 같이 추측한다. 다운로드는 0x34 RequestDownload 서비스 요청 후, 0x36 TransferData를 반복하는 방식으로 이뤄진다. 0x34 서비스 요청 후 얼마나 지난 후에 0x36 서비스를 요청을 할 것인지를 설정하는데 사용하는 것 같다. 

 

Delay Time after Transfer Data

• 역시 실험해보지 않았다. 다음과 같이 추측한다. 0x36 TransferData를 반복할 때, 지난 서비스 요청과 이번 서비스 요청 사이에 얼마나 지연 시간을 줄 것인지를 설정하는데 사용하는 것 같다. 

 

 

전송 트레이스 분석

• 전송 트레이스의 첫 부분은 아래와 같다.  

Block0 전송 과정 첫 부분

 

• 첫줄 메시지는 진단기가 0x34 RequestDownload 서비스를 요청하는 것이다.  
  • 0x10: 한 메시지에 요청을 모두 실을 수 없다. 멀티 프레임 메시지의 First Frame을 표시한다. 
  • 0x0B: 데이터는 11 바이트이다. 10 0B 34 00 44 00 00 00 83 00 00 64 E4
  • 0x34: RequestDownload의 서비스 아이디
  • 0x00: 비압축, 비암호화
  • 0x44: 어드레스를 4 바이트로 표시한다. 짝수=내부 플래시 메모리. 데이터 크기를 4 바이트로 표시한다.
  • 0x 00 00 00 83: 데이터 기록을 시작할 주소이다. 83은 세 번째 메시지 (Consecutive Frame)에서 왔다.
  • 0x 00 00 64 E4:  25,828 바이트. Block0의 크기이다. 세 번째 메시지 (Consecutive Frame)에서 왔다.

데이터 크기 0ㅌ64 E4는 25,828 바이트이다.

• 둘째 줄 메시지는 제어기가 진단기의 First Frame에 대응하여 보낸 Flow Control 메시지이다. 
• 세째 줄 메시지는 위에서 설명하였다. 진단기가 제어기로 보내는 멀티 프레임 메시지의 두 번째 메시지이다. 
• 네번 째 줄의 메시지는 0x34 RequstDownload 요청에 대한 긍정 응답 (0x74 = 0x34 + 0x40)이다.
• 다섯번 째 줄의 메시지는 0x36 DataTransfer 요청이다.
  • 0x10: 한 메시지에 요청을 모두 실을 수 없다. 멀티 프레임 메시지의 First Frame을 표시한다. 
  • 0x82: 데이터는 130 바이트이다. 녹색 테두리에 들어있는 데이터 바이트들이다. 
  • 0x36: TransferData의 서비스 아이디
  • 0x01 02 01 ... 98 E0 F8 AA AA: 데이터. AA는 공란을 채우는 패딩 바이트이다. 
• 여섯번 째 줄 메시지는 제어기가 진단기의 First Frame에 대응하여 보낸 Flow Control 메시지이다.   
• 일곱번 째 줄 이하 0x2n으로 시작하는 메시지들은 데이터를 실은 Consecutive Frame들이다. n은 일련 번호이다. 빠진 메시지가 없는 지 확인하는데 사용된다.
• 0x02 76 01 줄은
  • 0x02: Single Frame으로 길이가 2 바이트이다.
  • 0x76: 0x34 TransferData에 대한 긍정 응답이다.
  • 0x01: 뭔가 미리 정한 파라미터의 값이다. 
• 그 이하로 Block0의 25,828 바이트 데이터가 전송 완료될 때까지 TransferData가 반복된다.
• Block0의 데이터가 모두 전송되면 RequestTransferExit 요청을 한다. 

Block0 데이터 전송 과정 끝 부분. Blcok1 데이터 전송 과정 첫 부분

 

 

소프트웨어 전송 종료 (Transmit Exit)

• 소프트웨어 전송 종료를 위한 Transmit Exit의 설정은 아래 그림과 같다. 

 

• 서비스 아이디는 0x37이다. UDS의 명칭은 RequestTransferExit이다. 
• 요청에는 Checksum 검증 방법에 따라 아래의 타입들이 있다.
  • Checksum 검증을 하지 않음
  • 진단기가 요청에 Checksum을 포함하고, 제어기가 확인함
  • 제어기가 응답에 Checksum을 포함하고, 진단기가 확인함
  • 기타

 

 

• 예제에서는 진단기가 Checksum을 전달한다.

Block0의 Checksum을 RequestTransferExit (0x37) 요청에 담아 진단기가 제어기로 전송한다.

 

Block0의 Checksum

 

 

블록별 다운로드 반복

• 위에 설명한 절차대로 Block0 데이터 전송이 완료되면, Block1 데이터를 대상으로 0x34(RequestDownload), 0x36(TransferData), 0x37(RequestTransferExit) 절차가 수행된다. 그 후에는 Block2, Block3 데이터를 대상으로 동일한 절차가 반복 수행된다. Block이 n개라며 n번 반복되었을 것이다.

 

파일 다운로드 실행 

• 위와 같이 정의한 0x343637 Download File 서비스를 실행하는 장면은 아래 비디오와 같다.
• Diagnostic Console 탭으로 이동하여 실행한다. 

  tsmaster basic console download file - YouTube

 

 

 

다음 블로그에서 다음 절차들을 계속 설명한다. UDS 진단 통신으로 하는 소프트웨어 업데이트 5 - 메타 데이터 업데이트 :: hsl's tsmaster 사용기

 

 

목차 :: hsl's tsmaster 사용기