Dual MCU design for an high processing LoRa device

[SamyHaouaraUTC]

Hello,

I recently came across an ST article describing a Condition-Based Monitoring architecture using a dual-MCU approach, with an STM32L476RG handling signal processing (and potentially edge AI), and an STM32WL dedicated to network connectivity.

I find this architecture very interesting and relevant for a project I’m currently exploring, but I would like to better understand what level of support and resources are available from ST for implementing such a solution in practice.

In particular, I have a few questions:

• Does ST provide official support or reference designs for this kind of dual-MCU architecture (STM32L4 + STM32WL)?
• Are there any example projects, application notes, or firmware packages that demonstrate communication between the two MCUs in this context?
• Regarding FUOTA (Firmware Update Over The Air), are there existing solutions or middleware provided by ST that support this setup, especially with STM32WL acting as the communication node?
• Are there recommended tools, libraries, or ecosystems (e.g., STM32Cube, expansion packages) specifically targeting Condition-Based Monitoring or predictive maintenance use cases?
• Finally, is there any dedicated customer support, documentation, or training material available on the STM website for this type of architecture?

Any pointers to documentation, examples, or experience feedback would be greatly appreciated.

Thanks in advance for your help!

Best regards,
Samy Haouara

[mƎALLEm]

Hello,

I don't think there is a specific application/application note or documentation related to that specific architecture. 

For FUOTA, please refer to the AN5554 "LoRaWAN® firmware update over the air with STM32CubeWL up to v1.4.0"

 

 

[Andrew Neil]

---

@SamyHaouaraUTC wrote:

I would like to better understand what level of support and resources are available from ST for implementing such a solution in practice.

---

There aren't really any special resources or support necessary - just treat it as two separate microcontroller projects.

Most likely, they will just communicate via one simple interface; eg, UART.

 

An example would be the LoRa projects which implement an AT-command interface

https://www.st.com/resource/en/user_manual/um2073-stm32-lorawan-expansion-package-for-stm32cube-stmicroelectronics.pdf#page=37

via: https://www.st.com/en/embedded-software/i-cube-lrwan.html#documentation

 

[SamyHaouaraUTC]

Thank you both for your answers and the shared resources — very helpful.

I do have one follow-up question:

From your perspective, do you see any incompatibilities or major challenges in implementing FUOTA within this dual-MCU architecture, specifically to update both the STM32WL (connectivity side) and the STM32L4 (application/processing side)?

For example, would this typically require a custom mechanism between the two MCUs for relaying firmware updates, or are there existing approaches/recommendations from ST for handling this kind of setup?

Thanks again for your insights.

Best regards,

Samy Haouara

[mƎALLEm]

For STM32WL you can consider the  AN5554 while for STM32L4 you need to consider either to implement a custom bootloader or simply use the ST bootloader (AN2606) most probably using the UART interface and make STM32WL a bridge between the wireless server and STM32L4. Indeed you need to implement a mechanism that makes each of STM32WL and STM32L4 knows that the other MCU is going to be updated and synchronize with it.

[Andrew Neil]

FUOTA is going to have to be custom to some degree - as there are 2 sets of firmware to update.

Again, this could be handled as 2 entirely separate projects - each microcontroller independently.

 

Note that FUOTA is challenging over LoRa because of its very small payloads - especially at the extremes of range...