User controlled initializing and deinitializing (EHM-51)

[renzenicolai]

Feature description

Firmware that makes use of patched esp-hosted demonstrating the use case: https://github.com/Nicolai-Electronics/tanmatsu-launcher/

For my application I would like to be able to recover from situations where the slave ESP32 radio is unreachable. For this being able to test whether or not the slave ESP32 works before starting ESP-HOSTED is a must have.

Currently I have made the following changes to the version of ESP-HOSTED in my project:

• Remove the constructor and destructor attributes from the init and deinit functions in esp_hosted_host_init.c (headers should be added to allow the user application to manually call these functions)
• Replace the ESP_ERROR_CHECK macros in hosted_sdio_card_fn_init (sdio_wrapper.c) with return on error statements

By doing this the user can:

• Test if the radio is working by first calling hosted_sdio_init followed by hosted_sdio_card_init
• If this succeeds esp_hosted_host_init can be called to start WiFi

In general I would appreciate it a lot if the use of ESP_ERROR_CHECK in ESP-HOSTED could be limited to an absolute minimum. Please just return esp_err_t error codes so that the user application can handle errors gracefully.

Use cases

Detection if the radio is working so that the product can re-flash the radio module without the firmware crashing before app_main gets called.

Alternatives

No response

Additional context

If calling hosted_sdio_card_init returns an error my firmware will restart the esp32-c6 module in bootloader mode and load firmware onto it. Currently we use the serial port of the esp32-c6 for this (github.com/badgeteam/esp32-component-esptool).

If possible we would like to re-flash the esp32-c6 module via sdio but no documentation for the sdio bootloader protocol is currently available. If possible we would like to receive such information so that we can implement a component for flashing the esp32-c6 via sdio instead of serial.

[mantriyogesh]

I would need to have good thought on this, instead of just doing the changes on the go.

I understood the use case you wish to do, and happy that you shared your problems and viewpoints.
Please allow me to spare some time on this and come back.

Although, I have an immediate response for this:

Remove the constructor and destructor attributes from the init and deinit functions in esp_hosted_host_init.c (headers should be added to allow the user application to manually call these functions)

We had given some thought on this.
We are trying to find midway, if this can be done in configurable way.

@SohKamYung-Espressif Adding you for brainstorm on this later

[renzenicolai]

In addition to user controlled initializing and de-initializing it would be very much appreciated if the host component could be reworked so that esp_hosted_host_init returns an esp_err_t value to signal that initializing failed instead of crashing. Currently esp-hosted initializes a thread for the sdio_read_task function which returns without deleting itself if the card_init function fails.

While you can make a freertos task exit without crashing by adding vTaskDelete(NULL); before the return this alone would not be enough to make esp_hosted_host_init handle failure properly. For this I recommend to move the card init function into esp_hosted_host_init to be ran as early as possible as the card init failing is a good indication that the slave radio chip is not functional without having to initialize most of the other parts of the stack.

[mantriyogesh]

You are obsoletely right, agreed upon every word from prior comment.

I will add such a change, but we are in the middle of urgent fixes on other legs this week. I can however concentrate on this next week.