How to program ESP32 for mass production

[leotordo]

Hello,
I designed a board with ESP32C3 and wrote FW with ESP-IDF. On my pc I've installed all required prerequisites: Java, Git, Python etc. and IDF. I download bin file by UART and a little board with two switches for reset and GPIO9

Now, I've to send informations, binary and hardware to our assembly office for the mass production.

Have I to install all software I used to develop the project or is there a single program I can you only to download the binary?

Thanks
Stefano

[username]

Get the Flash Download Tools.
https://www.espressif.com/en/support/do ... ther-tools

[bidrohini]

Something like this may help too.
https://www.youtube.com/watch?v=hrNsdTKUbfY

[leotordo]

thanks everybody

[DrMickeyLauer]

I'm currently pondering about the same thing. How are you guys handling testing and factory programming? For my project, roughly 50% of the hardware is testable without special fixtures. Ideally I would love the factory doing the tests before they send the units over to us. Are there any best practices with regards to testing and factory programming? Would love to know your experiences, in particular of those folks with peripheral devices (CAN, KLINE, ENET, etc.) on the boards.

[ESP_Sprite]

Fwiw, I once designed a little production run; it was small enough to have testing, programming and assembly done manually. What I did was design a PCB that goes on top of a Raspberry Pi, that had a little OLED display on it as well as some ADCs and other measuring circuits. That was connected to a bed-of-nails tester that interfaced with a bunch of important points: power supplies, the output for the speaker etc as well as the programming pins of the ESP32. The firmware in the Raspberry Pi used esptool.py to flash some factory testing firmware to the ESP, then communicated with that using a custom script to run the ESP32 through the testing steps, measuring external signals using the ADCs on the custom PCB. If there was an error, it'd show up on the OLED so the tester could chuck it into the 'broken' bin; if everything checked out, the Raspberry Pi would program the final firmware and show the unit was ready. It took some designing and programming, but from what I can tell it works well. All the person testing it needs to know is to chuck a board into the bed-of-nails tester, wait until the LCD indicates the test is done, and then dependent on the result chuck it in the 'OK' bin or to mark it with the error and throw it into the 'broken' pile.

[DrMickeyLauer]

I like it. That's probably the most comprehensive approach, albeit the most complex one. Any other success stories?

[DrMickeyLauer]

By now we're thinking about a special fixture that can hold 5 boards secured and attached (via needle pins) and connected via USB to a Linux PC (probably a Raspi, but that's not decided yet). Now each of the boards is also connected (through their OBD2 connector) to another board (same, but "known good" and running a special test master software). The test client software is a part of the original production firmware and starts up when there is nothing in NVS. The test results are display via the 4 builtin LEDs on the device under test.

Now I need to think of a way to script the `esptool` in a way that it a) probes whether a new device has been attached to /dev/ttyUSBx, and if so, flashes it with a test software. Since the device nodes will be permanently there (we're talking UART, not JTAG), we need to probe every second or so. Since there is still no proper python API, I'm afraid I need to parse the esptool output, right?

Does that sound feasible so far?

[ESP_Sprite]

ESPTool has somewhat of an API, albeit a very light one, so I think you indeed need to be parsing the output of the tool.