PCBA 프로그래밍에는 어떤 펌웨어 파일이 필요합니까?

개요

펌웨어 파일은 완벽하게 유효하지만 아직 생산 준비가 되지 않았을 수 있습니다.

PCB 어셈블리의 펌웨어 프로그래밍을 위해 EMS 팀에는 공개된 이미지, 정확한 대상 장치, 적용되는 보드 개정판, 프로그래밍 인터페이스, 필요한 메모리 주소 또는 장치 구성, 결과를 확인하기 위한 정의된 방법이 필요합니다. 일련 번호, MAC 주소, 교정 값 또는 보안 자격 증명도 필요한 제품에는 추가 취급 지침이 필요합니다.

유용한 생산 확인은 간단합니다.

펌웨어를 작성하지 않은 기술자가 공개된 지침에 따라 보드를 올바르게 프로그래밍할 수 있습니까?

그렇지 않은 경우 소프트웨어는 개발 관점에서 완성될 수 있지만 제조 핸드오프는 그렇지 않습니다.

프로그래밍 릴리스를 한 페이지에 담기

펌웨어 이미지는 핸드오프의 한 부분일 뿐입니다.

많은 프로젝트에서 가장 유용한 동반 문서는 승인된 내용과 사용 방법을 프로덕션에 알려주는 짧은 프로그래밍 릴리스 시트입니다.

고객이 이를 프로그래밍 지침, 릴리스 노트, 제조 지침 또는 통제된 작업 지침이라고 부르는지는 중요하지 않습니다. 중요한 부분은 운영자가 이메일 스레드, 이전 개발 노트 및 파일 이름에서 설정을 재구성할 필요가 없다는 것입니다.

실제 릴리스 시트에는 다음이 포함될 수 있습니다.

간단한 MCU 보드에는 이러한 항목 중 몇 가지만 필요할 수 있습니다. 여러 프로그래밍 가능 장치, 다양한 펌웨어 변형, 고유 식별자 또는 보안 기능을 갖춘 제품에는 더 많은 것이 필요합니다.

릴리스 시트는 엔지니어링 결정을 운영자의 손에 맡기지 않습니다. 보드가 프로그래밍에 도달할 때쯤에는 승인된 이미지, 설정 및 검증 규칙이 이미 명확해졌을 것입니다.

파일 형식은 명확한 프로그래밍 방법보다 중요하지 않습니다.

HEX와 BIN은 일반적이지만 모든 제품에 자동으로 정답이 되는 것은 아닙니다.

프로덕션 프로그래밍 워크플로우에서는 다음을 사용할 수도 있습니다.

• ELF 또는 관련 실행 파일 형식
• Motorola S-기록;
• 공급업체-특정 프로그래밍 파일
• 기기-별 구성 패키지.

원시 BIN에는 일반적으로 별도로 정의된 대상 주소가 필요합니다. 주소-포함 형식은 파일 내에서 더 많은 정보를 전달할 수 있습니다. ELF, HEX, BIN, S-레코드 또는 다른 형식이 사용되는지 여부는 대상 장치 및 승인된 프로그래밍 설정에 따라 다릅니다.

생산 현장에서는 규칙이 더 간단합니다.

승인된 프로그래밍 설정에서 지원되는 형식을 사용하고 파일 자체에서 정의하지 않은 모든 내용을 문서화하세요.

EMS 범위가 승인된 프로덕션 이미지 프로그래밍으로 제한되는 경우 일반적으로 소스 코드는 필요하지 않습니다. 컴파일, 디버깅, 펌웨어 수정 또는 프로덕션-이미지 생성이 합의된 범위의 일부일 때 소스 코드, IDE 프로젝트 및 빌드 환경이 관련됩니다.

전체 저장소를 보내도 어떤 빌드가 승인되었는지 프로덕션에 아직 알 수 없습니다.

프로그래밍 액세스도 하드웨어 결정입니다

시스템 내 프로그래밍의 경우-소프트웨어 패키지는 설정의 절반에 불과합니다.

또한 생산 스테이션에서는 대상 장치에 대한 물리적, 전기적 액세스가 필요합니다.

