Using ESP/Tasmota for OTA programming of STM32 microcontrollers #21068
Replies: 3 comments 6 replies
-
|
Tasmota is already able to do OTA update of STM32 via serial, like in the Shelly Dimmer 2 where the Tasmota setup includes replacing the firmware of the STM32. To be clear, I've not looked closely at your suggestion here, or how things differ, and am not trying to say anything about how to handle the "overlap", but it seems to plausibly make sense to have some unification. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, cool, I had no idea. I'll have to look at the existing code then. But based on the docs alone, a major difference is that Tasmota is driving the bootloader protocol there, given a firmware file upload. In my implementation, Tasmota is acting like a dumb serial to TCP bridge, relying on another project to handle the bootloader protocol. Arguably the latter is more flexible, since it also allows readback and option byte programming, etc. I also don't really know if there are big differences in the STM bootloaders across the many STM32 variants out there, but I could imagine some corners having been cut in existing code considering it only has to work for one target device. My gut feeling is that unifying the two would probably be a lot of work due to how different the approach is. ETA: reading that again, I sound like I don't like the existing approach -- of course the existing method is much more user-friendly! It would probably be good enough for my use case too, if it works with the chip I'm using. |
Beta Was this translation helpful? Give feedback.
-
|
The implementation for the Shelly Dimmer 2 does not look like it is abstracted for general use, but is based on detection of file type (simple fingerprinting of the start bytes) when that driver is configured. Same OTA upgrade flow is also used for other devices needing firmware replacement on a sister MCU, but still adapting to differences in protocol. |
Beta Was this translation helpful? Give feedback.
-
|
Having now browsed the existing code a little, the implementation of the actual STM bootloader protocol at https://github.com/arendst/Tasmota/tree/development/lib/lib_div/stm32flash-1.0-tasmota actually looks like a generic implementation. If I didn't already get flashing working via stm32loader, I'd use it for my use case. So that part looks good already. I think the hardcodedness in the code you linked is only in divining what the user meant when they uploaded a file with the generic firmware upload box? I feel like that could also be disambiguated by using a dropdown on the upload page, based on which drivers are in the template, a macro in user_config_override.h, or even just the file extension, if the heuristics become a problem. The more fundamental issue I'm seeing now is that for a generic implementation you'd want to support two drivers sharing the same serial port pins; one for the firmware upload, and one for normal operation. For my use case "normal operation" would be the existing TCP bridge as a dumb debug serial port, but more typically it'd be something more intelligent to control the connected device via MQTT. In both my driver and the Shelly dimmer driver (I think?) the update logic is kind of baked into the "normal operation" driver, but you can't exactly expect every driver that uses serial to implement a hook to let specifically an STM32 programming driver take control. I don't know nearly enough about Tasmota to reason about what that kind of pin sharing would look like, or if it's possible at all. Simplifying to just sharing serial ports, I guess one could add something into TasmotaSerial for this; that sounds like way too ugly of a hack to me, though. Otherwise the user would have to manually change the template to switch between firmware update and normal operation, right? |
Beta Was this translation helpful? Give feedback.
-
|
@jvanstraten i want to flash an attached stm32F4 via tasmota OTA. sfromis already helped me to find the supported device table but it seems that the F4 can´t be flashed currently. Do you already have a memory map table or something else which helps me to solve my ota issue? |
Beta Was this translation helpful? Give feedback.
-
|
Not really, because the approach I'm using is fundamentally different from what mainline Tasmota does. In my approach Tasmota is really just a TCP to serial bridge, and I rely on the Python I don't actually know how the bootloader protocol works myself, so I'm not sure what kind of information you need exactly, assuming you're looking to submit a PR to Tasmota. Maybe stm32loader's source (probably this file?) can help you if STM's own documentation isn't clear. |
Beta Was this translation helpful? Give feedback.
-
Yes, you are correct in your assumption that most Tasmota users does not touch the code. |
Beta Was this translation helpful? Give feedback.
-
|
As long as it's just me it should probably just stay on my fork, otherwise it's just bloat and maintenance overhead for everyone else. I don't foresee ever having to update the modules I'm running this on, so I'm unlikely to maintain it in that case. If it's not enabled in any default build to save space, no one might even notice when it breaks. I figure that with this discussion thread out there there's at least a chance someone with the same setup I came up with would find my fork and not have to redo the work. If at least one other person does show up there's more reason to merge. |
Beta Was this translation helpful? Give feedback.
-
|
That sounds like a plan 👍 |
Beta Was this translation helpful? Give feedback.
-
Short version: I just made a Tasmota driver to use an ESP-01S for OTA updating of STM32 microcontrollers. Is there any interest in a pull request?
Long version:
I'm currently working on some DIY home automation stuff, but after having tried Tasmota and ESPHome for a while I'm not convinced about power consumption, latency, stability, etc... WiFi just isn't for me. So back to wired serial ports I went.
One thing I immediately missed from the WiFi stuff though, is OTA. You just can't really do that over DIY serial busses running at 2400 baud, not to mention that writing bootloaders yourself is hard. At some point I moved to Teensy-based stuff (back when that was a tenth of the price) so I at least wouldn't need more than a long USB cable, but the really old stuff is a bunch of ATtiny microcontrollers that are so far embedded I need to flip my breaker, disassemble stuff, and then flip my breaker again to, you know, power my computer. Rinse and repeat for every test... Ain't nobody got time for that. Counterpoint: that system has been working flawlessly without any updates or repairs for over a decade now. Meanwhile Home Assistant + ESPHome seems to catch fire for an entirely new reason every time it updates, power goes out, or there is a full moon. Really, the only thing my own system misses thus far is reasonable extensibility, which, due to all the DIY point-to-point serial connections, usually requires recompilation.
So I had the following idea: what if STM32 microcontrollers (which have a serial bootloader, similar to ESP, but are much less power-hungry and have much more I/O and peripherals), but with an ESP-01S tied to its primary serial port, BOOT0, and nRST pins, with its power gated by a switch controlled by the STM32? Then whenever I want debug serial or OTA updates, I can give it a command to enable power to the ESP-01S over whatever low-speed wired protocol I want. Or I can just push a button to do the same if that fails, which is more work, but still doesn't require disassembly and such. A complete ESP-01S module is literally cheaper than a single STM32 in my BOM (Asia vs the West and all), so it seems worth the investment.
I found the existing TCP to serial bridge driver in Tasmota, and initially figured I'd just use that. However, I didn't immediately see a good way to automate driving BOOT0 and nRST without setting up and maintaining a whole MQTT environment again just for that. What I wanted, really, is for it to just reset the STM32 into its bootloader automatically when connecting via TCP, and reset it into application code when the connection closes. I figured I could just script it, but the ESP-01S board I designed for is an ESP8266, so no berry scripting. D'oh. To be honest I know little more about berry than that it exists, so I don't really know if it would have been possible anyway.
In the end I bit the bullet and started hacking away at Tasmota itself. The result is a clone of the TCP to serial driver, with some light modifications to make it do what I want. It differs from the existing TCP bridge as follows:
Combined with a modification to stm32loader that allows it to connect via TCP instead of a serial port, I have everything I need: just point it to the bootloader TCP server and it can program the connected STM32. In the meantime I can keep netcat/telnet open to the virtual COM port server for debug messages and commands.
So, as I stated in the tl;dr, my question is if there is interest in a PR for this, or if it's out of scope. After all, I think Tasmota is more intended for people who can't or don't want to program microcontrollers themselves, which you'd still have to do for STM32s. Not to mention that there's some circuitry involved in tying the two together, at least if you don't want the ESP32 to always be powered. I'm guessing the answer is "out of scope," and I don't want to spend time testing and cleaning up beyond "works on my machine" for a dead-on-arrival PR, so hence the question.
Beta Was this translation helpful? Give feedback.
All reactions