임베디드 소프트웨어 디버깅 장비3 - 인 서킷 에뮬레이터

 

새로운 장비인 인 서킷 에뮬레이터를 설명하기에 앞서서 지난번까지 알아봤던 로직 어날라이저에 대한 내용을 조금 더 살펴보고 지나가겠습니다. 스테이트 모드의 유용성과 전체적인 단점에 대한 내용입니다.

 

로직 어날라이저의 스테이트 모드는 소프트웨어 엔지니어에게 유용한데요, 어떤 부분에 있어서 느낄 수 있는지 봅시다.

 

- 만약 메모리가 존재하지 않는 주소나, bad_assertion 함수에 있는 주소처럼, 마이크로프로세서가 가져오지 말아야 할 곳으로부터 명령어를 가져오면 트리거가 걸리도록 로직 어날라이저를 설정할 수 있습니다. 그러고 나서, 뒤로 가면서 어디에서 문제가 발생했는지를 조사할 수 있습니다.

 

- 마이크로프로세서가 RAM의 특정한 장소에 유효하지 않은 값을 쓸 때, 트리거가 걸리도록 로직 어날라이저를 설정할 수 있습니다. 만약 시스템이 고작 6개의 상태를 가지고 있는 스테이트 머신에 7번째 상태를 쓰려고 한다면, 이 시스템은 문제가 있는 겁니다. 만약 포인터에 RAM의 주소 범위를 벗어나는 주소를 쓰려고 한다면, 도대체 무엇이 그렇게 만드는지 궁금하겠죠.

 

- 인터럽트 루틴의 첫 번째 명령어를 가져올 때 트리거를 걸어서, 인터럽트 루틴을 실행하면서 마이크로프로세서가 어떤 동작을 하는 지를 알 수 있습니다.

 

- 가끔 발생하는 버그를 가지고 있는 경우, 타깃 시스템과 로직 어날라이저를 밤새 실행시키도록 해서 아침에 결과를 확인해 볼 수도 있습니다.

 

- 대부분의 로직 어날라이저는 저장되는 것을 제한할 수 있는 필터를 설정할 수 있도록 허용합니다. UART의 주소만을 필터링해서 마이크로프로세서가 UART에 읽거나 쓸 때만 데이터를 저장할 수 있도록 설정할 수 있습니다. 이렇게 해서, UART와 소프트웨어와의 상호작용을 알 수 있습니다.

 

보통 문제의 증상이라고 생각하는 이벤트들에 로직 어날라이저의 트리거를 설정해 놓고 어떻게 코드가 그 상태로 되었는지를 뒤로 가면서 조사를 하곤 합니다.

 

이제는 로직 어날라이저의 단점에 대해서도 말해볼게요.

 

- 로직 어날라이저가 마이크로프로세서가 어떤 것을 했는지를 알려줄 수는 있지만, 회로를 따라 한 스텝씩 실행시키거나 레지스터의 값을 보거나 메모리의 내용을 바꾸는 등의 동작을 하려고 브레이크 포인트를 설정해서 마이크로프로세서를 정지시키는 것은 불가능합니다.

 

- 마이크로프로세서가 메모리를 읽거나 쓸 때만, 메모리의 내용을 알 수 있습니다. 게다가 마이크로프로세서의 레지스터 값은 알 수 없고요.

 

- 프로그램이 정지되었다면, 메모리의 내용, 레지스터 그 밖에 다른 시스템에 있는 어떤 것도 알 수가 없습니다.

 

- 마이크로프로세서가 큰 캐시 메모리를 가지고 있고, 캐시로부터 명령어를 실행시킨다면 로직 어날라이저는 마이크로프로세서의 내부에서 어떤 명령어가 캐시로부터 읽히는 지를 알 수 없기 때문에, 마이크로프로세서가 어떤 일을 하는 지를 알 수가 없습니다. 로직 어날라이저는 그저 메모리로부터 읽히는 명령어를 볼 수 있을 뿐입니다.

 