제품에 따라 다음을 통해 이루어질 수 있습니다.

• SWD;
• JTAG;
• UART 또는 다른 부트로더 인터페이스
• USB DFU;
• SPI;
• 전용 프로그래밍 커넥터;
• 설비-접근 가능한 테스트 지점;
• 다른 기기-특정 인터페이스.

프로그래밍 명령은 보드 전원 상태, 커넥터 또는 테스트{0}}핀아웃, 필요한 부팅 상태, 프로그래밍 어댑터, 재설정 동작, 예상되는 삭제/프로그램/검증 순서를 정의해야 할 수도 있습니다.

이러한 세부 사항은 조립된 보드가 프로그래밍 스테이션에 도착하기 전에 가장 잘 해결됩니다.

액세스할 수 없는 SWD 신호는 더 나은 HEX 파일을 전송하여 수정할 수 없습니다.

고정 장치 액세스 또는 프로그래밍 테스트 포인트에 의존하는 제품의 경우 프로그래밍 준비 상태는 소프트웨어 핸드오프가 아닌 부분적으로 DFT 문제입니다.

 

펌웨어 개정판과 보드 개정판을 함께 유지

최신.hex 또는 final_new_v2.bin이라는 파일은 해당 파일을 만든 사람이 완벽하게 이해할 수 있습니다. 그들은 열악한 생산 관리입니다.

제조에는 승인된 릴리스를 다음과 구별할 수 있는 안정적인 방법이 필요합니다.

• 구식 버전;
• 엔지니어링 빌드;
• 테스트{0}}전용 이미지
• 다른 제품 변형.

고객의 문서{0} 제어 시스템에 따라 릴리스된 ID에는 펌웨어 개정판, 제어된 파일 이름, 릴리스 날짜, 해당 보드 개정판, 고객 승인 참조, 파일 크기 또는 체크섬/해시가 포함될 수 있습니다.

프로덕션에는 하나의 범용 이름 지정이나 체크섬 체계가 필요하지 않습니다. 폴더의 다른 모든 항목과 릴리스된 빌드를 구분하는 안정적인 방법이 필요합니다.

이는 하나의 하드웨어 플랫폼이 여러 소프트웨어 변형을 지원할 때 더욱 중요해집니다. 보드는 동일하게 보일 수 있지만 완제품은 그렇지 않을 수 있습니다.

 

프로그래밍에 단위-특정 데이터가 포함되는 경우

많은 제품의 경우 모든 보드는 동일한 펌웨어 이미지를 수신합니다.

다른 제품에도 다음과 같은{0}}단위별 정보가 필요합니다.

• 일련번호;
• MAC 주소
• 제품 ID
• 교정 계수;
• 지역 구성;
• 고객별-설정;
• 장치 자격 증명.

이 시점에서 공통 펌웨어와{0}단위별 데이터는 서로 다른 두 가지 데이터 흐름입니다.

생산팀에서는 고유한 값이 어디서 왔는지, 어디에 기록되었는지, 각 값이 올바른 실제 보드와 어떻게 연관되어 있는지, 중복 할당을 방지하는 방법을 알아야 합니다.

한 가지 세부 사항은 간과하기 쉽습니다. 고유한 값은 언제 소비되는 것으로 간주됩니까?

일련 번호 또는 MAC 주소는 할당될 때, 프로그래밍이 성공할 때 또는 장치가 필수 테스트를 통과한 후에만 사용되는 것으로 간주될 수 있습니다. 모든 제품에 대한 단일 규칙은 없지만 빌드가 시작되기 전에 합의된 규칙이 있어야 합니다.

실패한 장치에도 동일하게 적용됩니다. 팀은 할당된 값을 재사용할 수 있는지, 폐기해야 하는지, 추적성을 위해 실패한 보드에 계속 연결되어 있는지 알아야 합니다.

 

프로그래밍 패스는 FCT 패스가 아닙니다.

프로그래밍 검증과 기능 테스트는 제조 흐름에서 밀접하게 함께 발생할 수 있지만 서로 다른 질문에 답합니다.

프로그래밍 검증

프로그래밍 검증은 다음을 요구합니다:

