회로 내 에뮬레이터 (약칭 ICE)는 뛰어난 디버깅 기능을 자랑하며 고가의 태그도 자랑합니다.
회로 내 디버거 (약칭 ICD)는 ICE가 할 수있는 대부분의 작업을 수행 할 수 있지만 비용은 훨씬 저렴합니다.
ICE는 실제로 소켓에서 문제 칩을 제거하고 에뮬레이터 케이블로 교체하지만 현대 QFN, BGA 및 취약한 TQFP 패키지를 사용하면 대부분의 제품을 스스로 "ICE"디버거라고 부릅니다. ICD와 거의 같은 방식으로 디버그 헤더에 연결됩니다.
이름에 "ICE"를 사용하는 제품의 예는 다음과 같습니다.
여러 공급 업체의 JTAG 'ICE'제품도 있습니다. 물리적으로 회로가 아니기 때문에 할인하지는 않지만 진정한 ICE로 작동하지 않으면 할인합니다.
어떤 종류의 개발 작업에서 ICE가 필요하며 언제 ICD에 만족해야합니까? 코드를 단계별로 실행하고 LED 및 printf () 문을 사용하지 않는다고 가정합니다.
ICE로 해결했지만 실제로는 해결할 수없는 문제의 예는 무엇입니까?
답변:
ICE (In-Circuit Emulator)가 대상 칩을 대체합니다. 회로의 나머지 부분에 대한 실제 칩처럼 작동하지만 내부에 모든 종류의 후크가있어서 진행 상황을 확인하고 중단 점을 설정하며 새 코드를로드하고 추적을 잡을 수 있습니다. ICD (In-Circuit Debugger)는 해당 목적을 위해 대상 칩에 추가 된 특수 디버그 하드웨어를 사용하여 ICE와 유사한 기능을 제공하려고합니다. 불행히도, 마케팅 사람들은 당신이 그들의 제품이 다음 제품보다 낫다고 생각하도록 속이려는 이러한 장기적인 용어를 다시 정의하려고 노력했습니다. Microchip의 RealIce가 특히 그 예입니다. 진짜이지만 그렇지 않은 것은 ICE입니다.
실제 ICE (RealIce가 아님)는 최상의 회로 내 디버깅 환경입니다. 불행히도, ICE에서 사용하기 위해 타겟 칩의 특수 본드 아웃 버전을 만드는 데 드는 높은 비용과 칩에서 무언가를 꺼내는 것이 문제가되기 때문에 속도가 너무 빨라 졌기 때문에 이것들은 거의 사라졌습니다. 또 다른 문제는 ICE가 대상 칩이 소켓에 있거나 대상 칩 대신 특수 어댑터가 장착되어 ICE가 해당 라인에 연결될 수 있다는 것입니다.
그래서 오늘 우리는 ICD에 갇혀 있습니다. 다행히도 그들은 ICE로하고 싶은 대부분의 일을합니다. 코드가 실제 대상 칩에서 실행되는 것이 아니라 대상 칩 과 같은 것을 시도하는 것이 아니라는 장점도 있습니다 . 단점은 온칩 리소스가 필요하므로 ICE처럼 코드와 하드웨어에 완전히 투명하지 않다는 것입니다. ICD는 종종 여러 역할을 수행 할 수있는 디버깅 라인에 액세스해야합니다. 디버깅 중에 다른 역할에서 해당 핀을 사용할 수 없습니다. 각 부품에 내장 된 디버그 회로의 양은 전체 비용의 작은 부분으로 유지되어야합니다. 그렇지 않으면 비용이 너무 많이 들기 때문에 기능이 손상되어야합니다. 모든 칩에 추가하기에는 비용이 많이 드는 멋진 기능 중 하나는 큰 RAM 버퍼가 필요하기 때문에 진정한 추적 기능입니다.
모든 문제는 결국 다양한 도구로 해결할 수 있습니다. 당신이 그것을 해결할 수 있는지가 아니라 얼마나 많은 시간과 노력이 필요합니다. 정기적으로 ICE (Microchip ICE-2000 및 ICE-4000)를 사용하는 경우 추적 기능을 자주 사용하지 않았지만 다른 방법을 사용하면 훨씬 더 많은 비용이 듭니다. 때로는 변수에 갑자기 잘못된 값이있는 버그가 있습니다. 코드를 단계별로 실행하면 모든 것이 정상이며 변수를 조작하는 루틴이 모든 것을 올바르게하는 것처럼 보이지만 결국 실행하면 문제가 발생하여 해당 변수가 휴지통에 빠집니다. 원인은 잘못된 포인터, 버퍼 오버플로, 스택 불일치 등을 가진 다른 코드입니다. ICE를 사용하면 변경되는 변수에 중단 점을 설정할 수 있습니다.
대부분의 경우 ICD가 충분할 것입니다. 특히 큰 칩의 경우 디버깅 전용 커플 핀은 그리 큰 문제가 아닙니다. 요즘에는 디버깅을 위해 RealIce를 주로 사용합니다. ICD2보다 훨씬 안정적이고 덜 벗겨지지 않습니다. 당신은 그것과 함께 사는 법을 배웁니다.