1. Vì sao CBT6 tồn tại

Dòng F103 được xây dựng quanh một die duy nhất có thể được cấu hình với các mật độ flash khác nhau. Đó là lý do C6T6, C8T6 và CBT6 dùng chung package, sơ đồ chân và bộ ngoại vi: khác biệt nằm ở bộ nhớ, không phải kiến trúc.

Đối với nhà thiết kế, đó là một món quà. Một bo mạch đã được đánh giá cho C8T6 chấp nhận CBT6 mà không cần thay đổi layout, và firmware biên dịch mà không cần thay đổi driver. Câu hỏi duy nhất là liệu bản đồ bộ nhớ có còn đúng hay không.

Đối với người mua, đây là quyết định về giá và khả năng cung ứng: linh kiện 128 KB đắt hơn một chút, nhưng loại bỏ rủi ro phải thiết kế lại lưu trữ lần thứ hai về sau.

2. Ba biến thể bộ nhớ

Lưu ý những gì không thay đổi: RAM vẫn ở mức 20 KB trên C8T6 và CBT6. Tăng gấp đôi flash không mang lại cho ứng dụng thêm stack, heap hay buffer. Nếu giới hạn là RAM, câu trả lời là một họ khác, chứ không phải một linh kiện flash lớn hơn.

C6T6 32 KB là sự đánh đổi ngược lại: rẻ nhất, nhưng chỉ khả thi cho một image cố định nhỏ. Chuyển từ 32 KB lên 128 KB là mức tăng gấp bốn lần và thường giải quyết ràng buộc một cách vĩnh viễn.

Những gì giữ nguyên

Pinout, package, tập ngoại vi, clock tree và giao diện debug không thay đổi trên C6T6, C8T6 và CBT6. Cùng một board, cùng một thạch anh, cùng một header SWD và cùng một mạch USB đều hoạt động với cả ba.

Đó là lý do việc nâng cấp thường được mô tả là "miễn phí". Công sức kỹ thuật là có thật nhưng có giới hạn: cập nhật linker script, xem lại partition table, chạy lại các bài kiểm thử chấp nhận. Không thay đổi schematic, không re-layout, không thêm driver mới.

Khác biệt ngoại vi duy nhất đáng kiểm tra là hình học trang của bộ điều khiển flash, vì kích thước trang quyết định cách EEPROM mô phỏng và bootloader xóa.

Trên thực tế, C8T6 và CBT6 thường có thể thay thế cho nhau ở cấp nhà phân phối, và việc chọn linh kiện phụ thuộc vào loại nào có sẵn tại thời điểm build. Chính sự linh hoạt đó là lý do để thiết kế partition table quanh 128 KB, để có thể dùng một trong hai mà không cần thay đổi firmware.

3. Khi 64 KB không còn đủ

Firmware tăng trưởng theo các bước có thể dự đoán được. Một dự án vừa vặn thoải mái ở 40 KB có thể vượt 64 KB khi một trong năm điều sau xảy ra.

Một ngăn xếp mạng được thêm vào.Ngay cả một ngăn xếp TCP/IP nhỏ gọn có TLS cũng tiêu tốn hàng chục kilobyte.

Một bộ hiển thị và bộ phông chữ được thêm vào.Một vài bộ ký tự Trung Quốc hoặc Nhật Bản có thể vượt quá toàn bộ ngân sách ứng dụng.

Cơ chế staging OTA được thêm vào.Cập nhật hai ngân hàng cần chỗ cho hình ảnh thứ hai, hoặc ít nhất là một hình ảnh nén.

Ghi log hoặc lưu trữ cấu hình chuyển vào flash.Các trang EEPROM mô phỏng làm giảm không gian ứng dụng khả dụng.

Ký hiệu debug hoặc bootloader tăng kích thước.Bootloader chiếm phần dưới của flash dù có ai đo hay không.

Điều gì thực sự chiếm thêm 64 KB

Sẽ hữu ích khi thấy dung lượng được phân bổ ở đâu trước khi quyết định. Một ứng dụng kết nối điển hình trên lớp MCU này được chia gần đúng như sau: bootloader 16 KB, mã ứng dụng 30–50 KB, ngăn xếp TCP/IP gọn nhẹ 12–20 KB, TLS 15–25 KB, hệ thống tệp và cấu hình 4–8 KB, và vùng chờ OTA bằng kích thước image.