승인된 프로그래밍 방식에 따라 의도한 데이터가 올바르게 작성되었는가?

장치 및 설정에 따라 프로그래머의 확인 기능, 허용되는 경우 다시 읽기 비교, CRC, 구성 확인 또는 기타 승인된 방법이 포함될 수 있습니다.

기능 테스트

기능 테스트는 다음을 요구합니다.

전원이 공급되고 프로그래밍된 PCB 어셈블리가 제품에 필요한 기능을 수행합니까?

프로젝트에 따라 여기에는 다음이 포함될 수 있습니다.

• 전원-켜기 동작;
• 의사소통;
• 입출력 응답;
• 센서 입력;
• 릴레이 또는 액추에이터 출력;
• 현재 추첨;
• 고객이-정의한 작동 조건.

PASS를 표시하는 프로그래머는 자동으로 PCB 어셈블리가 FCT를 통과했다는 증거로 처리되어서는 안 됩니다.

보드{0}}레벨 검증과 조정하기 위해 펌웨어 로딩이 필요한 프로젝트의 경우 STHL의테스트 및 검사기능은 관련 서비스 경로를 제공합니다.

 

추가 지침이 필요한 두 가지 상황

대부분의 프로그래밍 작업에는 정교한 프로비저닝 프로세스가 필요하지 않습니다. 두 가지 상황이 적용될 때 특별히 주의를 기울일 필요가 있습니다.

테스트 펌웨어 및 프로덕션 펌웨어

일부 제품은 제조 중에는 진단 펌웨어를 사용하고 배송에는 다른 펌웨어 릴리스를 사용합니다.

그렇다면 프로덕션에서는 각 단계에서 어떤 이미지가 적용되는지, 테스트 이미지가 언제 교체되는지, 최종 릴리스가 어떻게 확인되는지, 이후에 또 다른 기능 확인이 필요한지 여부를 알아야 합니다.

그렇지 않으면 보드가 제조 진단을 통과하고 잘못된 펌웨어가 설치된 채로 생산 상태를 유지할 수 있습니다.

모든 제품에 별도의 테스트 펌웨어가 필요한 것은 아닙니다. 프로세스는 실제 제품을 따라야 합니다.

보안 프로비저닝

일부 보안{0}}지원 기기에는 서명되거나 암호화된 이미지, 보안{1}}부팅 설정, OTP/eFuse 구성, 키, 인증서 또는 기타 제어되는 프로비저닝 데이터가 필요합니다.

이러한 요구 사항이 적용되는 경우 OEM 및 EMS 제공업체는 민감한 데이터의 소유자, 생산 작업 수행 권한, 되돌릴 수 없는 설정 승인 방법에 동의해야 합니다.

이러한 항목은 일반 펌웨어 첨부 파일처럼 처리하면 안 됩니다.

프로그래밍이 시작된 후 펌웨어가 변경되면 어떻게 되나요?

새 펌웨어 이미지는 거의 즉시 공유 폴더에 배치될 수 있습니다.

이미 생산 현장에 있는 보드는 이에 따라 변경되지 않습니다.

프로그래밍이 시작된 후 새 릴리스가 출시되면 팀은 다음에 대한 명확한 처분이 필요합니다.

• 이전 버전으로 이미 프로그래밍된 장치;
• 이미 테스트된 장치;
• 프로그래밍을 기다리는 장치;
• 재프로그래밍이 필요한지 여부;
• 기능 테스트가 영향을 받는지 여부
• 재시험이 필요한지 여부
• 개정 경계는 생산 로트 내에 위치합니다.

검토 수준은 변경 사항을 따라야 합니다.

수정된 표시 문자열과 전원{0} 제어 동작 변경은 동일한 제조 위험을 수반하지 않습니다. 그러나 단순히 파일을 교체하고 줄을 계속하라고 지시하는 방식으로 두 가지 모두 도입해서는 안 됩니다.

버전 관리가 서류 작업이 아닌 생산 관리가 되는 곳입니다.

 

짧은 사전{0}}생산 점검

