Skip to main content
Visitor II
February 16, 2026
Question

Interfacing ESP32-C6 with ST85MM (Architecture & Firmware loading)

  • February 16, 2026
  • 2 replies
  • 196 views

Hi everyone,

I’m currently working on a design to integrate an ESP32-C6 with the ST85MM PLC modem, and I’m hitting a few roadblocks regarding the best hardware architecture and communication flow.

To be honest, I'm also a bit confused about the specific differences between the ST8500 and the ST85MM. I’ve been reading documentation for both, and while they seem very similar (same package, similar pinouts), I'm not clear if the host interface or boot behavior differs significantly between them.

Crucially, I haven't been able to find any firmware examples or reference code for either chip. I feel like I'm flying blind regarding the actual host communication implementation. If anyone has a code snippet, a repository, or a specific application note that shows how to initialize the modem or handle the host exchange, that would be appreciated.

My main goal is to use the ESP32-C6 as the host controller to manage the ST85MM, specifically for loading firmware and exchanging data (reading "Meters and More" frames). I have a few specific questions:

1. Physical Connection (UART or SPI)
What is the recommended interface for connecting the ESP32-C6 to the ST85MM?

  • Is UART sufficient for both firmware loading and real-time frame reading, or should I commit to SPI for higher bandwidth?

  • Are there specific flow control pins (RTS/CTS) or handshake lines I absolutely need to provision on the ESP32 side?

2. Firmware Storage and Loading
I’m unclear on the ST85MM boot process regarding flash memory.

  • Does the ST85MM typically run from its own internal flash, or does it require an external flash chip?

  • Host Loading: Is it possible (and practical) for the ESP32-C6 to hold the ST85MM binary image and load it into the ST85MM RAM at every boot? Or is it standard practice to give the ST85MM its own dedicated external flash?

  • If I use external flash for the ST85MM, can the ESP32-C6 act as a passthrough programmer to update that flash?

3. Interaction
Once the system is running, how does the host typically poll for Meter frames? Is there a specific host interface protocol document I should be looking at for the packet structure between the Host (ESP32) and the Modem (ST85MM)?

Any schematics, explanation of the ST8500/ST85MM differences, or pointing me toward any code examples would be greatly appreciated!

Thanks in advance.

2 replies

Didier HERROUIN
ST Technical Moderator
June 12, 2026

Dear Lorenzo,

ST85MM is a subset of ST8500 (same package, same pinout, same I/F), but some HW modifications has been added to be compliant to MM standard.

Only UART interface can be used to communicate with ST85xx. No flow control is required.

SPI interface can be optionally used if the FW is loaded in an external Flash memory : based on BOOT pins level at power-on, the ST8500 boots from its serial flash or from UART. Your suggestion to hold the binary image inside ESP32-C6 and load it at every boot is correct.

For ST8500, FW and full documentation are available at st.com, at evaluation kit page : EVLKST8500GH-2 | Product - STMicroelectronics

As MM is not an open standard, please open an OLS ticket at st.com to get the relevant support from ST experts.

 

Best regards,

 

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question.
Andrew Neil
Super User
June 12, 2026

An important thing to remember is that the ST85MM - like any other device neither knows nor cares what microcontroller you use.

So long as your host can support the comms defined in device’s datasheet, it is irrelevant to the device what that host is 

  • A UART interface is a UART interface - not dependant on any particular microcontroller
  • An SPI interface is an SPI interface  - not dependant on any particular microcontroller

 

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.