다소 내용이 길어졌지만 한번 꼭 보고 넘어가셨으면 좋겠습니다.

 

 

[인 서킷 에뮬레이터]

 

에뮬레이터 또는 약자로 ICE로 불리기도 하는 인 서킷 에뮬레이터는 타깃 회로에 있는 마이크로프로세서를 대체합니다. 회로에서 마이크로프로세서를 제거하고 그 자리에 에뮬레이터를 붙입니다. 타깃 회로에 있는 다른 칩들의 관점에서 보면, 에뮬레이터는 마이크로프로세서로 보입니다. 실제 마이크로프로세서가 연결하고 구동하는 모든 시그널에 같은 방법으로 연결합니다. 그러나 에뮬레이터는 표준 데스크톱 시스템의 소프트웨어 디버거와 비슷한 디버깅 능력을 제공해 줍니다. 일반적으로, 브레이크 포인트를 설정할 수 있고, 브레이크 포인트에 다다르면, 메모리 값과 레지스터의 값을 조사할 수 있고, 소스 코드를 볼 수 있고, 명령을 다시 실행할 수 있고, 코드를 통해 한 스텝씩 명령을 수행시킬 수도 있습니다. 만약에 프로그램이 다운되더라도, 대개의 경우 에뮬레이터는 여전히 메모리와 레지스터의 내용을 볼 수 있게 해 줍니다. 그리고 로직 어날라이저보다는 유연성이 떨어지긴 하지만, 대부분의 에뮬레이터는 로직 어날라이저의 스테이트 모드에서처럼 트레이스를 저장할 수 있습니다.

 

많은 에뮬레이터는 에뮬레이트 된 마이크로프로세서가 타깃 시스템의 메모리 대신 사용하도록 하는 하나 이상의 메모리 블록을 내부에 가지고 있고 이것을 오버레이 메모리라고 부릅니다. 오버레이 메모리를 사용하도록 주소 범위를 설정해서, 어떤 범위, 이를테면 타깃의 롬이나 플래시가 해당하는 부분만 읽기 가능하도록 하고 RAM에 해당하는 부분은 읽기 쓰기가 가능하도록 해서 에뮬레이터의 주소 범위를 설정할 수 있습니다. 에뮬레이트 된 마이크로프로세서가 특정 범위의 주소에서 데이터를 읽거나 쓸 때, 에뮬레이터는 타깃의 메모리 대신 오버레이 메모리를 사용할 것입니다. 툴들 간에 호환성이 있다는 전제 하에, 에뮬레이터를 위한 소프트웨어가 로케이터의 출력 파일을 읽게 해서 코드를 오버레이 메모리에 올라가도록 만듭시다. 이건 디버깅을 위해서 소프트웨어를 타깃에 다운로드하는 매우 쉽고 효율적인 방법이 될 겁니다.

 

상상하던 대로 에뮬레이터는 매우 유용한 장비임에 분명합니다. 데스크톱 디버거의 성능과 로직 어날라이저의 능력을 동시에 가질 수 있습니다. 아마도 에뮬레이터의 성능이 로직 어날라이저를 필요 없게 만들었다고 생각할 수 도 있지만 잘못된 생각입니다. 에뮬레이터와 비교해서 로직 어날라이저가 나은 점이 뭔지 말해볼게요.

 

- 로직 어날라이저는 일반적으로 복잡한 환경에서 문제를 발겨하는 것을 더 쉽게 만드는 더 나은 트레이스 필터와 더 정교한 트리거링 방법을 가지고 있습니다.

 

- 타이밍 모드에서도 작동합니다.

 

