Hosted communication layer recovery (EHM-58)

[udoudou]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Described the feature in detail and justified the reason for the request.
• Provided specific use cases and examples.

Feature description

There are two points in this requirement:

1. There is no communication status monitoring mechanism. The application layer cannot perceive that there is a problem in the communication layer. In the current code, the heart command has been implemented on the slave side. But the hosted side is not yet complete

   esp-hosted-mcu/host/drivers/rpc/wrap/rpc_wrap.c

   Line 307 in 41c47b9

   #if 0

2. There is no usable implementation for restoring communication. For example, esp_hosted_deinit, esp_hosted_slave_reset, etc. are not implemented correctly yet.

Use cases

The slave may restart abnormally due to some faults, or communication may be impossible due to other reasons. The WiFi\BLE function will be abnormal. However, the application layer cannot know that this exception has occurred and perform necessary operations to restore WiFi/BLE.
If an abnormality is detected, the simplest way is to restart the host to recover. This is acceptable for some projects with low requirements. However, for some projects (such as products with HMI screens), restarting the host will significantly affect the user experience. Therefore, it is necessary to be able to restore hosted communication without restarting the host.

Alternatives

No response

Additional context

No response

[mantriyogesh]

There is no communication status monitoring mechanism. The application layer cannot perceive that there is a problem in the communication layer. In the current code, the heart command has been implemented on the slave side. But the hosted side is not yet complete

Yes, the event is not getting subscribed by default for heartbeat.
Although, you can manually subscribe to any event using template below, also applicable for heartbeat:

if (set_event_callback(RPC_ID__Event_Heartbeat,                 my_heartbeat_event_callback) {
  ESP_LOGE(TAG, "event callback register failed for heartbeat event", );
}

Nevertheless, this needs to be enabled in the code, as you had pointed out.

The slave may restart abnormally due to some faults, or communication may be impossible due to other reasons. The WiFi\BLE function will be abnormal. However, the application layer cannot know that this exception has occurred and perform necessary operations to restore WiFi/BLE.

For the same reason, we had provided the ESP_INIT event, here. If the slave is crashed abnormally, host should receive this event. You can use this place as hook to handle any unexpected things. Please be careful that this is rx callback and it should not be blocked or stuck. you can use other synchronisation mechanisms to proceed the handling. for example, semaphore post to your task for any application specific event. you can also trigger 'async' rpc events from the event handlers directly.

If an abnormality is detected, the simplest way is to restart the host to recover. This is acceptable for some projects with low requirements

restarting host seems a very stricter approach as you stated. instead, you can use the init event for hooking to initialisation code flow or some function that you might already have to do application init, including wifi or bluetooth initialisation.

This is kept open ended , to handle the failures as per the expected way to handle.

Therefore, it is necessary to be able to restore hosted communication without restarting the host.

What is the transport you use? Are you able to get log :

esp-hosted-mcu/host/drivers/rpc/wrap/rpc_wrap.c

Line 130 in 41c47b9

ESP_LOGD(TAG, "Received Slave ESP Init");

when changed to

 ESP_LOGI(TAG, "Received Slave ESP Init");

[udoudou]

Currently using spi_hd. From the code analysis, at least the implementation of this transmission method, after the slave restarts, it needs to wait for the host to write SPI_HD_CTRL_DATAPATH_ON to SPI_HD_REG_SLAVE_CTRL before generating Event_ESPInit. So I think theoretically, after the slave restarts, you can't see the print

[mantriyogesh]

@SohKamYung-Espressif , Can you please assess the problem?

[SohKamYung-Espressif]

@udoudou Regarding #55 (comment)

You are correct. Currently, the slave waits for the host to open the datapath before starting communications. This was done to ensure the host is ready to receive interrupts from the slave before the slave asserts the Data Ready signal.

Setting SPI_HD_CTRL_DATAPATH_ON can be ignored by the slave so it can, be default, send the Event_ESPInit upon reset. If the host receives this event, it can use it as an indication that the slave unexpectedly reset.

But changing this sequencing for SPI-HD and testing the slave reset behaviour will take some time, as there are other pending changes to be made to esp-hosted-mcu first.

[mantriyogesh]

@udoudou, Did you get a chance to try the QSPI suggestion by @SohKamYung-Espressif?

[udoudou]

@mantriyogesh @SohKamYung-Espressif I will skip these two loops 1 和 2 . Manually restart C2, and P4 can receive the INIT event. However, it will cause P4 to initiate the first reset of C2 and attempt communication which will fail due to the failure to receive the interrupt. Adding g_h.funcs->_h_post_semaphore(spi_hd_data_ready_sem); here can solve this problem.