Những tập tin phần sụn nào cần thiết cho lập trình PCBA?

Tổng quan

Tệp chương trình cơ sở có thể hoàn toàn hợp lệ và vẫn chưa sẵn sàng để sản xuất.

Để lập trình chương trình cơ sở trên cụm PCB, nhóm EMS cần có hình ảnh được phát hành, thiết bị đích chính xác, bản sửa đổi bo mạch mà nó áp dụng, giao diện lập trình, mọi địa chỉ bộ nhớ hoặc cấu hình thiết bị cần thiết và cách xác định để xác minh kết quả. Các sản phẩm cũng yêu cầu số sê-ri, địa chỉ MAC, giá trị hiệu chuẩn hoặc thông tin xác thực bảo mật cần có hướng dẫn xử lý bổ sung.

Việc kiểm tra sản xuất hữu ích rất đơn giản:

Kỹ thuật viên không viết chương trình cơ sở có thể lập trình bảng mạch chính xác theo hướng dẫn đã phát hành không?

Nếu không, phần mềm có thể đã hoàn thành từ quan điểm phát triển, nhưng việc chuyển giao sản xuất thì không.

Đặt bản phát hành lập trình trên một trang

Hình ảnh phần sụn chỉ là một phần của quá trình chuyển giao.

Đối với nhiều dự án, tài liệu đi kèm hữu ích nhất là một bản phát hành chương trình ngắn cho biết những gì đã được phê duyệt và cách sử dụng nó.

Việc khách hàng gọi đây là hướng dẫn lập trình, ghi chú phát hành, hướng dẫn sản xuất hay hướng dẫn công việc được kiểm soát không quan trọng. Phần quan trọng là người vận hành không phải xây dựng lại thiết lập từ các chuỗi email, ghi chú phát triển cũ và tên tệp.

Một tờ phát hành thực tế có thể bao gồm:

Một bo mạch MCU đơn giản có thể chỉ cần một vài vật dụng như vậy. Một sản phẩm có nhiều thiết bị có thể lập trình, nhiều biến thể phần sụn, số nhận dạng duy nhất hoặc chức năng bảo mật sẽ cần nhiều hơn thế.

Bảng phát hành giữ cho các quyết định kỹ thuật nằm ngoài tầm tay của người vận hành. Vào thời điểm bo mạch đạt đến giai đoạn lập trình, hình ảnh, thiết lập và quy tắc xác minh đã được phê duyệt phải rõ ràng.

Định dạng tệp không quan trọng bằng một phương pháp lập trình rõ ràng

HEX và BIN là phổ biến, nhưng cả hai đều không phải là câu trả lời đúng cho mọi sản phẩm.

Quy trình lập trình sản xuất cũng có thể sử dụng:

• ELF hoặc các định dạng thực thi có liên quan;
• bản ghi Motorola S{0}};
• các tệp lập trình cụ thể của nhà cung cấp-;
• gói cấu hình cụ thể của thiết bị-.

BIN thô thường cần một địa chỉ đích được xác định riêng. Các định dạng mang địa chỉ-có thể mang nhiều thông tin đó hơn trong tệp. Việc sử dụng bản ghi ELF, HEX, BIN, S{3}} hay định dạng khác tùy thuộc vào thiết bị đích và thiết lập lập trình được phê duyệt.

Trên sàn sản xuất, quy tắc đơn giản hơn:

Sử dụng định dạng được hỗ trợ bởi thiết lập lập trình đã được phê duyệt và ghi lại mọi thứ mà bản thân tệp không xác định.

Nếu phạm vi EMS bị giới hạn ở việc lập trình hình ảnh sản xuất đã được phê duyệt thì mã nguồn thường không cần thiết. Mã nguồn, dự án IDE và môi trường xây dựng trở nên phù hợp khi biên dịch, gỡ lỗi, sửa đổi chương trình cơ sở hoặc tạo hình ảnh-sản xuất là một phần trong phạm vi đã thỏa thuận.

Việc gửi toàn bộ kho lưu trữ vẫn không cho quá trình sản xuất biết bản dựng nào được phê duyệt.

Truy cập lập trình cũng là một quyết định về phần cứng

Để lập trình trong hệ thống, gói phần mềm chỉ là một nửa quá trình thiết lập.

Trạm sản xuất cũng cần quyền truy cập vật lý và điện vào thiết bị mục tiêu.

Tùy thuộc vào sản phẩm, điều đó có thể thông qua:

• SWD;
• JTAG;
• UART hoặc giao diện bộ nạp khởi động khác;
• DFU USB;
• SPI;
• một đầu nối lập trình chuyên dụng;
• lịch thi đấu-điểm kiểm tra có thể truy cập được;
• một giao diện cụ thể của thiết bị-khác.

Hướng dẫn lập trình cũng có thể cần xác định tình trạng nguồn điện của bo mạch, đầu nối hoặc sơ đồ chân điểm{0}}kiểm tra, trạng thái khởi động bắt buộc, bộ điều hợp lập trình, hành vi đặt lại và trình tự xóa/chương trình/xác minh dự kiến.

Những chi tiết này được giải quyết tốt nhất trước khi các bo mạch được lắp ráp đến trạm lập trình.

Không thể khắc phục tín hiệu SWD không thể truy cập bằng cách gửi tệp HEX tốt hơn.

Đối với các sản phẩm phụ thuộc vào quyền truy cập thiết bị cố định hoặc điểm kiểm tra lập trình, tính sẵn sàng lập trình một phần là vấn đề về DFT chứ không chỉ là chuyển giao phần mềm.

 

Giữ bản sửa đổi phần sụn và bản sửa đổi bảng mạch cùng nhau

Các tệp có tên mới nhất.hex hoặc Final_new_v2.bin có thể hoàn toàn dễ hiểu đối với người tạo ra chúng. Họ là những người kiểm soát sản xuất kém.

Sản xuất cần một cách đáng tin cậy để phân biệt bản phát hành đã được phê duyệt với:

• một phiên bản lỗi thời;
• một công trình kỹ thuật;
• một hình ảnh-chỉ thử nghiệm;
• một biến thể sản phẩm khác.

Tùy thuộc vào hệ thống kiểm soát tài liệu-của khách hàng, thông tin nhận dạng được phát hành có thể bao gồm bản sửa đổi chương trình cơ sở, tên tệp được kiểm soát, ngày phát hành, bản sửa đổi bảng hiện hành, tham chiếu phê duyệt của khách hàng, kích thước tệp hoặc tổng kiểm tra/băm.

Sản xuất không cần một sơ đồ đặt tên hoặc tổng kiểm tra chung. Cần có một cách đáng tin cậy để phân biệt bản dựng đã phát hành với mọi thứ khác trong thư mục.

Điều này càng trở nên quan trọng hơn khi một nền tảng phần cứng hỗ trợ nhiều biến thể phần mềm. Các bảng có thể trông giống hệt nhau trong khi thành phẩm thì không.

 

Khi lập trình bao gồm đơn vị-Dữ liệu cụ thể

Đối với nhiều sản phẩm, mỗi bo mạch đều nhận được cùng một hình ảnh chương trình cơ sở.

Các sản phẩm khác cũng cần thông tin-cụ thể về đơn vị như:

• số sê-ri;
• Địa chỉ MAC;
• ID sản phẩm;
• hệ số hiệu chuẩn;
• cấu hình khu vực;
• cài đặt cụ thể của khách hàng;
• thông tin xác thực của thiết bị.

Tại thời điểm đó, chương trình cơ sở chung và dữ liệu trên mỗi đơn vị là hai luồng dữ liệu khác nhau.

Quá trình sản xuất phải biết các giá trị duy nhất đến từ đâu, chúng được viết ở đâu, mỗi giá trị được liên kết với bảng vật lý chính xác như thế nào và cách ngăn chặn việc gán trùng lặp.

Một chi tiết rất dễ bị bỏ qua: khi nào một giá trị duy nhất được coi là được tiêu thụ?

Số sê-ri hoặc địa chỉ MAC có thể được coi là sử dụng khi nó được chỉ định, khi lập trình thành công hoặc chỉ sau khi thiết bị vượt qua bài kiểm tra bắt buộc. Không có quy tắc duy nhất cho mọi sản phẩm nhưng cần có quy tắc được thống nhất trước khi bắt đầu xây dựng.

Điều tương tự cũng áp dụng cho các đơn vị bị lỗi. Nhóm cần biết liệu giá trị được chỉ định có thể được sử dụng lại hay không, có thể bị loại bỏ hay vẫn được liên kết với bảng bị lỗi để truy xuất nguồn gốc.

 

Thẻ lập trình không phải là thẻ FCT

Xác minh lập trình và Kiểm tra chức năng có thể diễn ra gần nhau trong quy trình sản xuất nhưng chúng trả lời các câu hỏi khác nhau.