Cộng các con số đó lại và giới hạn trần sẽ đến nhanh thôi. Một ứng dụng 45 KB với TLS và vùng chờ dual-bank cần hơn 128 KB trước cả dữ liệu ghi nhật ký hoặc dữ liệu phông chữ. Đó là lý do một linh kiện 64 KB có vẻ đủ trên bàn thử nghiệm rồi lại hết dung lượng trong quá trình tích hợp.

Phép tính tương tự giải thích vì sao "chỉ cần bật TLS" là quyết định về dung lượng lưu trữ cũng như là quyết định về bảo mật. Các bộ mã hóa và kho chứng chỉ không miễn phí.

4. Công việc chuyển đổi

Lỗi phổ biến nhất là sửa linker script mà quên bảng phân vùng. Sau đó bo mạch nạp đúng nhưng bản cập nhật OTA ghi vượt qua vùng staging, hoặc bootloader từ chối một image mà nó cho là quá lớn.

Độ bền và EEPROM giả lập

Flash không phải EEPROM. Flash của F103 được đánh giá cho một số lượng hạn chế chu kỳ xóa, thường trong khoảng mười nghìn mỗi trang. Một khối cấu hình được ghi mỗi khi tắt nguồn sẽ làm cạn kiệt một trang rất lâu trước khi vòng đời phục vụ của sản phẩm kết thúc.

EEPROM giả lập giải quyết vấn đề này bằng hai kỹ thuật. Thứ nhất, nó ghi vào một vị trí mới thay vì ghi đè, nhờ đó hao mòn được trải đều trên một trang hoặc một khối. Thứ hai, nó giữ một chỉ mục nhỏ trong RAM và chỉ ghi lại chỉ mục khi trang đã đầy.

Cả hai kỹ thuật đều tiêu tốn flash tỷ lệ với số lượng biến và độ sâu cân bằng hao mòn. Trên một linh kiện 64 KB, đây có thể là một phần đáng kể của ngân sách; trên CBT6, không gian thêm vào giúp cho một sơ đồ cân bằng hao mòn sâu hơn trở nên khả thi.

Nếu sản phẩm ghi log dữ liệu liên tục, hãy cân nhắc dùng FRAM ngoài hoặc một SPI flash nhỏ thay vì làm hao mòn flash nội bộ của MCU. Chi phí khiêm tốn và lợi ích về độ tin cậy là lớn.

Xung nhịp, wait state và hiệu năng cảm nhận

Một flash lớn hơn không làm MCU nhanh hơn, nhưng nó có thể thay đổi số wait state flash mà mã chạy với. Ở 72 MHz, F103 cần wait state trên cả hai dung lượng; sự khác biệt xuất hiện khi mã được đặt ở các địa chỉ khác nhau hoặc khi bộ đệm prefetch hoạt động khác đi.

Với hầu hết ứng dụng, điều này là vô hình. Với các vòng lặp đếm chu kỳ, giao diện bit-banged và các vòng điều khiển chặt chẽ, nó có thể quan trọng, và kiểm thử chấp nhận nên bao gồm các đường dẫn nhạy cảm về thời gian thay vì chỉ kiểm tra chức năng.

Nếu thiết kế chạy dưới 48 MHz, wait state thường bằng không và sự khác biệt biến mất hoàn toàn. Đó là một lý do nhiều thiết kế công nghiệp cố ý chạy chậm hơn mức tối đa.

5. Dung lượng flash khi chạy

F103 báo cáo dung lượng flash của nó trong một thanh ghi mà firmware có thể đọc. Điều đó hữu ích cho một nền tảng được xuất xưởng với các phiên bản 64 KB hoặc 128 KB, và đó cũng là một cái bẫy: mã hardcode số trang hoặc địa chỉ sector sẽ hoạt động sai trên một dung lượng khác.

Nếu sản phẩm có thể xuất xưởng với cả hai biến thể, hãy đọc kích thước khi khởi động và cấu hình lớp lưu trữ từ đó. Nếu chỉ xuất xưởng với một biến thể, hãy xác nhận kích thước mong đợi trong kiểm thử sản xuất để phát hiện cuộn linh kiện sai trước khi lắp ráp.

Các tùy chọn thiết kế OTA

Bốn kiểu phổ biến, và chi phí flash của chúng khác biệt rõ rệt.

Hai bank.Hai slot ảnh đầy đủ cộng với một bootloader. An toàn và đơn giản, nhưng cần gấp đôi kích thước ảnh. Trên 128 KB, một ảnh 40 KB với dàn trang hai bank tiêu tốn 80 KB trước khi có dữ liệu.

