STM32F4 SPI + ESP32_S3 FG communication issue

[czagaadam]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Provided a clear description of your suggestion.
• Included any relevant context or examples.

Issue or Suggestion Description

Can someone help how to proceed with STM32F4 SPI + ESP32_S3 FG firmware implementation?

Where I stuck:

I generated a normal STM32F4 (STM32F407VGTX) project with CubeIDE which includes:
SPI1, UART5, FREERTOS(CMSIS_V1), + CS, RESET, HANDSHAKE, DATA READY pins.

I followed the guide and put everything together in cube IDE.
I can compile the firmware but I think I missed something or do not understand something well.

So my main.c contains this:

I removed freertos.c file and I'm using the MX_FREERTOS_Init implementation from app_main.c

Running the application and putting a break point in MX_FREERTOS_Init in from app_main.c:
For me the value of transport_driver_event_handler looks strange:

Storing the event handler in transport_init in spi_drv.c

Continue running the application:
I'm getting an ESP-Hosted for ESP32-C2/C3/C6/S2/S3 message in CoolTerm, but error from ESP
E (144959) SPI_DRIVER: rx_pkt len+offset[131070]>max[1600], dropping it
and threads seems to be blocked

Modification:
I made a small modification in spi_drv.c I had to comment out these lines because application thinks STM32 is connected to a ESP32 instead of ESP32_S3:

If I uncomment them in CoolTerm I'm getting:
ESP-Hosted for ESP32 message instead of ESP-Hosted for ESP32-C2/C3/C6/S2/S3
and no error message from ESP, but I'm using ESP32_S3

Do I have to run any default task in MX_FREERTOS_Init in from app_main.c: ?
Why application thinks it is an ESP instead of ESP32_S3?
Why I'm getting this error: E (144959) SPI_DRIVER: rx_pkt len+offset[131070]>max[1600], dropping it

Thank you!

[mantriyogesh]

Did you use master code base or feature/esp_as_mcu_host branch?

[czagaadam]

Did you use master code base or feature/esp_as_mcu_host branch?

Do you mean in this esp-hosted repository ?
I'm using all of these files under esp_hosted_fg:

and calling MX_FREERTOS_Init from app_main.c in my main.c generated by CubeIDE

They are linked in my CubeIDE project:

For ESP I just pulled the esp-idf and did the export.ps1 stuffs...

[mantriyogesh]

can you hold up till 15 nov?

We are porting the https://github.com/espressif/esp-hosted/tree/feature/esp_as_mcu_host which is dedicated for mcu, by 15 nov.
this would be better experience and better integration for mcu like stm32 (we are trying to get specific stm32h7 ported for host, which could be referred for your stm mcu host)

to answer your original question, you shouldn't need to replace the file on your own. ideally the https://github.com/espressif/esp-hosted/blob/master/esp_hosted_fg/host/stm32/proj/prepare_project.bat should have done. but check the https://github.com/espressif/esp-hosted/blob/master/esp_hosted_fg/docs/MCU_based_host/Getting_started.md for all the details, how it should be used..

[czagaadam]

hi,
that project seems impressive I'll take a look of that on 15th of nov but until that I don't want to give up.

I've used that bat file and I followed the guide, all the symbols,path and build variables are set.
If I call directly control_path_init(control_path_event_handler); it is listing the proper configuration.

I think the issue is somewhere with SPI communication:
E (25743) SPI_DRIVER: rx_pkt len+offset[131070]>max[1600], dropping it
It's like ESP throwing the SPI message because it's tool long or not compatible.
In STM side the SPI buffer size is set
#define MAX_SPI_BUFFER_SIZE 1600

Can you help what this error message is referring to exactly ?

[mantriyogesh]

Spi buffer size is expected to be 1600 bytes only, both the sides.

The log shows that the spi communication is not correct. Basically you can lower the frequency for spi and cross check if you have same spi mode in use.

If you are using jumper wires, ensure you use good, equal lengthed (<cm) wires.

The bytes interpreted are shifted bytes.

[czagaadam]

Thanks for your support!
Sorry for late answering, a few days ago I was managed to make it work:
I regenerated the whole CubeIDE project and did again the whole ESP source compilation stuff and also the SPI frequnecy was lowered. It was working but it was very unstable because of the jumper cables and it was running on the lowest SPI clock.

