Most cost discussion around a microcontroller stops at the unit price. In volume, the programming step — getting your firmware onto the chip, correctly, every time — is a quiet line item that scales with every unit you ship. This article looks at AT32 production programming from the buyer's side: where the cost actually sits, and how to keep it low without weakening protection.
Parts referenced below: AT32F403ACGT7, AT32F421K8U7-4, AT32F415CBT7, AT32F425C8T7 and AT32F435RGT7.
The three ways firmware gets onto the chip
Each method moves the same bytes, but the labour and the risk land in different places.
| Method | Best at | Hidden cost | When it wins |
|---|---|---|---|
| In-circuit (SWD/JTAG) at test | Low-to-mid volume, frequent firmware changes | A programmer per station, manual connect | Prototype and variable firmware |
| Pre-programmed parts | Stable firmware, high volume | Inventory tied to one image | Long runs of a fixed build |
| Gang / handler programming | Very high volume | Upfront tooling and fixtures | Tens of thousands per month |
The honest rule: pick the method by firmware stability first, then by volume. A stable design on a gang programmer is cheap; a changing design pre-programmed is a warehouse of obsolete stock.
Protection is free, discipline is not
AT32 parts include read-out protection and option-byte control on the chip itself. Turning these on adds zero to the bill of materials. What costs money is the process around them.
- Decide the protection level before mass production. Raising it later often forces a full erase, and a wrong bit can brick a batch.
- Bake the locking step into the programmed image so the test fixture applies it automatically.
- Keep a record of which protection level shipped in which lot, so a returned unit can be handled correctly.
Done this way, firmware security is essentially free. Added after the fact, it is a line-down event.
Tag the batch, not the board
The most expensive production bug with the AT32 family is flashing the right firmware to the wrong member of the family. Flash size, pin count and peripheral set vary across parts that share a prefix, and a mismatched image either fails to boot or behaves subtly wrong. The fix is unglamorous: at intake, tag every batch with the part number and the image checksum, and have the fixture refuse any mismatch.
Keep the bootloader field-friendly
Separate the bootloader from the application and make the bootloader updatable through a defined interface. A returned unit can then be re-flashed without a cable and a bench. The one-time engineering to build a solid bootloader is far cheaper than the recurring handling cost of units that need a technician.
For a wider view of the family, see Microcontrollers and MCUs and the AT32F403ARGT7.
Frequently asked questions
What are the realistic ways to flash firmware onto an AT32 in production?
Three approaches dominate. In-circuit programming through the SWD/JTAG header is simplest for low volume and lets you update at test. Offline programming of the raw flash (or pre-programmed parts from the factory) moves the work upstream so the board line only places parts. A gang programmer or automated handler burns many units at once for high volume. The cost driver is not the tool, it is how many times a human touches each board.
Does encrypting firmware add cost to production?
The read-out protection and option-byte locking are features of the chip itself, so enabling them costs nothing in bill of materials. The cost is in discipline: you must decide the protection level before mass production, because raising read protection usually requires a full erase, and a wrong setting can brick a batch. Build the locking step into the programmed image and the test fixture, and it is free; bolt it on later and it is expensive.
Should I pre-program parts or program at the test station?
Pre-programming at the distributor or with a gang writer removes a step from the board line and shortens test time, which matters when volume is high. The trade-off is inventory: pre-programmed parts are tied to one firmware version. For designs that change firmware often, program at the test station so you are not holding rework stock. For stable designs, pre-program and save the line time.
How do I avoid paying for a firmware update on every returned unit?
Keep a clean separation between the bootloader and the application, and make the bootloader field-updatable through a defined interface. Then a returned unit can be re-flashed without opening the case or involving a programmer. The one-time engineering to build a robust bootloader is far cheaper than the recurring handling cost of units that need a cable and a bench.
What is the cheapest mistake to avoid in AT32 production programming?
Mismatching the image to the exact part. The AT32 family spans flash sizes and pin counts that look interchangeable on paper but need different images. Tag every batch with the part and the image checksum at intake, and have the test fixture refuse to flash a mismatch. That single check prevents the most expensive failure: a correctly built board running the wrong firmware.
About us & trademarks: JTDZ Tech (Shenzhen Jingteng Electronics Technology Co., Ltd.) is an independent distributor of electronic components. We are not an authorised distributor or representative of the manufacturers named in this article. Manufacturer and part names are used for indicative purposes only, to help identify the components discussed; all trademarks remain the property of their respective owners. Always verify specifications against the manufacturer's datasheet before design-in or purchase.
价格随采购数量与行情流动，所示价格仅供参考。欢迎询价获取实时报价，量大从优。
