Traduit de English par IA ·
Nous avons fait exactement cela sur des contrôleurs de bâtiment (STM32 plus un modem ESP32). Hermetry ne se soucie pas de la puce qui exécute finalement l’image ; il ne communique qu’avec l’appareil connecté, donc c’est l’ESP32 qui télécharge et qui remonte les informations.Lorsque vous assignez un paquet, l’appareil reçoit ces attributs partagés dans un seul message sur v1/attributes/set : fw_title, fw_version, fw_size, fw_checksum, fw_checksum_algorithm (SHA256), fw_url et fw_sig si le paquet possède une signature détachée. fw_url est une adresse HTTPS à courte durée de vie, valable 15 minutes, et le téléchargement peut reprendre grâce à une requête HTTP Range.L’appareil signale la progression via des attributs client : fw_state passe par DOWNLOADING, DOWNLOADED, VERIFIED, UPDATING, UPDATED (ou FAILED avec fw_error), fw_progress de 0 à 100 pendant le téléchargement, puis après le redémarrage current_fw_title et current_fw_version. UPDATED seul n’est pas accepté : il attend de voir la nouvelle version en cours d’exécution.Notre procédure sur l’ESP32 :
1. fw_* arrive -> vérifier fw_title == "irr-stm32"
2. GET fw_url (reprise Range) dans la flash de l'ESP32, signaler fw_progress
3. Vérification SHA-256 + Ed25519 avec fw_sig -> fw_state VERIFIED
4. Envoyer l'image par UART au bootloader du STM32 dans la banque 2
5. Le STM32 vérifie à nouveau, permute les banques, redémarre -> fw_state UPDATING
6. Le STM32 transmet sa version à l'ESP32 -> current_fw_version
Vous avez un F407 de 1 Mo, à banque unique ; pour 380 Ko, je réserverais les 512 Ko supérieurs comme zone de téléchargement, avec un petit bootloader qui recopie l’image après vérification. La flash externe fonctionne aussi, mais le bootloader aura alors besoin du pilote SPI.Dans l’onglet Firmware du profil, activez les mises à jour du firmware (désactivées par défaut) et laissez Autoriser les images non signées désactivé en dehors du banc de test. Les mises à jour via LTE sont également désactivées par défaut. Renseignez les Modèles matériels du paquet pour qu’une image ESP32 ne se retrouve jamais dans la zone du STM32.Firmware updates (OTA)
We did exactly this on building controllers (STM32 plus an ESP32 modem). Hermetry doesn’t care which chip ends up running the image, it only talks to the device that’s logged in, so the ESP32 is the one that downloads and reports.
When you assign a package, the device gets these shared attributes in one message on v1/attributes/set: fw_title, fw_version, fw_size, fw_checksum, fw_checksum_algorithm (SHA256), fw_url and fw_sig if the package has a detached signature. fw_url is a short-lived HTTPS address, valid for 15 minutes, and the download can resume with an HTTP Range request.
The device reports progress as client attributes: fw_state goes DOWNLOADING, DOWNLOADED, VERIFIED, UPDATING, UPDATED (or FAILED with fw_error), fw_progress 0 to 100 while downloading, and after the reboot current_fw_title and current_fw_version. UPDATED alone isn’t accepted, it wants to see the new running version.
Our flow on the ESP32:
1. fw_* arrives -> check fw_title == "irr-stm32"
2. GET fw_url (Range resume) into ESP32 flash, report fw_progress
3. SHA-256 + Ed25519 check against fw_sig -> fw_state VERIFIED
4. stream image over UART to the STM32 bootloader into bank 2
5. STM32 verifies again, swaps banks, reboots -> fw_state UPDATING
6. STM32 reports its version to ESP32 -> current_fw_version
You have a 1 MB F407, which is single bank, so for 380 KB I’d use the upper 512 KB as the download slot and a small bootloader that copies it over after checking it. External flash works too, but then the bootloader needs the SPI driver.
On the profile’s Firmware tab turn on firmware updates (off by default), and leave Allow unsigned images off outside the test bench. Updates over LTE are off by default too. Set Hardware models on the package so an ESP32 image never ends up in the STM32 slot.