- 어떤 마이크로프로세서와도 동작을 합니다. 시장에 나와 있는 모든 마이크로프로세서가 에뮬레이터를 가질 수 있는 것은 아닙니다. 칩 제조 회사는 에뮬레이터 제조 회사가 새로운 에뮬레이터를 시장에 공급하는 것보다 더 쉽게 새로운 마이크로프로세서들을 시장에 공급합니다. 에뮬레이터가 가능하더라도, 에뮬레이터 가격이 저렴한 것은 아닙니다. 보통 마이크로프로세서를 변경할 때마다, 심지어 지금 마이크로프로세서랑 아주 조금 다른 종류를 선택해도 새로운 에뮬레이터를 구매해야 합니다.

 

- 원하는 많은 아니면 적은 연결만 가질 수도 있습니다. 에뮬레이터로는 그 자체가 중요한 프로젝트가 되는 모든 시그널들에 연결을 해야만 하죠.

 

- 에뮬레이터는 일정 수준 이상 더 시스템에 영향을 미칩니다. 때로는 에뮬레이터로 마이크로프로세서를 대체할 때 예전 버그는 사라지고 새로운 버그가 나타나기도 하고요. 로직 어날라이저를 연결할 때도 역기 문제가 생길 수 있긴 하지만 일반적인 경우는 아닙니다.

 

몇몇 회사들은 로직 어날라이저와 에뮬레이터를 혼합해서 두 장비의 능력을 동시에 제공하는 하이브리드 장비를 생산하기도 합니다. 임베디드 시스템을 테스트하거나 디버깅하는 것의 어려움이 이런 제품의 제조 회사들에게 창조성을 제공한 것이라고 볼 수 있겠습니다.

 

 

[하드웨어를 관찰할 수 있도록]

 

적당히 지나간 것 중의 하나를 돌이켜보면 로직 어날라이저와 에뮬레이터는 단지 연결된 시그널에 대한 것만 말할 수 있다는 것이었습니다. 그렇게 오래되지 않은 과거에는 칩의 핀 사이가 십 분의 일 센티미터 정도 떨어져 있었기 때문에, 연결하는 것이 그렇게 큰 문제는 아니었습니다. 로직 어날라이저의 프로브를 시그널에 연결하는 것은 각각 서로 떨어져 있었기 때문에 상대적으로 쉬웠습니다. 그러나, 칩과 시그널들 사이의 공간은 점점 더 작아졌습니다. 십 분의 일 센티미터 정도 떨어져 있는 시그널을 찾기란 고대 생물을 보는 것만큼 어려워졌습니다. 재밌게도 그 정도 떨어져 있는 신호 선들은 요즘 신호 선들이 비하면 고대의 거대 생물만큼 크게 보입니다. 작고 더 가깝게 붙어 있는 타깃 시스템의 시그널에 프로브를 연결하는 것은 더 골치 아파진 시대가 되었죠.

 

이런 문제에 이상적인 해답이란 존재하기 힘듭니다. 이상적이지는 않지만 그나마 가능한 해결책은 많은 제조 회사들이 다양한 종류의 클립과 프로브, 새롭고 더 작은 부품에 연결할 수 있는 도구들을 파는 것입니다. 시그널들의 공간이 점점 더 작아지기 때문에, 이런 제품들은 더 비싸지고, 더 설치하기 어렵고, 잘 망가지고, 어느 정도 안정성이 떨어질 겁니다. 하물며 이런 것들의 대부분은 연결시키기 위해서 칩 주위에 어느 정도 공간을 필요로 할 것이고, 이 것은 설계할 때 미리 염두에 두어야 한다는 말이 되겠죠. 그럼에도 불구하고 이런 제품은 아주 값진 선물입니다.

 

다른 가능성은 측정하고 싶은 시그널을 디버깅 장비가 연결될 수 있는 소켓에 붙여서 타깃 시스템을 설계하는 겁니다. 편리하긴 하겠지만 추가 소켓을 위한 공간이 제품을 더 크게 만들 것이라는 것은 뻔히 보이는 문젯거리입니다. 이런 계획은 또 어떤 버그를 추적해야 할지 알기도 전에, 사전에 어떤 시그널을 측정해야 하는 지를 미리 결정하게 만들죠.

 