Dàn trang nén.Image đã tải xuống được lưu ở dạng nén và được giải nén tại chỗ khi khởi động. Tiết kiệm dung lượng, thêm một bước giải nén và một chế độ lỗi nếu bộ giải nén bị gián đoạn.

Staging bên ngoài.Image được lưu trong một bộ nhớ flash SPI bên ngoài, và MCU sao chép nó vào bên trong. Thêm một linh kiện nhưng loại bỏ hoàn toàn ràng buộc về dung lượng bên trong.

Không staging.Thiết bị tải xuống và ghi trực tiếp, thường với một bootloader khôi phục. Rẻ nhất về flash, rủi ro nhất ngoài thực địa.

Dù chọn kiểu nào, bảng phân vùng phải được cố định trước khi ghi firmware. Thay đổi nó sau đó sẽ vô hiệu hóa mọi thiết bị ngoài thực địa.

Kiểm tra tương thích firmware

Bốn bước kiểm tra giúp phát hiện hầu hết vấn đề khi chuyển đổi trước khi chúng ra đến thực địa.

ID thiết bị.Mã khởi động của firmware có thể rẽ nhánh theo ID; hãy thêm giá trị mới một cách tường minh.

Thanh ghi kích thước Flash.Hãy xác nhận giá trị mong đợi trong kiểm tra sản xuất, để cuộn linh kiện sai mật độ bị loại tại thời điểm nạp chương trình.

Độ lệch bảng vector.Nếu bootloader di dời ứng dụng, hãy xác nhận độ lệch khớp với bảng phân vùng mới.

Số trang mô phỏng EEPROM.Số trang được dành riêng cho cấu hình phải khớp với bố cục mới, nếu không trang cuối sẽ chồng lấn lên ứng dụng.

6. Nguồn thứ cấp tại 128 KB

Các quy tắc tương tự từ bài viết 64 KB vẫn áp dụng: khả năng tương thích chân là về mặt cơ học, và firmware phải được xác thực. Với flash lớn hơn, có thêm một mục cần lưu ý — thuật toán lập trình flash và độ chi tiết xóa có thể khác nhau, điều này ảnh hưởng đến cả thời gian sản xuất và thiết kế OTA.

Đồng thời xác minh đường khôi phục. Nếu bootloader hỗ trợ DFU qua USB hoặc UART, hãy kiểm thử việc khôi phục từ một image ứng dụng bị hỏng trên dung lượng mới, vì descriptor DFU thường mã hóa kích thước image tối đa.

Truy cập gỡ lỗi không thay đổi, nhưng các option byte đáng để kiểm tra: bảo vệ chống đọc, hành vi watchdog và cấu hình chân boot được lưu trong flash và có thể khác nhau về trạng thái mặc định giữa các lô. Hãy xác nhận chúng trên fixture thay vì trên bàn thử.

Nạp chương trình sản xuất và truy xuất nguồn gốc

Việc chuyển đổi dung lượng thay đổi image lập trình và thường cả fixture. Ba mục cần được xác minh trên dây chuyền.

Kích thước image và checksum.Thiết bị lập trình phải chấp nhận image lớn hơn, và checksum lưu trong vùng bootloader phải khớp.

Xác minh đọc lại.Việc xác minh đầy đủ sau khi lập trình phát hiện ngay cuộn linh kiện sai mật độ, thay vì ở lần khởi động đầu tiên.

Ghi nhật ký Unique ID.Unique ID 96 bit gắn một thiết bị với hồ sơ sản xuất. Việc ghi nhật ký nó giúp truy vết hàng trả về từ hiện trường và giúp xác định lô hàng lỗi.

7. Kế hoạch kiểm thử

Khi 128 KB vẫn chưa đủ

Nếu kích thước image dự kiến vượt khoảng 100 KB, bước tiếp theo không phải là một biến thể F103 khác — mà là một dòng vi điều khiển khác. Cortex-M3 của F103 ở 72 MHz và 20 KB RAM sẽ trở thành giới hạn trước cả flash.

Các lựa chọn bao gồm lớp 256 KB trong cùng dòng, một linh kiện Cortex-M4 có RAM lớn hơn và đơn vị dấu phẩy động, hoặc một bộ nhớ flash QSPI ngoài hỗ trợ execute-in-place. Mỗi lựa chọn là một quyết định nền tảng với chi phí chứng nhận và firmware riêng.

Quy tắc thực tế: chọn dung lượng đáp ứng các tính năng trong hai năm tới, không phải kích thước image hiện tại. Việc phải tái chứng nhận cùng một bo mạch hai lần tốn kém hơn mua linh kiện lớn hơn một chút ngay từ đầu.