Xác minh lập trình

Xác minh lập trình hỏi:

Dữ liệu dự định có được ghi chính xác theo phương pháp lập trình đã được phê duyệt không?

Tùy thuộc vào thiết bị và cách thiết lập, điều đó có thể liên quan đến chức năng xác minh của lập trình viên, so sánh đọc lại khi được phép, CRC, xác minh cấu hình hoặc phương pháp được phê duyệt khác.

Kiểm tra chức năng

Kiểm tra chức năng hỏi:

Tổ hợp PCB được cấp nguồn và lập trình có thực hiện các chức năng mà sản phẩm yêu cầu không?

Tùy thuộc vào dự án, điều này có thể bao gồm:

• hành vi{0}}tăng sức mạnh;
• giao tiếp;
• phản hồi đầu vào/đầu ra;
• đầu vào cảm biến;
• đầu ra rơle hoặc bộ truyền động;
• rút thăm hiện tại;
• điều kiện hoạt động do khách hàng- xác định.

Lập trình viên hiển thị PASS sẽ không tự động được coi là bằng chứng cho thấy tổ hợp PCB đã vượt qua FCT.

Đối với các dự án yêu cầu tải chương trình cơ sở phải được phối hợp với xác thực cấp độ bo mạch-, STHLKiểm tra và kiểm trakhả năng cung cấp đường dẫn dịch vụ có liên quan.

 

Hai tình huống cần hướng dẫn thêm

Hầu hết các công việc lập trình không cần một quy trình cung cấp phức tạp. Có hai tình huống đáng được chú ý nhiều hơn khi áp dụng.

Phần mềm thử nghiệm và phần mềm sản xuất

Một số sản phẩm sử dụng chương trình cơ sở chẩn đoán trong quá trình sản xuất và một bản phát hành chương trình cơ sở khác khi vận chuyển.

Nếu vậy, nhà sản xuất cần biết hình ảnh nào được áp dụng ở mỗi giai đoạn, thời điểm hình ảnh thử nghiệm được thay thế, cách xác nhận bản phát hành cuối cùng và liệu sau đó có cần kiểm tra chức năng khác hay không.

Nếu không, bo mạch có thể vượt qua quá trình chẩn đoán trong quá trình sản xuất nhưng vẫn rời khỏi quá trình sản xuất với cài đặt sai phần sụn.

Không phải mọi sản phẩm đều cần phần mềm thử nghiệm riêng biệt. Quy trình phải tuân theo sản phẩm thực tế.

Cung cấp an toàn

Một số thiết bị-hỗ trợ bảo mật yêu cầu hình ảnh đã được ký hoặc mã hóa, cài đặt khởi động-bảo mật, cấu hình OTP/eFuse, khóa, chứng chỉ hoặc dữ liệu cấp phép được kiểm soát khác.

Khi áp dụng các yêu cầu này, nhà cung cấp OEM và EMS phải thống nhất ai sở hữu dữ liệu nhạy cảm, hoạt động sản xuất nào được phép thực hiện và cách phê duyệt các cài đặt không thể đảo ngược.

Không nên xử lý các mục này như các tệp đính kèm chương trình cơ sở thông thường.

Điều gì sẽ xảy ra nếu phần sụn thay đổi sau khi bắt đầu lập trình?

Hình ảnh chương trình cơ sở mới có thể được đặt vào thư mục dùng chung gần như ngay lập tức.

Các bảng đã có trên sàn sản xuất không thay đổi theo nó.

Nếu có bản phát hành mới sau khi chương trình đã bắt đầu, nhóm cần có cách xử lý rõ ràng về:

• các đơn vị đã được lập trình với phiên bản trước đó;
• các đơn vị đã được thử nghiệm;
• các đơn vị chờ lập trình;
• liệu có cần lập trình lại hay không;
• liệu việc kiểm tra chức năng có bị ảnh hưởng hay không;
• liệu có cần phải kiểm tra lại hay không;
• nơi ranh giới sửa đổi nằm trong lô sản xuất.

Mức độ xem xét nên theo sự thay đổi.

Chuỗi hiển thị đã sửa và thay đổi về hành vi điều khiển nguồn-không có cùng rủi ro trong sản xuất. Nhưng không nên giới thiệu đơn giản bằng cách thay thế một tập tin và yêu cầu dòng tiếp tục.

Đây là lúc việc kiểm soát phiên bản không còn là thủ tục giấy tờ mà trở thành kiểm soát sản xuất.

 

