전기 시스템 테스트를 지원하도록 임베디드 시스템을 설계 할 수 있습니까?

백그라운드
데스크톱 컴퓨터 및 랩톱을 이중 부팅으로 구성 할 수 있습니다. 예 : 동일한 컴퓨터 / 노트북의 우분투와 창.

질문 : 비슷한 개념을 임베디드 시스템에 적용 할 수 있습니까? 그렇다면 전기 제조 테스트에 큰 도움이 될 수 있습니다. 전기 제조 테스트는 높은 처리량에 달려 있습니다. 따라서 완전한 예를 들어 임베디드 Linux 시스템을 부팅하는 것은 효율적이지 않으며 전기 제조 테스트 환경에서는 거의 수행되지 않습니다. 따라서 일부 유형의 전자 스위치 / 신호 (테스터가 제공 할 수 있음)를 사용하면 보드 테스트를 가능하게하는 프로세서에 이미 프로그래밍되어있는 최소 소프트웨어 세트를 매우 빠르게로드 할 수 있습니다. 예를 들어 외부 결정 (XT)이 올 바르고 작동하는지 확인하십시오.

@ouflak의 의견에 따르면 : 특정 NEC V850 마이크로 컨트롤러 기반 응용 프로그램을 알고 있는데, 모든 마이크로 컨트롤러는 PCB 보드에 배치되기 전에 갱 프로그래머를 사용하여 프로그래밍되었습니다. 전기 제조 테스트 중에 테스터는 마이크로 컨트롤러가 매우 작은 프로그램을로드하고 CAN 버스를 통해 PCB 보드와 통신하여 테스트 목적으로 임베디드 시스템의 섹션을 활성화하도록합니다.

마찬가지로 Android 아키텍처 / 디자인을 실행하는 PCB와 같은 비글 본 블랙을 전기 제조 테스트 전용 플래시 섹션에서 부팅하도록 수정하는 방법을 조사하고 싶습니다. 이미 완료된 공급 업체 TI로서 TI Sitara 용 그래픽 컨트롤러를로드하고 테스트하는 것은이 기능을 수행하지 않습니다. PCB 제조 공정을 테스트하고 검증하기 만하면됩니다.

의료 기기의 소형 8 비트 마이크로 컨트롤러와 비슷한 작업을 수행했습니다. 공장에는 두 가지 펌웨어가 있습니다.

먼저 공장 테스트 펌웨어가 다운로드됩니다. 하위 어셈블리를 실행하고 공장 테스트 장비와 통신하기위한 알고리즘이 있습니다. 공장 테스트가 수행됩니다.

둘째, 필드 펌웨어가 다운로드됩니다. 필드 펌웨어에는 자체 필드 자체 테스트가 있습니다 (범위가 작고 공장 테스트 장비를 사용하지 않음). 현장 자체 테스트도 통과하면 부분 조립품이 양호하다는 결론을 내립니다.

이를 통해 기본 펌웨어에서 공장 테스트 코드를 제거 할 수있었습니다. 따라서 현장 펌웨어를보다 쉽게 ​​개발할 수있었습니다. 일부 테스트 모드가 최종 사용자에게 닥칠 수있는 원격 가능성에 대해 걱정할 필요가 없었습니다. 메모리 사용량도 줄었습니다.

당신이 묻는 것은 매우 다양한 형태로 이루어집니다. 임베디드 마이크로 컨트롤러의 경우 일반적으로 다음 두 가지 형식 중 하나를 사용합니다.

1. 두 가지 별도의 펌웨어 빌드가 있습니다. 하나는 제조 테스트 용이고 다른 하나는 정상 작동 용입니다. 테스트 프로세스는 첫 번째 펌웨어를 장치에로드하고 테스트, 교정 등을 수행 한 다음 두 번째 펌웨어를 장치에로드합니다. 여기에는 첫 번째 단계에서 수행 한 교정 측정을 기반으로 생산 펌웨어의 일부 값을 사용자 정의하는 것이 포함될 수 있습니다.

