안녕하세요.

임베디드 개발을 하게되면 여러가지 알수없는 현상을 목격하고 이를 해결하기 위한 노력을 하게 됩니다.

운이 좋아서 쉽게 원인을 해결할 때도 아니면 소 뒷발에 쥐잡기로 해결이 되는 경우가 있지요.

오늘 몇가지 사례를 공유해보고자 합니다.

거창한 분석방법을 이용해서 해결한 것이 아니고 자유게시판인 만큼 그냥 지나가는 소리로 읽어주시면 감사하겠습니다.

제가 경험했던 경우와 주변 엔지니어에게 들은 신기한 케이스들입니다. 너무 많지만 몇가지만 공유해보겠습니다.

1. 대학 석사때 아는 형님

- 하드웨어 보드르 만들었는데 한달째 디버깅도 안되고 동작이 안됨.

- 매일 끙끙 앓다가 꿈에서 20번 버스가 사람을 태우고 자기 앞을 지나감.

- PCB 에 20번 BUS 라인을 확인하고 바로 해결 (단선)

- 이해가 되시나요? 그 버스가 그 bus 이더냐?

2. 제가 초보때

- NAND 칩이 바뀌었는데 동작이 안됨.

- 삼성 NAND 스펙만 정말 한달 내내 정독 정독. 코드도 4페이지 이하라 한달내내 그것만 봄.

- OOB 영역 크기가 바뀐 문제였는데 해결이 안됨.

- 한달째 되는 새벽녘 잠자리에서 어슴푸레 꿈과 현실이 구분 안되는 상황에서

누워있는 천장에서 왼쪽엔 코드가 오른쪽에 데이터시트가 나타남.

- 신기한 것은 어슴푸레가 아니라 코드 한자 한자 테이터 시트 한자한자 다 읽어짐.

- 심지어 페이지 넘김 해도 선명하게 모든 글자가 다 읽힘 (아마 자동으로 다 외어 졌던듯)

- 꿈속에서 데이터 시트를 다시보다가 특정 문구 발견

- 해당 코드로 진입하여 머리속으로 수정 및 디버깅. 머리속으로 컴파일 단축키도 눌렀음.

- 꿈속에서 이건 해결한 거다 라고 확신이 듬.

- 출근하여 정말 그 부분(당연히 꿈 속의 코드랑 현실 코드랑 같지요) 한 줄만 수정하여 해결

3. 초보때 선배 엔지니어 술자리에서 제가 졸라서 들은 신기한 경험 (제발 이야기해주세요~~ 이런 분위기)

- 커피 자판기 제작 회사임

- 계속 현장에서 자판기 컵이 걸린다는 신고

- 사무실에서는 재현 불가

- 자주 목격되는 현장 출장 방문

- 며칠을 반복하며 생길때 까지 방문

- 일주일뒤 정말 컵이 많은데 걸려서 나오지 않음.

- 떨리는 마음으로 커피 자판기 도어를 염.

- 너무 놀래서 뒤로 자빠질 뻔 함.

- 컵이 쌓여서 마지막 1-2개정도만 남았는데 그 컵이 컵트레이 속에서 공중에 떠 있음. 게다가 살짝 움직이면서 둥둥.

- 그래서 그 트레이를 손으로 가만히 잡으니 우주선 착륙하는 것 마냥 천천히 착륙함.

- 회사로 돌아가서 트레이 사출 재질을 변경함.

- 다들 이유를 아시겠죠? ㅎㅎㅎ

4. 기구 엔지니어 썰

- 표 판매기 기구에서 500원 동전이 자꾸 걸림.

- 알바 3명을 시켜서 500원 잔뜩 주고 재현될때까지 시킴.

- 일주일 뒤...

- 알바 한 명이 동전이 걸렸다고 달려옴.

- 긴장된 표정으로 엔지니어 총 출동 (야! 절대 손대지 말고 가민하 놔둬 를 외치며 30m 거리를 날라감)