Kiểm tra ngắn-trước khi sản xuất

Trước khi đơn vị sản xuất đầu tiên được lập trình, người mua và nhóm EMS phải trả lời:

• Hình ảnh hoặc hình ảnh chính xác nào được phát hành?
• Thiết bị lập trình nào nhận được từng hình ảnh?
• Bản sửa đổi bo mạch nào được phê duyệt cho phần sụn?
• Có cần địa chỉ tải hoặc bản đồ bộ nhớ không?
• Các byte tùy chọn, cầu chì hoặc dữ liệu cấu hình được nhúng hay tách biệt?
• Giao diện lập trình nào được sử dụng?
• Quyền truy cập lập trình cần thiết có sẵn trên bo mạch không?
• Bảng được cấp nguồn như thế nào trong quá trình lập trình?
• Lập trình viên, dự án hoặc thiết lập đã được phê duyệt nào được áp dụng?
• Có cần-dữ liệu cụ thể về đơn vị không?
• Điều gì chứng tỏ rằng hoạt động lập trình đã trôi qua?
• Kiểm tra chức năng hoặc kiểm tra khác có cần thiết sau đó không?
• Dự án có sử dụng chương trình cơ sở thử nghiệm, cung cấp bảo mật hoặc quy trình làm việc đặc biệt khác không?

Nếu những câu trả lời đó rõ ràng thì bản thân gói lập trình có thể chỉ chứa một vài tệp.

Nếu không, việc thêm nhiều tệp hơn hiếm khi giải quyết được vấn đề chuyển giao.

 

STHL hỗ trợ lập trình chương trình cơ sở như thế nào trong sản xuất PCBA

Công ty TNHH Công nghệ STHL Thâm Quyến (STHL) hỗ trợ lập trình MCU, FPGA và EEPROM như một phần của các dự án lắp ráp PCB hiện hành. Việc lập trình có thể được phối hợp với thử nghiệm chức năng và các yêu cầu-dự án cụ thể về truy xuất nguồn gốc nếu cần.

Đối với một bản dựng riêng lẻ, quá trình đánh giá lập trình có thể bao gồm hình ảnh đã phát hành, thiết bị mục tiêu, bản sửa đổi bảng mạch, quyền truy cập lập trình, cấu hình thiết bị bắt buộc, phương pháp xác minh và bất kỳ dữ liệu cụ thể nào về đơn vị{0}}do khách hàng cung cấp.

Lập trình viên, thiết bị cố định hoặc cáp, yêu cầu bảo mật, quyền sở hữu chương trình cơ sở và hồ sơ sản xuất bắt buộc phải được thống nhất cho dự án cụ thể thay vì giả định từ một tuyên bố năng lực chung.

Phần kết luận

Các yêu cầu lập trình phần mềm cơ sở PCBA quan trọng nhất không được xác định bằng việc khách hàng có gửi tệp HEX, BIN, ELF hay tệp được hỗ trợ khác hay không.

Quá trình bàn giao-sẵn sàng sản xuất sẽ giúp nhóm sản xuất trả lời bốn câu hỏi cơ bản:

• Dữ liệu nào nên được lập trình?
• Nó thuộc về bản sửa đổi thiết bị và bo mạch nào?
• Chương trình sản xuất nên được kiểm chứng như thế nào?
• Điều gì phải xảy ra trước khi quá trình lắp ráp PCB chuyển sang bước sản xuất tiếp theo?

Đối với một bảng MCU đơn giản, những câu trả lời đó có thể nằm gọn trên một trang. Một sản phẩm có nhiều thiết bị có thể lập trình, dữ liệu duy nhất, nhiều biến thể chương trình cơ sở hoặc yêu cầu bảo mật đương nhiên sẽ cần nhiều chi tiết hơn.

Firmware sẵn sàng được sản xuất khi đội ngũ sản xuất đủ năng lực có thể lặp lại quy trình lập trình đã được phê duyệt từ thông tin được công bố, thay vì dựa vào kiến ​​thức chỉ tồn tại trong đầu nhà phát triển.

Đối với bản dựng yêu cầu lập trình chương trình cơ sở, hãy bao gồm các tệp lập trình có sẵn và hướng dẫn cùng với tệp BOM, Gerber, thông tin lắp ráp, số lượng và các yêu cầu kiểm tra khi bạngửi chi tiết dự án PCBA của bạn.

Đối với các câu hỏi-cụ thể về lập trình, hãy liên hệ với STHL tạiinfo@pcba-china.com.