MDSTECH

* 문제점 및 증상

스마트폰을 개발 하던 중 아주 간헐적으로 (100대중 한대에서 1달에 한번 정도) Standby mode 이후 Wakeup을 하지 못하는 경우가 있었습니다.

개발 플랫폼은 ARM920T Core의 모사의 통합 칩이었고 당시 개발방법은 Exception handler에 OS의 변수들을 device의 file로 저장하도록 하여, 문제 발생시에 그 Log file을 보고 분석하는 것이었습니다. 하지만 이 경우에는 위와 같은 디버깅 방법이 그다지 효과가 없었습니다. 일단 Log도 입수하기 쉽지 않았고, 죽는 위치가 도저히 종잡을 수 없었기 때문입니다.



* TRACE32 접근방법(디버깅)

일단 OS를 수정하여 일정시간마다 Standby Wakeup을 반복하게 하였습니다.

Wakeup 하자마자 시작되는 코드에 Breakpoint를 걸고 Break가 될 때마다 Code 영역 메모리 전체를 파일로 저장하고 매번 이전 파일과 diff하도록 Practice Script를 작성한 후 (diff는 Command line tool을 만들고 Practice에서 OS call하도록 하였습니다.) 낮에는 다른 버그를 잡고 밤에는 Script를 걸어놓고 퇴근했습니다.



3주 정도 지났을 때 현상이 나왔는데 Dump한 파일에서 차이가 발견된 부분을 Disassemble해보니 Wakeup때 실행되는 한 Function의 끝에서 ret하는 부분의 Opcode가 다른 것으로 바뀌어 있었습니다. 코드 영역 2Mega중에서 200byte정도가 달라져 있었던 것으로 기억합니다.

따라서 실행되어서는 안 되는 함수로 진입을 해버린 것인데, 그제서야 Log file의 신비가 이해가 되었습니다. 또 코드 메모리 자체가 깨지는 것이니 현상은 전혀 관련이 없어 보일 정도로 Random한 것이 당연했습니다.

Code메모리 전역에 Memory Write Breakpoint를 걸고 또 다시 3주정도를 기다렸습니다. 결국 하드웨어 문제임이 증명되었고, 다른 개발자가 SDRAM 초기화 Parameter를 수정하여 해결하였습니다.



이 외에도 PDA용 모 OS에서 부팅 중에 DB가 깨지는 일이 간혹 있었습니다. OS측에서는 이 문제가 새로운 솔루션 때문이라는 증거를 요구했고 저희가 답변을 해야 하는 상황이었습니다.

결과만 말씀 드리면 OS문제였는데, 당시 저희는 Power On시에 DB가 깨진다는 심증만을 가지고 있었습니다. 이 때 사용한 방법이 입력 Level이 TTL호환인 SSR(Solid State Relay)로 간단한 Switch를 만들고 한쪽을 Parallel Port의 D0에 연결하고 다른 쪽을 Device의 power단에 연결한 후 Parallel power의 D0를 On/Off하는 Command line용 프로그램을 작성했습니다. 역시 이번에도 Practice로 다음 Sequence를 반복했습니다.

- SSR로 Device Power On

- Initialize Script를 실행(디버깅을 위해서는 반드시 Script를 돌려야 했습니다)

- 문제 예상 지점 바로 뒤까지 Run

- DB분석 문제없으면 다시 1번으로, 문제 발견되면 RAM을 PC의 File로 저장 및 개발자가 출근할 때까지 Break상태로 대기



역시 이번에도 낮에는 다른 버그 잡고 퇴근할 때 걸어두곤 했는데 이 문제는 2~3일이면 결과가 나와서 PC에 저장된 파일을 OS측에 보내어 확인을 받고, 그 쪽에서 새 코드가 올 때마다 테스트하여 결과를 알려주었습니다. 이후로 저희 쪽 말을 많이 믿는 눈치였습니다.



* 결론

임베디드의 경우 알 수 없는 버그가 많고 그 규명이 쉽지 않아 을의 입장에서 일하는 저희 회사는 버그의 확실한 원인 규명이 중요한데, 이때 TRACE32가 많은 도움이 되었습니다.

제 생각에 TRACE32의 최대 강점은 Practice Script Language(CMM)인 것 같습니다.

앞서 설명했듯이 디버깅 자동화로 개발자가 쉬는 동안에도 낭비가 될 수 있는 반복적인 디버깅 시간을 어느 정도 줄일 수 있다는 점이 큰 매력인 것 같습니다.