- 도어를 정말 천천히 열어봄. 재현상황이 무너질까봐~~

- 매끈한 동전 회수함 앞단에서 평면판 위에 500원 짜리 동전이 세로로 서 있었음.

-> 500원 짜리 동전을 랜덤하게 던져서 똑바로 설 확율임.

-> 8시간 x 5일 x 3명 당 1번

- 바닥을 평면으로 하지 않고 기울어지게 설계 변경

 

다들 그런거 있쟎아요 나만 아는 신기한 경험들 ㅎㅎ

 

즐거운 하루 되세요~~~

 

프로그램은 오래 짜왔지만 경력에 비하여 코딩 실력은 그리 뛰어나지 않다고 생각됩니다.
다만 제가 잘하는 걸 생각해보면 
나름 버그 없는 프로그램 (제가 개발한 제품들은 보통 24시간 꺼지지 않거나 하루 12시간 이상
계속적으로 사용되는 금융 데이터 처리하는 제품) 을 만들고, 
문제 발생시 디버깅 대처 능력이 매우 빠르다는 것입니다.
 
펌웨어 변경시마다 수십억 이상의 배상건이 발생할 가능성이 있는 시스템을 다루면서
극도의 긴장감과 공포속에서 나날을 보냈던 기억이 납니다. 
펌웨어 오류로 옆동네에서 회사 파산하고 개발자 도망가고 그런 모습들을 보면서 나한테도 그런일이 생길까
노심초사하던 시절이 있었습니다. 이 일도 익숙해지면 그냥 그렇더라구요. 
 
그런 와중에 살기위한 대책으로 자연스레 학습이 되었는데
버그 없는 코딩 이전에 버그 찾는 방법을 알려드립니다. 대부분 이걸 필요로 하실 겁니다.
 
펌웨어의 경우 문제가 발생하면 보통 2가지중 하나입니다.
   하드웨어냐 펌웨어냐!
   1) 펌웨어 엔지니어는 하드웨어를 의심하고 하드웨어 엔지니어는 펌웨어를 의심합니다.
   2) 답은 자신을 의심하세요. 남을 의심하는 것은 나에 대한 완벽한 논거가 확립된 뒤에야 
      의심하시면 됩니다.
 
제가 디버깅 하는 순서로 주로 현장 시스템인 경우입니다.
너무 원론적인 거라 잘 적용이 안될 수는 있지만 해결 방법은 대동소이합니다.
 
사례를 들면 좋은데 너무 전문적으로 가게 되어서 일반적인 방법론으로 풀어봅니다.
 
1. 전체를 파악한다.
   보고자가 말하는 의중을 제외하고 사실 데이터만 수집한다.
   직접 현상을 확인해본다. 책상머리에서 상상으로는 해결이 불가하다.
   참고로 보통 보고자들은 이상 발생에 대하여 과장보고하는 경우가 일반적입니다.
2. 그 중에서 확실한 것은 제외한다. 확실하다는 것은 이론과 실증을 통하여 자기 확인이 아닌
   정확한 데이터에 기반한 확실한 것을 말합니다.
   정확하게 이론과 실증입니다. 10년동안 잘 돌던 코드는 약간의 실증만 있는 코드 입니다. 
   이론으로 바탕되지 않은 코드죠. 해당 코드 부분을 잘라서 거의 모든 경우의 데이터 입력을 통한 
   시뮬레이션 후 일치를 확인하고 믿어야 합니다.
3. 2번을 생각하면 거의 모든게 의심스러워 집니다. 왜냐하면 데이터시트도 제대로 안보고 만든게 많기 때문이죠.
   이제서야 보기 시작합니다.
4. 발생 빈도를 확인한다.
   단 한번 발생하고 안했느냐. 지금도 계속 발생하느냐. 특정 조건에만 발생하느냐(이 경우는 해피한 경우입니다)