2. 프로덕션 펌웨어에 제조 테스트 기능을 추가하십시오. 이것은 내 경험에서 더 일반적입니다.

   종종 장치는 어떤 방식으로 호스트 컴퓨터와 통신해야합니다. 이것은 일반적으로 명령 세트가 구현되었음을 의미합니다. 이 방법을 사용하면 제조 테스트 중에 만 사용되는 몇 가지 추가 명령이 추가됩니다. 최종 사용자가 직접 명령을 보내지 않는 경우 (예 : 호스트에서 미리 준비된 앱 사용) 일반적으로 프로토콜을 게시하지 않고 원하는 명령을 추가 할 수 있습니다. 사용자가 장치와 직접 통신하는 경우 제조의 마지막 단계는 추가 명령 또는 기능을 비활성화하는 것일 수 있습니다. 예를 들어, 일련 번호가 1의 프로그래밍되지 않은 값일 때만 추가 기능을 사용할 수있는 직렬화 된 장치에서이 트릭을 몇 번 사용했습니다. 제조의 마지막 단계는 장치가 모든 측정 사양을 충족하는 경우 새 일련 번호를 할당하고 장치에 프로그래밍하는 것입니다.

   생산 비용을 너무 많이 들이고 싶지는 않지만 추가 기능이 모두 펌웨어 일 필요는 없습니다. 엔드 유닛이 통신 인터페이스없이 독립형이지만 내장 UART를 사용하여 명령 / 응답 인터페이스를 구현 한 경우도 있습니다. 이 경우 UART 신호는 보드 하단의 베어 패드를 통해 사용할 수 있습니다. 테스트 픽스처의 포고 핀이 연결되어 명령 세트에 액세스 할 수 있습니다. 최종 사용자는이 기능에 대해 전혀 알지 못하며 보드 하단에 두 개의 둥근 패드 만 보입니다. 이 경우에는 보안 문제가 없으므로 사용자 원숭이와 함께 매우 드물게 발생하는 경우 (내가 아는 한 발생하지 않았 음) 장치를 "깨뜨릴"수 있습니다. 물론 그것은 당신이 보드의 다른 부분으로 원숭이를 놀리는 것과 다르지 않습니다.

   다른 경우에는 "테스트 모드"에 액세스하는 숨겨진 비밀 방법이 있습니다. 예를 들어, 자동차의 GPS 장치는 전원을 켤 때 특정 버튼을 누르고 있으면 이상한 일을합니다. 일반적으로 타이밍 제약 조건 내에서 버튼을 클릭하기 어려운 특정 시퀀스가 ​​필요한 장치를 만들었습니다.

가능하지만 전체 이미지와 작은 테스트 이미지를 모두 포함 할 수있는 충분한 저장 공간이 있어야합니다. 종종 부트로 더라고하는 초기 프로그램이 실행됩니다. 부트 로더의 작업은 기본 응용 프로그램을 설정 및 시작하고 종종 펌웨어 업데이트를위한 복구 경로를 제공하는 것입니다.

부트 로더가 I / O를 확인하고이를 사용하여로드 할 이미지를 선택하는 것은 어렵지 않으며 일부 제품에서 수행됩니다.

실제 예는 다음과 같습니다. 휴대 전화에서 "fastboot"라고하는 초기 부분은 기본 Android 시스템을로드 할 버튼을 확인하는 버튼입니다 (볼륨을 줄입니다. 현재 기억할 수는 없습니다). 아무것도 누르지 않았거나 복구 이미지가 눌 렸을 때 복구 이미지는 매우 빠르게 시작되지만 기능이 제한됩니다. 파일 시스템에 액세스 할 수 있으며 거기에 일부 진단 테스트 옵션을 넣는 것은 쉽지 않습니다.

다른 임베디드 시스템에서는 모든 스토리지 용량이 중요 할 수 있으며 설계자는 필요한 기능 세트를 맞추는 것에 대해 진단 및 복구를 수행해야합니다.

부록 : 원본 답변에는 이미지를 선택하기 위해 버튼 누르기 또는 이와 유사한 것을 감지하는 방법에 대한 설명이 필요합니다.

대부분의 경우 부트 로더는 시스템의 나머지 부분 (보통 C 또는 어셈블리)과 유사한 코드로 작성됩니다. 따라서 일반 소프트웨어와 동일한 수준의 하드웨어 액세스 권한을 갖습니다. 대부분의 경우 버튼 또는 이와 유사한 버튼은 프로세서에서 직접 GPIO로 읽거나 외부 GPIO 확장기 (예 : SPI 또는 I2C 버스)로 읽는 간단한 버스를 통해 읽을 수있는 간단한 I / O 라인입니다. 부트 로더 이미지에서 많은 공간을 차지하지 않습니다.

복구 또는 현장 테스트와 달리 제조 테스트를 위해 명시 적으로 설계된 것은 사용자가 액세스 할 수있는 버튼으로 구현할 가능성이 적습니다. 저렴하지만 실수로 쉽게 트립되지 않는 방법은 PCB에 납땜 패드가 결합되어 테스트를 시작하기 위해 함께 단락 될 수 있습니다 (단순 스크류 드라이버 사용부터 손톱 모양의 스타일 리그로 구현하는 것까지).