Câu chuyện sản phẩm trong năm năm

Hãy xem một bộ điều khiển được thiết kế năm 2021 với image 40 KB trên C8T6. Đến năm 2023, image đạt 58 KB sau khi thêm giao diện web. Đến năm 2024, TLS đẩy nó vượt 64 KB, và nhóm phải nén phông chữ để vừa.

Năm 2025, vùng staging OTA không còn vừa. Giải pháp lúc đó là một bản sửa đổi bo mạch, bố cục phân vùng mới và di trú tại hiện trường — tất cả đều có thể tránh được nếu thiết kế đã bắt đầu trên CBT6 với chi phí chỉ thêm vài xu.

Đó là lập luận cho việc dự phòng dung lượng: không phải là flash thừa sẽ được dùng ngay, mà là chi phí khi hết dung lượng được đo bằng các lần re-spin chứ không phải bằng xu.

8. Chi phí và lập kế hoạch

Chênh lệch giá giữa C8T6 và CBT6 là nhỏ. Quyết định không nằm ở chi phí đơn vị; mà ở việc 64 KB tăng thêm có loại bỏ được một lần thiết kế lại trong tương lai hay không.

Ba dấu hiệu ủng hộ CBT6: image hiện tại trên 45 KB, roadmap có network stack hoặc màn hình, hoặc sản phẩm có vòng đời nhiều năm. Hai dấu hiệu ủng hộ ở lại 64 KB: image ổn định và nhỏ, và sản lượng đủ cao để từng cent có ý nghĩa.

Nếu image đã gần 100 KB, hãy nhảy thẳng lên lớp 256 KB. Qualify một linh kiện 128 KB rồi lại chuyển tiếp sau một năm là con đường tốn kém nhất.

Quy tắc quyết định cho thiết kế mới

Hãy ghi ra ba con số trước khi chọn: kích thước image hiện tại, kích thước dự kiến sau hai năm, và liệu OTA có bắt buộc hay không. Nếu câu trả lời cho OTA là có, hãy cộng thêm kích thước image một lần nữa. Nếu tổng dự kiến trên 90 KB, hãy bắt đầu từ 128 KB trở lên.

Đối với một sản phẩm chức năng cố định không có kết nối và không có OTA, 64 KB thường là đủ và C8T6 vẫn là lựa chọn rẻ hơn. Sai lầm là giả định rằng một sản phẩm sẽ giữ nguyên cố định trong năm năm.

9. FAQ

CBT6 có thể thay thế trực tiếp cho C8T6 không?

Về mặt vật lý và chức năng thì có. Firmware cần được cập nhật linker script và bảng phân vùng cho dung lượng flash lớn hơn.

RAM có tăng không?

Không. Cả hai linh kiện đều có 20 KB. Nếu RAM là yếu tố giới hạn, một linh kiện có flash lớn hơn sẽ không giúp ích.

Sau này tôi có thể quay lại C8T6 không?

Chỉ khi image vừa trong 64 KB. Hãy lập bảng phân vùng sao cho có thể hạ cấp mà không cần thay đổi mã.

Các linh kiện thay thế tương đương có cùng thanh ghi kích thước flash không?

Thường có một thanh ghi tương thích, nhưng giá trị và độ chi tiết có thể khác nhau. Hãy đọc datasheet cho đúng linh kiện cụ thể.

Lỗi chuyển đổi phổ biến nhất là gì?

Cập nhật linker script nhưng không cập nhật bảng phân vùng OTA, dẫn đến các bản cập nhật ghi ra ngoài vùng staging.

Tôi có nên đặt CBT6 cho một thiết kế mới không?

Nếu image dưới 32 KB và ổn định, C8T6 là phù hợp. Nếu có bất kỳ khả năng tăng trưởng nào — giao diện web, TLS, ghi log hoặc OTA — hãy bắt đầu từ 128 KB và tránh phải làm vòng thiết kế thứ hai.

Ghi chú nguồn cung

Khả dụng ở dung lượng này tốt hơn ở 32 KB, vì nhiều thiết kế sử dụng nó hơn. Hãy duy trì một nguồn thứ hai đã được phê duyệt và xác nhận rằng thuật toán nạp flash của nó khớp với fixture sản xuất của bạn; image là như nhau, nhưng tooling có thể không như vậy. Hãy kiểm tra trước khi bạn đặt hàng.

10. Nguồn

• Trang sản phẩm ST STM32F103CB:st.com
• Tài liệu GigaDevice GD32F103:gigadevice.com