5. 약간은 좁혀진 범위에서 의심가는 부분을 과도하게 반복시켜서 재현이 되는지 확인한다.
   여기서 과도한 반복이 어려운 경우가 제일 문제가 되긴 합니다만 세상에 방법이 없는 건 없습니다.
   3개월에 한번 발생한다면 배포한 단말기들의 프로그램을 변경(의심부분 로그만 확인)하고 
    재현될때까지 정말 3개월동안 기다린 적도 있습니다. 총 수정까지 1년이 걸렸구요.
6. 과도한 반복을 통한 재현이 되면 거의 그 부분이 확실한 겁니다.
   그럼 재현이 잘 되니 점차 함수의 범위를 좁힐 수 있습니다.
   계속 큰데서 작은데로 범위를 좁혀갑니다.
   일반적으로 여기서 실수하는데 처음부터 의심가는 부분 작은데서만 집중하면 해결이 안됩니다.
   의외로 내가 확신했던 부분에서 오류가 발생합니다.
7. 확실한 코드 부분을 찾으면 동일한 상황을 만들어서 정확히 재현시켜 봅니다.
   그러면 100% 확인이 된 겁니다.
8. 이상하게도 재현이 안된다 라는 상황이 있습니다. 그러면 5번 참조. 재현이 됩니다.
   몇달만에  한번 생기더라도 그물을 쳐놓고 몇달 기다리면 됩니다.   
   이 문제로 회사가 망하는 게 아니라면 내부적으로 그 부분을 과도하게 동작하도록 처리하고
    최대한 많은 단말기에 다운로드해서 상황을 지켜봅니다. 발생이 더 잘되면 기뻐하면 됩니다.
9. 그럼에도 나는 완벽하다면 슬슬 하드웨어를 의심해야 됩니다.
   모든 데이터를 수집하세요. 날짜별 발생 빈도, 단말기 위치, 그날의 온도 습도 까지도 등등 
   빅데이터 처럼 모을 수 있으면 찾기가 더 쉽습니다.
10. 통신문제 처럼 되었다 안되었다 하면 통신관련 소자의 클럭이나 크리스탈에 달린 커패시터 값을 확인하세요.
11. 펌웨어가 운영 중 소자 다운시 리셋을 걸어주고 초기화 과정을 다시 잘 실행하는 지 확인하세요.
12. 해당 하드웨어가 노이즈 테스트 및 정전기 테스트는 하였는지 확인하고 안했다면 테스트 해보세요.
    라이터 부싯돌로도 단말기가 죽는 수도 있습니다.
13. 보드의 여러 소자들의 최대 주파수 범위내로 동작시키고 있는지, 데이터 시트를 몽땅 다시 다 확인해보세요.
14. 역시 보드의 여러 소자들의 리셋 타이밍도 맞게 동작시키고 있는데 확인해보세요.
15. 그래도 못찾으면 펌웨어가 와치독을 제대로 사용하고 있는지 확인하세요. 
    최악의 경우 재부팅은 되어야 겠지요. 그렇게 해서 가끔씩 재부팅하는 체로 동작하게 하세요. 
   시간도 벌고 일단 살고 봐야 되니깐. 
   그 다음에 퇴사하세요. (농담입니다 ㅎㅎ)
 
    
다음번에는 죽은 하드웨어도 인공호흡으로 살리는 
"PCB 노이즈 대책 코딩 기법"에 대하여 한번 올려드리겠습니다.
이런게 이론으로 있는지는 모르겠지만 저는 효과가 있다고 봅니다.
 
하드웨어 엔지니어가 엉망이라도 우리 펌웨어 엔지니어는 살려 낼 수 있습니다.
너무 하드웨어만 탓하지 마세요. 담에는 하드웨어 엔지니어가 펌웨어 엔지니어를 살려 줄껍니다.

 

+ Recent posts