-
UDS 진단 통신으로 하는 소프트웨어 업데이트 3 - 소프트웨어 전송diagnostic 2025. 2. 27. 13:04
소프트웨어 전송
- 소트웨어 전송 과정은 아래 그림과 같다.
소프트웨어 전송 과정 - 소프트웨어가 프로그램될 영역 삭제, 다운로드 요청, 프로그램할 소프트웨어 전송 (데이터 전송), 전송 종료, 소프트웨어 번호 (기타 메타 데이터) 쓰기이다.
- 영역 삭제와 메타 데이터 쓰기는 자동차사, 협력사 특화된 루틴(기능)이다. UDS에는 RoutineControl 이라는 이름으로 서비스 아이디 0x31이 정의되어 있다. 나는 영역 삭제와 메타 데이터 쓰기를 위한 루틴이 정의되어 있다고 가정하고 설명한다.
- 다운로드 요청 (서비스 아이디 0x34), 데이터 전송 (서비스 아이디 0x36), 전송 종료 (서비스 아이디 0x37)는 각각의 서비스로 분리되어 있지만 실제로는 합쳐져 실행된다. 그래서 TSMaster에는 Combined Services 라는 기능이 마련되어 있다. Diagnostic 창/ Basic Diagnostic Config 탭/ 서비스 트리/ Combined Services에 $343637 DownloadFile 서비스가 그것이다. Combined Serivces 아래에 새 서비스를 추가할 수는 없다. $343637 DownloadFile 아래에 새 서비스를 추가하는 것은 가능하다. 아래 그림에도 두 개의 서비스가 정해져 있다.
0x34, 0x36, 0x37은 소프트웨어 다운로드 관련 서비스들이고 이들은 합쳐져 실행된다. $343637 DownloadFile 아래 서비스를 정의할 수 있다. - 343637 DownloadFile (이하 파일 다운로드 서비스)의 설정을 하나씩 설명한다.
파일 다운로드 서비스 추가
- 343637 DownloadFile을 마우스 우클릭하여 Add New Service를 한다.
- 아래 그림과 같이 빈 파일 다운로드 서비스가 추가된다.
General Config
- "+" 버튼으로 파일 선택 창을 열고 다운로드할 파일을 선택한다. (1)
- 파일을 선택하면 소프트웨어 블록 정보가 자동으로 등록된다. (2)
- Service Name을 정한다. 나는 소프트웨어 파일 이름과 동일하게 했다. (3)
- 창 아래쪽에 "Loading a file to different services is prohibited"라는 빨간색 글씨의 경고가 나온다. 한 파일로 한 서비스만 만들 수 있다는 의미이다. 즉, 새 파일이면 새 서비스를 만들어야 한다. (이렇게 하면 잘못된 파일을 다운로드하는 실수를 줄일 수 있어 좋다고 생각한다.)
다운로드할 파일을 선택하면 블록 정보가 자동으로 채워진다. - "+" 버튼 오른쪽에 아래로 향한 삼각형 버튼을 누르면 소프트웨어의 내용을 Hex 코드로 볼 수 있다. 위쪽에 Block을 선택하면 해당 블록만 볼 수 있다.
소프트웨어를 Hex로 볼 수 있다. 블록을 선택하면 해당 블록의 내용만 볼 수 있다. 블록 영역에서 마우스 우클릭하면 추가 메뉴들을 실행할 수 있다. (나는 실험하지 않았다.) - 메모리 주소와 메모리 크기를 몇 바이트로 표시할 것인지 설정한다. 바이트 순서가 Motorola인지 Intel인지 설정한다. Checksum 계산에 어떤 알고리즘을 적용할 지 설정한다. 제어기의 하드웨어 사양과 소프트웨어 사양에 따라 설정한다.
여러 CRC 알고리즘들이 지원된다. - 실험을 해보니 bin 파일과 hex 파일을 지원한다. elf 파일은 지원되지 않는(것 같)다.
Erase Flash
- Erase Flash의 설정 화면은 아래 그림과 같다. Erase Flash의 서비스 아이디가 0x31인 것을 볼 수 있다. 서비스 아이디 0x31은 RoutineControl의 서비스 아이디이다. RoutineControl을 먼저 설명한다.
Erase Flash 설정 화면. 서비스 아이디가 0x31 RoutineControl의 서비스 아이디이다. RoutineControl
- 진단 통신으로 루틴하게 실행되는 서비스가 있다. 플래시 메모리 삭제, 브레이크 액 주입을 위한 밸브와 모터 제어, 메타 데이터 쓰기 등이다. 이런 서비스는 더 잘게 정의된 서비스들을 연결하여 구현할 수 있다. 그렇게 하기 귀찮고, 실수가 있을 수 있다. 작은 서비스들을 묶어 루틴으로 정의하여, 요청 하나로 전체 서비스들이 수행되도록 하는 것이 RoutineControl이다. 루틴 제어라고 부르겠다.
- 루틴 제어의 화면은 아래와 같다. Diagnostic 창/ Basic Diagnostic Config 탭/ 서비스 트리/ RemoteControl 서비스를 마우스 우클릭하여 Add New Service 메뉴로 서비스를 추가할 수 있다.
RoutineControl 서비스 설정 화면 - ErashFlash 서비스 요청은 31 01 FF 00 ss xx xx xx xx yy yy yy yy 이다. (설명을 위해 일부 xx를 ss난 yy로 변경하였다.) 이것은 예이다. 모든 EraseFlash 서버스 요청이 정확하게 이 형식으로 되어있지 않다는 의미이다. 아래에서 추가 설명한다.
- 0x31은 루틴 제어의 서비스 아이디이다.
- 0x01은 루틴 제어 서비스의 시작을 요청하는 RoutineControlType 파라미터이다. RoutineControlType 칸을 선택하면 오른쪽 끝 '...' 버튼을 볼 수 있다. 이를 클릭하면 타입을 선택할 수 있는 창이 뜬다. 선택한 값에 따라 루틴을 시작시키거나, 정지시키거나, (진행 여부) 상태 회신을 요청할 수 있다.
-
루틴 제어를 시작, 정지, 상태 점검 요청을 할 수 있는 RoutineControlType 파라미터를 선택한다.
-
- FF 00은 루틴의 아이디이다. EraseFlash 루틴은 FF 00으로 사양서에 정의되어 있다는 의미이다. 루틴마다 고유의 아이디가 있(어야 한)다. 루틴 아이디는 직접 입력한다.
- ss의 이름은 RoutineControlOptionRecord로 되어있다. 값은 0x44이다. 나는 이 파라미터의 용도를 모른다. Erash Flash 설정 화면을 보면 Length Format으로 되어있고, 적용 여부를 선택할 수 있는 옵션이다.
- xx xx xx xx와 yy yy yy yy는 삭제(erase) 영역의 주소(Address)와 크기(DataLength)를 전달하는 파라미터가 있다. 내가 했던 프로젝트에서는 사용자는 미리 정해진 영역의 번호를 선택하도록 되어있었다. 위 그림의 경우 주소와 크기 모두 32 bit이다. 설정을 위해 많은 숫자를 입력해야 한다. 입력 실수가 있을 수 있다. 프로그램 대상인 플래시 메모리의 영역들은 소프트웨어 개발 중에 정해진다. 몇 개 안 된다. 각 영역에 번호를 부여하면 짧은 입력으로 (파라미터 한 개로) 영역을 지정할 수 있다. 실수의 확률을 줄일 수 있다. 이것은 현재처럼 자동화가 발달하지 않아 수작업이 많았던 과거의 이야기이다.
- 자동화 수준이 높고 활발한 현재는 주소와 크기를 다운로드할 파일에 맞게 자동으로 주소와 크기가 지정되도록 한다. 다운로드할 파일인 hsl을 선택하면 TSMaster는 관련 시스템 변수들을 생성한다.
시스템 변수 창에 다운로드할 파일인 hsl을 접두어로한 변수들이 생성된다. StartAddress, DataLength, Checksum 변수들과 계산된 값들을 볼 수 있다. - Parameters에서 파라미터를 선택한 후 "+" 버튼을 클릭하고 시스템 변수 창에서 해당하는 변수를 클릭하면, 시스템 변수의 값이 파라미터의 값으로 사용된다.
파라미터와 시스템 변수를 연결한다. Erase Flash 계속
- 343637 DownloadFile의 Erase Flash로 돌아와서 마저 설명한다.
- $3101 부분은 위에서 설명하였다. 0x31은 루틴 제어의 서비스 아이디. 0x01은 시작을 의미하는 파라미터.
Erash Flash 설정 - Block Erase Type은 아래 그림의 선택 옵션들이 있다. 이 선택에 따라 진단기와 제어기 사이의 통신에 어떤 차이가 있는 지는 (추측은 있지만) 모르겠다. 요청에는 해당하는 파라미터가 없기 때문이다.
삭제 방법을 선택할 수 있다. - RoutineID는 Erase Flash 루틴의 아이디이고 FF00으로 정의했다.
- $44는 위에서 설명한 것처럼 정확한 용도를 알지 못한다.
- Expected Response는 기대하는 응답이다.
글이 날라갈까 우려가 된다. 이 블로그는 여기까지에서 저장하고 발행한다. Request and Transmit Data는 다음 블로그에서 설명한다. UDS 진단 통신으로 하는 소프트웨어 업데이트 4 - 소프트웨어 전송 (계속) :: hsl's tsmaster 사용기
'diagnostic' 카테고리의 다른 글
UDS 진단 통신으로 하는 소프트웨어 업데이트 5 - 메타 데이터 업데이트 (0) 2025.02.28 UDS 진단 통신으로 하는 소프트웨어 업데이트 4 - 소프트웨어 전송 (계속) (0) 2025.02.28 UDS 진단 통신으로 하는 소프트웨어 업데이트 2 - 보안 접속 (0) 2025.02.26 UDS 진단 통신 (4 / 4) - ReadDTC 응답 해석을 위한 미니프로그램 (1) 2024.10.25 UDS 진단 통신 (3 / 4) - 진단 요청/ 응답 메시지 설정 (0) 2024.10.25