첫 번째 생산 단위를 프로그래밍하기 전에 구매자와 EMS 팀은 다음 사항에 답할 수 있어야 합니다.

• 정확한 이미지는 무엇입니까?
• 각 이미지를 수신하는 프로그래밍 가능 장치는 무엇입니까?
• 펌웨어가 승인된 보드 개정은 무엇입니까?
• 로드 주소나 메모리 맵이 필요합니까?
• 옵션 바이트, 퓨즈 또는 구성 데이터가 내장되어 있습니까, 아니면 별도로 있습니까?
• 어떤 프로그래밍 인터페이스가 사용됩니까?
• 보드에서 필요한 프로그래밍 액세스를 사용할 수 있습니까?
• 프로그래밍하는 동안 보드에 전원이 어떻게 공급됩니까?
• 어떤 프로그래머, 프로젝트 또는 승인된 설정이 적용됩니까?
• 단위{0}}별 데이터가 필요합니까?
• 프로그래밍 작업이 통과되었음을 증명하는 것은 무엇입니까?
• 나중에 기능 테스트나 또 다른 확인이 필요합니까?
• 프로젝트에서 테스트 펌웨어, 보안 프로비저닝 또는 기타 특수 워크플로우를 사용합니까?

이러한 대답이 명확하다면 프로그래밍 패키지 자체에는 몇 개의 파일만 포함될 수 있습니다.

그렇지 않은 경우 더 많은 파일을 추가해도 핸드오프가 해결되는 경우는 거의 없습니다.

 

STHL이 PCBA 제조 내에서 펌웨어 프로그래밍을 지원하는 방법

Shenzhen STHL Technology Co., Ltd.(STHL)는 해당 PCB 조립 프로젝트의 일부로 MCU, FPGA 및 EEPROM 프로그래밍을 지원합니다. 필요한 경우 기능 테스트 및 프로젝트별 추적성 요구사항에 맞춰 프로그래밍을 조정할 수 있습니다.-

개별 빌드의 경우 프로그래밍 검토에는 출시된 이미지, 대상 장치, 보드 개정, 프로그래밍 액세스, 필수 장치 구성, 확인 방법 및 고객이 제공한 장치{0}}별 데이터가 포함될 수 있습니다.

정확한 프로그래머, 고정 장치 또는 케이블, 보안 요구 사항, 펌웨어 소유권 및 필요한 생산 기록은 일반적인 기능 설명에서 가정하기보다는 특정 프로젝트에 대해 합의되어야 합니다.

결론

가장 중요한 PCBA 펌웨어 프로그래밍 요구 사항은 고객이 HEX, BIN, ELF 또는 다른 지원 파일을 보내는지 여부에 따라 정의되지 않습니다.

생산{0}}준비 완료를 통해 제조팀은 다음 네 가지 기본 질문에 답할 수 있어야 합니다.

• 어떤 데이터를 프로그래밍해야 합니까?
• 어떤 장치 및 보드 개정판에 속합니까?
• 생산 프로그램을 어떻게 작성하고 검증해야 합니까?
• PCB 어셈블리가 다음 생산 단계로 넘어가기 전에 어떤 일이 일어나야 합니까?

간단한 MCU 보드의 경우 해당 답변이 한 페이지에 들어갈 수 있습니다. 여러 프로그래밍 가능한 장치, 고유한 데이터, 다양한 펌웨어 변형 또는 보안 요구 사항이 있는 제품에는 당연히 더 자세한 정보가 필요합니다.

개발자의 머리 속에만 존재하는 지식에 의존하지 않고 자격을 갖춘 생산 팀이 공개된 정보에서 승인된 프로그래밍 프로세스를 반복할 수 있을 때 펌웨어 제조 준비가 완료된 것입니다.

펌웨어 프로그래밍이 필요한 빌드의 경우 BOM, Gerber 파일, 어셈블리 정보, 수량 및 테스트 요구 사항과 함께 사용 가능한 프로그래밍 파일 및 지침을 포함하십시오.PCBA 프로젝트 세부정보 제출.

프로그래밍{0}}에 관한 구체적인 질문은 다음 주소로 STHL에 문의하세요.info@pcba-china.com.