세 번째 가능성은 소프트웨어 디버깅을 위해서 선적될 제품과는 적자 회로적으로 동일하지만 측정은 쉽게 할 수 있는 특별한 회로를 설계하는 겁니다. 물론 이런 방식의 단점은 디버깅만을 위한 회로를 설계하고 제작하기 위해서 추가 비용이 든다는 것이고, 아무리 같게 만든다고 하더라도 실제 제품과 실험실의 제품은 차이가 존재한다는 것입니다. 또 매우 빠른 속도를 가진 특정한 칩은 구조적으로 큰 회로에서 도작하지 않을 수도 있습니다.

 

소프트웨어 엔지니어가 마주칠 수밖에 없는 또 다른 동향은 복잡한 회로를 만들기 위해서 분리되어 있는 부품들을 하나로 합치도록 해주는 ASIC입니다. ASIC안에만 있는 시그널들은 측정할 수 없기 때문에, 실제로 수행되는 많은 부분들이 실험실 장비들로부터 숨게 됩니다. 이런 경향의 극단적인 상황은 ASIC에 마이크로프로세서, 메모리, UART, 네트워크 연결, 모든 생각할 수 있는 잡동사니를 한데 넣는 것입니다. 이런 것을 SOC, system on a chip이라고 부릅니다. ASIC 밖으로 어떤 어드레스나 데이터 시그널이 나오지 않기 때문에 마이크로프로세서가 어떤 일을 하는지에 대해서 말하는 것이 불가능합니다.

 

어떤 제조사들은 ASIC과 소프트웨어를 동시에 시뮬레이트 해주는 툴을 만들고 있긴 하지만 실제로는 만족스럽지 못한 경우가 많습니다. 그러는 동안에 하드웨어와 소프트웨어 엔지니어들은 소프트웨어를 디버깅할 수 있도록 해주는 솔루션을 즉흥적으로 만들어야만 합니다.

 

시스템을 디버깅하는 일을 어렵게 하는 요인 중 또 다른 하나는 RISC 기술의 사용이 증가했다는 겁니다. RISC 마이크로프로세서는 매우 빠르기 때문에 인기가 있는데 이런 속도는 상대적으로 느린 외부 메모리에서가 아니라 마이크로프로세서에 내장된 매우 빠른 캐시 메모리로부터 명령어와 데이터를 가져오기 때문입니다. 이런 마이크로프로세서는 명령어와 데이터 블록을 외부 메모리로부터 캐시 메모리로 복사한 후에 나중에 어떤 것을 사용할지 결정합니다. 버스를 관찰하는 로직 어날라이저는 어떤 일이 발생하는지에 대해서 정보를 주지 못합니다. 보통은 RISC 마이크로프로세서를 위한 에뮬레이터가 어떤 명령어가 실행되었는지에 대한 정보를 주는데, 심지어 에뮬레이터마저 종종 어떤 데이터가 읽혔는지 쓰였는지에 대한 정보를 주지 못하곤 합니다.

 

디버깅 장비 제조 회사들은 문제 해결을 위한 장비를 만들고 있긴 하지만 모든 해결책은 다양한 종류의 타협이 될 겁니다. 엔지니어는 그중에서 가장 선호하는, 그리고 소화 가능한 타협을 선택해야 하는 거죠.

 

이런 것들은 복합적으로 작용하여 사전에 어떻게 소프트웨어를 디버깅할지 계획하는 것이 제품 개발의 중요한 측면이 될 정도로 충분히 곤란한 문제가 됩니다. 모든 도구가 항상 가능한 데스크톱 환경과는 다르게 임베디드 환경에서의 실험실 장비들은 제품을 만들 때 그런 장비들을 사용할 수 있도록 설계했을 때만 사용 가능하니까요.

 

 

참고)

임베디드 소프트웨어 디버깅 장비1 - 전압계/저항계, 오실로스코프

 

임베디드 소프트웨어 디버깅 장비2 - 로직 어날라이저