Traducido del English por IA ·
Nuestros controladores de riego tienen un STM32F407 que gestiona la lógica de las válvulas y un ESP32 que solo se encarga del Wi-Fi y de MQTT. Ambos se comunican por UART a 921600. El ESP32 es fácil de actualizar. El STM32, en cambio, tiene que flashearlo alguien con un ST-Link en el campo, y en verano eso supone mucho desplazamiento.Quiero que las actualizaciones de firmware de Hermetry entreguen también la imagen del STM32. ¿Qué recibe exactamente el dispositivo de Hermetry cuando se le asigna una actualización, y qué tiene que reportar de vuelta? Y en el lado del STM32, ¿necesito la configuración de doble banco o me basta con un segundo slot en la flash externa? La pieza es de 1 MB y la imagen ocupa unos 380 KB.
Our irrigation controllers have an STM32F407 doing the valve logic and an ESP32 that only does Wi-Fi and MQTT, the two talk over UART at 921600. The ESP32 is easy to update. The STM32 has to be flashed by someone with an ST-Link in a field, which in summer means a lot of driving.
I want Hermetry’s firmware updates to deliver the STM32 image too. What exactly does the device get from Hermetry when an update is assigned, and what does it have to report back? And on the STM32 side, do I need the dual bank setup or can I get away with a second slot in external flash? 1 MB part, image is about 380 KB.
Traducido del English por IA ·
En seguimiento a esto, tenemos la misma separación en nuestros controladores HVAC.
Following, we have the same split in our HVAC controllers.
Traducido del English por IA ·
Hicimos exactamente esto en controladores de edificios (STM32 más un módem ESP32). A Hermetry no le importa qué chip acaba ejecutando la imagen; solo se comunica con el dispositivo que ha iniciado sesión, así que el ESP32 es el que descarga e informa.Cuando asigna un paquete, el dispositivo recibe estos atributos compartidos en un solo mensaje en v1/attributes/set: fw_title, fw_version, fw_size, fw_checksum, fw_checksum_algorithm (SHA256), fw_url y fw_sig si el paquete tiene una firma separada. fw_url es una dirección HTTPS de corta duración, válida durante 15 minutos, y la descarga puede reanudarse con una solicitud HTTP Range.El dispositivo informa del progreso como atributos de cliente: fw_state pasa por DOWNLOADING, DOWNLOADED, VERIFIED, UPDATING, UPDATED (o FAILED con fw_error), fw_progress de 0 a 100 durante la descarga, y tras el reinicio current_fw_title y current_fw_version. UPDATED por sí solo no se acepta; espera ver la nueva versión en ejecución.Nuestro flujo en el ESP32:
1. llega fw_* -> comprobar fw_title == "irr-stm32"
2. GET fw_url (reanudación Range) a la flash del ESP32, informar fw_progress
3. Comprobación SHA-256 + Ed25519 contra fw_sig -> fw_state VERIFIED
4. Enviar la imagen por UART al bootloader del STM32 en el banco 2
5. El STM32 verifica de nuevo, intercambia los bancos y reinicia -> fw_state UPDATING
6. El STM32 informa su versión al ESP32 -> current_fw_versionTiene un F407 de 1 MB, que es de banco único, así que para 380 KB usaría los 512 KB superiores como zona de descarga y un pequeño bootloader que copie la imagen tras comprobarla. La flash externa también funciona, pero entonces el bootloader necesita el driver SPI.En la pestaña Firmware del perfil active las actualizaciones de firmware (desactivadas por defecto) y deje desactivado Permitir imágenes sin firmar fuera del banco de pruebas. Las actualizaciones por LTE también están desactivadas por defecto. Configure los Modelos de hardware en el paquete para que una imagen del ESP32 nunca acabe en la zona del 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_versionYou 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.
Traducido del English por IA ·
Muy claro, gracias. ¿Qué pasa si los 15 minutes se agotan a mitad de una descarga con un enlace débil? Algunos de nuestros campos tienen una sola barra.
Very clear, thanks. What happens if the 15 minutes run out halfway through a download on a weak link? Some of our fields have one bar.
Traducido del English por IA ·
El dispositivo vuelve a pedir fw_url (una solicitud de atributo) y recibe una nueva, luego reanuda desde el byte en el que estaba usando Range. Hemos tenido descargas de una hora de esta manera sin ningún problema.
The device asks for fw_url again (an attribute request) and gets a fresh one, then resumes from the byte it had with Range. We’ve had downloads take an hour that way without a problem.
Traducido del English por IA ·
Funcionó en dos equipos de banco y uno en campo. Usé la mitad superior de la flash más un bootloader de 16 KB. El primer intento falló porque puse fw_title en el paquete como «irr_stm32» y el ESP32 comprobaba un guion, así que se quedó en Queued. Después de ponerle el nombre correcto, pasó a UPDATED con la nueva current_fw_version.
Got it working on two bench units and one in the field. I used the upper half of flash plus a 16 KB bootloader. First try failed because I set fw_title on the package to «irr_stm32» and the ESP32 checked for a dash, so it just sat in Queued. Named it properly and it went through to UPDATED with the new current_fw_version.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.