esp_hosted_fg:STM32 can not communicate with ESP32C3

[gavin-hy]

Refer to the cloned code on github, and after allowing it, the printed LOG is as follows,

ESP_Hosted.zip Host chip is stm32f407 ESP32C3 image is ESP-Hosted-FG-release_0.0.5

[gavin-hy]

After the STM32 was reset, the information captured by the instrument was as follows， The connection should be fine,，SPI mode is 2. Now I don't know why we can't communicate!

[mantriyogesh]

We will check into this. Can you please try spi mode 1? https://github.com/espressif/esp-hosted/issues/334

[gavin-hy]

I tried to switch SPI mode to 1,Still unable to communicate, Here is the ESP32C3's log, only when the STM32 is reset does the ESP32C3 receive a packet of data, but this packet of data is problematic and is discarded.

[mantriyogesh]

1. have you added resetpin?
2. Is this issue only while ESP32-C3 getting reset because STM32 is resetting?
3. Are you able to get it working in first run?

[mantriyogesh]

The textual full logs at host and slave would be much appreciated.

[gavin-hy]

1.yes,I used one of the pins of the STM32 to control ESP32C3 reset. 2&3.The above log is after the STM32 reset, and since it cannot communicate properly, it is also like this after the simultaneous power-up, I think this phenomenon indicates that they did not communicate successfully.

Slave LOG: Host LOG: The Host Code ESP_Hosted.zip

[mantriyogesh]

can you please push your code somewhere in GitHub?

[gavin-hy]

can you please push your code somewhere in GitHub?

yeah, git@github.com:gavin-hy/ESP_Hosted.git

[mantriyogesh]

host log, 'Queue receive fail!', doesn't lead to anything meaningful. please check comment here: https://github.com/espressif/esp-hosted/blob/5144a28e15e555fed0230e169b70f8a94d9d08a7/esp_hosted_fg/host/stm32/driver/transport/spi/spi_drv.c#L793-L802

probably you can comment that log as such.

[mantriyogesh]

Oh! I meant code and not the zip!

are you seeing any race as such that after reset, tthe ESP not yet ready but host about to start the transaction?

esp_hosted_fg/host/stm32/app/app_main.c:

    /* stop spi transactions short time to avoid slave sync issues */
    hard_delay(50000);

What I meant, Is this delay less for you?

[mantriyogesh]

Although, ESP-IDF release/v4.4 should work (as per your log), I think later, you can move to release/v5.2 branch.

[mantriyogesh]

by https://github.com/espressif/esp-hosted/issues/339#issuecomment-1953399375,

I understand, that you are not able to make any single successful transaction from host to slave.

We had created a porting guide for Linux. Although yours is MCU, but spi transport related things still may be applicable. Linux porting guide

It is important to verify the SPI transactions are fine and the GPIOs used are verified to be working, at first.

[gavin-hy]

1.The host log, 'Queue receive fail!', as you said, added there! 2.The code has been uploaded to the repository. 3.Does the version of esp-idf have an effect on the slave? Below is a diagram of the hardware connection:

[mantriyogesh]

1. This log will just hit almost all the times. remove it. SPI is full duplex. When either party doesn't have anything to send (basically, only rx is valid), then it will just send a dummy data. Please check above comment for details and remove such print added.
3. I needed the picture of actual setup.

[gavin-hy]

Thanks for your replay, I made a low-level mistake where I mistook the MISO and MOSI pins of the ESP32C3 for the two being reversed, It's working now!

[mantriyogesh]

As you have this worked out, I think you can check the branch, https://github.com/espressif/esp-hosted/tree/feature/esp_as_mcu_host

This branch offers easy port layer and lwip out of the box, stable. But let me remind, some changes might be needed for STM32, as originally this branch has intention to work with any ESP as slave and any ESP as host. There are also many bugfixes we added into this branch, which lack in Master's MCU.

Some changes like esp_wifi_remote is available, so any esp_wifi_connect() to be used as esp_hosted_wifi_connect(). Similarly, esp_wifi_XXX() to be re-used as esp_hosted_wifi_XXX().

[gavin-hy]

@mantriyogesh Thaks for your advice, I'll test it!

[mantriyogesh]

I would highly suggest to back up your current work / workplace (as some baseline) first.

May be worth to try the new branch with ESP-ESP first, to have look and feel and then try integration. It is going to be not very straight forward as SPI porting at host would be needed.

[mantriyogesh]

just for reference, so that you are not lost, esp_wifi_remote_21feb23.tgz

But esp_wifi_remote just thin layer which just re-routes the function requests to specific calls. basically, esp_wifi_remotte could be bypassed (or retained if you seem useful)

[gavin-hy]

As you have this worked out, I think you can check the branch, https://github.com/espressif/esp-hosted/tree/feature/esp_as_mcu_host

This branch offers easy port layer and lwip out of the box, stable. But let me remind, some changes might be needed for STM32, as originally this branch has intention to work with any ESP as slave and any ESP as host. There are also many bugfixes we added into this branch, which lack in Master's MCU.

Some changes like esp_wifi_remote is available, so any esp_wifi_connect() to be used as esp_hosted_wifi_connect(). Similarly, esp_wifi_XXX() to be re-used as esp_hosted_wifi_XXX().

I downloaded the code from this branch and noticed quite a lot of differences compared to the master branch. Many names have been changed, for example, 'ctrl' has been changed to 'rpc', and there's additional control over the state of the slave devices. I'm wondering if these changes will be integrated into the MCU in the future. I believe that compared to using ESP to control another ESP, controlling the ESP32 series with a general MCU might be more common.

[mantriyogesh]

That's right. Your observations hold true.

Your comment about some other MCU as host is also equally correct expectation. But allow me let you know why we chose ESP as host.

Choosing of ESP itself was not our first choice, but result of experience. We used to use stm32 earlier (and still support), as you can see in master.

The problem with that approach is by the time we evaluate some stm32, other stm32 evolves. And worst part is they both may not abide similar hardware and software.

With Esp32xx series, we can easily demonstrate all the possible features anyone can get. I think Raspberry 2040 may be one such MCU we can try.

But anyway, this new branch would be much usable, as port later should be only the part where variable be, for any MCU.

In summary, reason to choose Esp32xx as host:

1. All features will be supported (I just remembered the stm32 we chose had sdmmc but no sdio, which made our life and even evaluation a hell)
2. Easy to manage, debug, fix
3. No risk of software/ hardware future support
4. Easy demonstration
5. Third party MCU can just implement port later and get it working

Do let us if you have any better ideas/questions.

[mantriyogesh]

Also appreciate your time and efforts to get through this branch.

Please note feature/esp_as_mcu_host branch is much ahead in terms of fixes and the way code should work.

For example, you can These fixes can still be picked and used in MCU. But might take some good time. So better to use the new branch.

Also, some people already have done Porting to their MCUs with this branch (specially STM32), which you can search in the issues page.

[mantriyogesh]

Can we please close this issue?

[gavin-hy]

Can we please close this issue?

yes, please close it! Thank you!