So finally I soldered the necessary pins with good quality wires, with this the SPI speed can be increased.

My question now, how can I extend the STM firmware with my code ?
Should I use the following function:
stm_ret_t send_to_slave(uint8_t iface_type, uint8_t iface_num, uint8_t * wbuffer, uint16_t wlen) ?
It seems it's adding a interface_buffer_handle_t message to the to_slave_queue queue.
And should I call the send_to_slave in a new thread?

[mantriyogesh]

Hello @czagaadam , it looks like you are using master branch right now.

We are going to a friendly port, which we also plan to test on sample stm32 (h7), over MCU only branch, at https://github.com/espressif/esp-hosted/tree/feature/esp_as_mcu_host. Most probably by Mid November.

This change would have offer the easier port layer, with easy sample network stack integration.
Would it be worth for waiting in my opinion, but if you wish to still continue on master (which we plan to deprecated once the above port is available on above dedicated MCU branch), please let us know.

Finally, please I would like to add, all the efforts by now you have put are not totally waste. In fact, the changes and verification method would in fact would be helpful, suppliment and also comparable at some places. Please let us know what you think ahead.

[RaboLab]

Hi @mantriyogesh , I'd like to know if the friendly port on the MCU only branch, which was planned to be completed by mid-November, has been delayed or rescheduled? If possible, could you let me know the expected completion time or pre-release date? I am currently in a critical hardware selection phase, so getting this information is very important to me.
I don't mean to rush you, just for getting info. And I appreciate all the hard work you have put into this project!

[mantriyogesh]

Hello @RaboLab ,

Sorry, I lost track on this.
We have done stm32-h7 port already, which works fine with lwip and iperf.

But it is not yet integrated into the github, as we need to test and support esp without any issues.
If you wish to evaluate, I can send you the code for your test.
Please send me mail (my mail id is on my profile) from mail id, which you wish to use as login mail id.

[RaboLab]

Hi @mantriyogesh ,
I have contacted you through the email 1815**85@qq.com, please check your inbox.

I appreciate your generous help!

[czagaadam]

Hi again @mantriyogesh !
Hope you are fine, I'm seeing you have a progression with stm32 hosted esp.
I've also contacted you in mail, can you please send me a code for testing.
Thank you very much!

[jnmar]

Hi @mantriyogesh ,
I am also interested in the STM32H7 port. Has the github repository been upgraded ? Or shall I contact you by email ?
Thanks in advance !

[mantriyogesh]

github push would take some time. Kindly send a mail, I will send you the details.

[mantriyogesh]

STM32 Host with SPI Transport for ESP Co-Processors

This repository demonstrates using an STM32 microcontroller as the host for SPI communication with ESP co-processors. It includes LwIP integration and iperf2-based testing.

---

Code Structure

• Slave Code: Located in <repo>/slave
• Host Code:
  • STM32 examples: <repo>/host/port/stm32/examples/wifi_iperf

---

Documentation References

• Slave Flashing: docs/spi_full_duplex.md#7-flashing-the-co-processor
• Host Flashing: README.md#11-stm32-example

---

Supported Features

• Slaves Supported: ESP32, ESP32-C2, ESP32-C3, ESP32-C5, ESP32-C6, ESP32-S2, ESP32-S3
• Slaves Tested: ESP32, ESP32-C6, ESP32-S3
• Transport Supported: SPI full-duplex
• Host Code: Independent of ESP-IDF on the host side
• Networking: LwIP stack integration

Note: This repository does not support SDIO or BLE transport.

---

Hardware Connections

Connect STM32 and the ESP co-processor as follows:

• SPI Lines: MISO, MOSI, SCLK, CS (4 GPIOs)
• Control Lines:
  • Handshake
  • Data Ready
  • Slave Reset
• Ground: Shared ground(s)

Total GPIOs required: 7 + Ground(s).

---

Main Repository Note

The main repository supports:

• ESP devices as hosts
• Multiple transport options (including SDIO and BLE)
• Higher throughput configurations (e.g., SDIO)

This STM32-focused repository is limited to SPI transport and does not include SDIO or BLE support. Future updates may integrate SDIO transport, but there is no current plan for this addition.

[mantriyogesh]

esp-hosted-stm32-spi-prerelease.zip