Setting up firmware for production

[anantgaur]

Hello,

We recently finished development of a new board based on ESP32-S3 and were seeking to move it to production. We don't have a very robust production setup just yet. I have to setup our project to move to production from our development environment.

Since I am very inexperienced with projects like this I just wanted to ask for some guidance on how to set up a production environment for a smaller scale.

• What tools should I use for flashing?

We can use a PC with a USB cable to flash it using UART, that's what we have been using so far. Are there tools available to easily flash something over UART?

I was thinking of setting up a bash script and bundle it with the build folder but I am not sure if that would work. Do I need a full idf install with idf.py?

Are there any flashing tools where I can just provide the bin files to the script and it will flash them?

• How should I handle flash encryption?

I do understand on device keys are recommended but can I use pre generated keys if I don't expect my device to reach a common consumer? I am worried about people on my team flashing problematic firmware on an off site machine rendering it useless. I know it shouldn't happen if processes are followed. How worried should I be?

Can I still flash over UART if I use pre generated keys?

I understand I would have to use espefuse.py to set the keys in efuse. Can that key be changed afterwards?

• How should I setup my git releases

I want my release to have to the tools to flash and all the necessary files. I want to create detailed steps on how to make a new release. What folders, files, tools should I include?

I also want to confirm, except for flash encryption, turning off logging and secure boot, is there anything else I should check before I make a build for release?

Any help on any question would be appreciated!

[jakob]

Hi,

I found this guide which focuses on WiFi testing, but also mentions some of the flashing tools: https://www.espressif.com/sites/default ... ide_en.pdf

Regarding the "device key", there is some information how to write it into NVS here: https://docs.espressif.com/projects/esp ... s_mfg.html. Note that secure boot and flash encryption keys are usually created on the device on first boot and don't need to be managed like this.

A few general notes: It is a really good idea to check that all the software is flashed correctly, so booting up after flashing and doing at least some plausibility checking is necessary. You will likely need to create a device database that contains all necessary information to identify a device (e.g., chip version, revision, software version, etc.). If your device is connected to the cloud, you likely also want to add its key or certificate there. Ideally, you flash the device, ship it, plug it in and it works.

Hope this helps a bit.

[anantgaur]

Thank you for the response good notes!

Regarding the "device key", there is some information how to write it into NVS here: https://docs.espressif.com/projects/esp ... s_mfg.html. Note that secure boot and flash encryption keys are usually created on the device on first boot and don't need to be managed like this.

Manufacturing utility was exactly what I was looking for! Thank you, with your recent documentation questionnaire maybe I should mention this. There should be an easy place to see what all tools/components etc. are available.

A few general notes: It is a really good idea to check that all the software is flashed correctly, so booting up after flashing and doing at least some plausibility checking is necessary. You will likely need to create a device database that contains all necessary information to identify a device (e.g., chip version, revision, software version, etc.). If your device is connected to the cloud, you likely also want to add its key or certificate there. Ideally, you flash the device, ship it, plug it in and it works.

We are already managing device version etc. using AWS IOT services. The fleet management also keeps tracks of the certificates attached with the device. I should keep a tally of revision too, I had forgotten that, thanks.

We do a full shipment test before we ship our machines, the ESP32 actually generates a report of its functions and logs it on our server before it ever leaves the factory. I am not worried about in factory, I am worried that if I use ESP generated keys instead of host generated keys, I can be left out of luck if someone flashes something wrong on site leaving me with no way of fixing that remotely. If I use host generated keys I can just send a pre-encrypted bin and have that flashed. I think I will be going that route.

[Mahavir]

Hello,

How should I handle flash encryption?

Please refer to following documentation guides:

https://docs.espressif.com/projects/esp ... urity.html
https://docs.espressif.com/projects/esp ... flows.html

First one talks about security in general and second one is specific to enabling security features with external host machine assisted workflow.

I do understand on device keys are recommended but can I use pre generated keys if I don't expect my device to reach a common consumer? I am worried about people on my team flashing problematic firmware on an off site machine rendering it useless. I know it shouldn't happen if processes are followed. How worried should I be?

It is fine to use pre-generated flash encryption key. It is strongly recommend to have per device unique key. Above docs pointer have more information in this regard.

Can I still flash over UART if I use pre generated keys?

Yes, provided the UART DL mode is not disabled or secure DL mode is enabled.

I understand I would have to use espefuse.py to set the keys in efuse. Can that key be changed afterwards?

No, EFuse is one time programmable memory. Once the flash encryption key is programmed, it can not be changed.

Please feel to raise any questions you may have.

Thanks.

[GogoBuilds]

Hey anantgaur — late to this thread, but the concern you raised is the right one to worry about: host-generated keys + a pre-encrypted bin is the safer route precisely because it leaves you a remote path back if someone flashes something wrong on-site. The other thing worth locking down before production is your rollback story — A/B OTA partitions plus a factory/recovery partition so a bad update can't strand a fielded unit. With your full-shipment-test-before-leaving-the-factory setup, you're already ahead of most.
On the remote-fix worry specifically: I'm a firmware dev building a hosted OTA backend for ESP32 fleets (signed upload, staged rollout, crash-loop rollback) as a lighter layer over the AWS IoT path you're already on. If you're open to it, I'd love 15 minutes to hear how you ended up handling updates in production — genuinely trying to learn from people shipping real machines.