Push an update over SDIO (EHM-80)

[savenlid]

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

I have P4+C5

As I understand the update of the C5 would have do be done physically or over WIFI-OTA.
I would like to push an update to C5 from P4, via "normal" hosted functions.

P4 has ethernet interface and "USB-tcpip", also for a lot of other reasons it makes more sense for the P4 to push it.
P4 is more suited as the "core" to deal with updates, its the "master" with respect to the C5.
It can decrypt the image and do other stuff, version checks, etc etc,

If I have misunderstood something ( happens often ) I will stand corrected.

Use cases

Let P4 push the C5 update
C5 in this case only being a wifi slave.

Alternatives

No response

Additional context

No response

[mantriyogesh]

graph TD
    A[HTTP Host Server] -->|Image Chunk| B[ESP Slave C5/C6 WiFi]
    B -->|Image Chunk| C[SDIO Interface]
    C -->|Image Chunk| D[P4 Processor]
    D -->|Image Chunk| E[ESP Slave C5/C6]
    E -->|Image Chunk| F[ESP Flash]
    
    F -->|Check| G{Whole Image Complete?}
    G -->|No| A
    G -->|Yes| H[Transfer Complete]
    
    style A fill:#e1f5fe
    style F fill:#f3e5f5
    style H fill:#e8f5e8
    style G fill:#fff3e0

Loading

Do you want this? Please check https://github.com/espressif/esp-hosted-mcu/blob/main/docs/esp32_p4_function

Here, chunk-by-chunk, part of the C5/C6 slave image would be taken from the HTTP host server to C5 Wi-Fi to SDIO to P4, and P4 would push that chunk to ESP and then go to ESP flash till the whole image is not pushed.

[savenlid]

Hi,

Not sure I understand exactly what the picture decipts.

What I want to achive.

#1, P4 sits on a newer C5 image in its littlefs flash-disk-partition, we don't care about how it came there, we just assume its there.
#2, via your hosted-sw I want to push this "P4-residing" image onto the C5 and upgrade it.

ps
typcially the image came to P4 via one of the below methods.
#1 via usb-memory-stick.
#2 via ethernet cabled port.
#3, via usb-netif-ncm, a laptop using a web-broswer uploading it to P4.
#4, down load via hosted-wifi.
#5, part of a complete P4 update, embedded into the littlefs-partition
ds

[mantriyogesh]

Currently, this feature is not available. We plan to enable the host to trigger slave firmware flashing on boot if a version mismatch occurs. P4 flash would include a dedicated partition for the slave firmware. However, this is not scheduled for implementation in the near future.

[savenlid]

Let me see if I understand your plans

You have 2 "slots" for FW on the C5/slave.
Active / Inactive.
If the inactive contains a newer firmware you swap to it at boot ?

Correct ?

If so, how do the new FW get into this inactive slot ?

It would be a bit unfortunate if its only possible via its own Wi-Fi.
Because Wi-Fi is not always connected (maybe not even enabled) and yet we want to keep FW up-to-date.
It may include security updates, and to pass regulations today and in the future is quite strict.

[mantriyogesh]

If the inactive contains a newer firmware you swap to it at boot?

Actually, if you're asking about the slave side (c5), it already has two OTA partitions

esp-hosted-mcu/slave/partitions.esp32c5.csv

Lines 6 to 7 in 0b5b8aa

	ota_0,app,ota_0,0x10000,1536K,
	ota_1,app,ota_1,0x190000,1536K,

.

The API,

esp-hosted-mcu/host/api/include/esp_hosted_ota.h

Line 32 in 0b5b8aa

esp_err_t esp_hosted_slave_ota(const char* image_url);

, is public and included when esp_hosted.h

esp-hosted-mcu/host/esp_hosted.h

Line 18 in 0b5b8aa

#include "esp_hosted_ota.h"

is used.

The slave OTA function is invoked from

esp-hosted-mcu/host/port/esp/freertos/src/esp_hosted_ota.c

Lines 243 to 247 in 0b5b8aa

	#if OTA_FROM_WEB_URL
	return esp_hosted_slave_ota_chunked(image_url);
	#else
	return esp_hosted_slave_ota_whole_image(image_url);
	#endif

.

OTA_FROM_WEB_URL is enabled, so it would call esp_hosted_slave_ota_chunked(image_url).

If the image is large enough, it needs to be flashed on the slave by sending it part by part over SDIO, regardless.

These two calls differ only in the higher layer, specifically how the part is obtained. esp_hosted_slave_ota_chunked retrieves it via HTTP, whereas esp_hosted_slave_ota_whole_image() assumes the full image is stored locally on the slave.

Q. Why is esp_hosted_slave_ota_whole_image() disabled or unused?
A. We don't currently store the image, but this is a legacy function from when Linux was the host.

Basically, once P4 stores the full slave image in a new flash partition, we can retrieve it and flash it over SDIO.

Now, consider

esp-hosted-mcu/host/port/esp/freertos/src/esp_hosted_ota.c

Lines 204 to 238 in 0b5b8aa

	static esp_err_t esp_hosted_slave_ota_whole_image(const char* image_path)
	{
	FILE* f = NULL;
	char ota_chunk[CHUNK_SIZE] = {0};
	int ret = rpc_ota_begin();
	if (ret == ESP_OK) {
	f = fopen(image_path,"rb");
	if (f == NULL) {
	ESP_LOGE(TAG, "Failed to open file %s", image_path);
	return ESP_FAIL;
	} else {
	ESP_LOGV(TAG, "Success in opening %s file", image_path);
	}
	while (!feof(f)) {
	fread(&ota_chunk, CHUNK_SIZE, 1, f);
	ret = rpc_ota_write((uint8_t* )&ota_chunk, CHUNK_SIZE);
	if (ret) {
	ESP_LOGE(TAG, "OTA procedure failed!!");
	/* TODO: Do we need to do OTA end irrespective of success/failure? */
	rpc_ota_end();
	return ESP_FAIL;
	}
	}
	ret = rpc_ota_end();
	if (ret) {
	return ESP_FAIL;
	}
	} else {
	return ESP_FAIL;
	}
	ESP_LOGE(TAG, "ESP32 will restart after 5 sec");
	return ESP_OK;
	ESP_LOGE(TAG, "For OTA, user need to integrate HTTP client lib and then invoke OTA");
	return ESP_FAIL;
	}

. This function is much simpler to understand.

You can think of rpc_ota_begin() as translating an RPC procedure that calls esp_ota_begin() on the slave. Similarly, rpc_ota_write() translates to esp_ota_write(), and rpc_ota_end() translates to esp_ota_end().

In essence, the lower part of OTA remains the same.

esp-hosted-mcu/host/port/esp/freertos/src/esp_hosted_ota.c

Lines 217 to 226 in 0b5b8aa

	while (!feof(f)) {
	fread(&ota_chunk, CHUNK_SIZE, 1, f);
	ret = rpc_ota_write((uint8_t* )&ota_chunk, CHUNK_SIZE);
	if (ret) {
	ESP_LOGE(TAG, "OTA procedure failed!!");
	/* TODO: Do we need to do OTA end irrespective of success/failure? */
	rpc_ota_end();
	return ESP_FAIL;
	}
	}

assumes it reads from a file. If you replace these read/write functions with SDMMC-based read/writes, it will work the same way.

It may include security updates, and to pass regulations today and in the future is quite strict.

We’ve considered this, and some changes are underway to automatically identify the slave’s version and allow the user to handle incompatible versions. Currently, we plan to add warnings, with potential future features like automatic slave updates if available.

[savenlid]

This seems to do it, also over sdio but only p4+c6

C5 not fully supported yet.

If it could co-exist somwhow with hosted, or toggie over.

https://components.espressif.com/components/espressif/esp-serial-flasher/versions/1.9.0

[mantriyogesh]

This seems to do it, also over sdio but only p4+c6

The ESP-hosted OTA is agnostic of the slave used. It doesn't matter if C5 or C6 or any other slave is in use.

C5 not fully supported yet.

If any issues you faced, please let us know.

If it could co-exist somwhow with hosted, or toggie over.

I did not understand your query correctly. Can you please clarify whether you want to use the ESP32-P4-Function-Ev-Board with ESP32-C5?

esp-serial-flasher

The esp-serial-flasher simplifies the flashing process and consistently performs reliably over UART, regardless of your ESP-Hosted configuration, provided that the same GPIOs are not utilized. Regarding SDIO-based over-the-air (OTA) updates, we do not utilize the SDIO stub from esp-serial-flasher project, as it is unnecessary. We have already established a fully functional SDIO slave for ESP-Hosted as the transport mechanism. This allows us to use the same transport for all communications, including OTA packets.

Do let us know if there is any further confusion or any issues that you face while using the OTA.

[savenlid]

P4+WIFI
Its not realistic when you deliver to an industry customer to rely on a Wi-Fi infrastructure and a hosted image to do an upgrade.
Even for domestic customer its not good.
That's is great for the lab during development, but not for the field.

P4 has ethernet, and USB , in many cases Wi-Fi is not even enabled.
An industry customer will not host an image on their network, they will certainly not let you access the www.
And who should update the image in the customer network?
It just wont fly.

Still C5/C6/C61 must be upgraded.
I had to modify my PCBA to be able to upgrade serially,

https://github.com/espressif/esp-serial-flasher

Luckily I had the extra pins on the P4.

Now lets hope the hosted-code will not interfere if Wi-Fi is not started, so P4 can do the upgrade.
We will see, new PCBA back in 3 weeks.

[mantriyogesh]

Hello @savenlid,

Thank you for raising this important point.

The OTA code is fairly simple and straightforward. In fact, an OTA example without Wi-Fi (where the host contains the slave image) is also available in Linux here:
esp-hosted test_utils.c (example)

That said, I acknowledge that on P4 we have not yet ported this non-Wi-Fi solution. The P4 can host the C5/C6/C61 image, and we can re-use the code from here:
esp-hosted-mcu host OTA support

Please allow me some time to add this example. As you stressed, it is a common use case and we should support it properly.

I also completely understand your point about using ESP32-P4 without Wi-Fi in industrial scenarios. Honestly, we did not anticipate that ESP-IDF itself doesn’t have a direct solution for this yet.

One clarification: when you mentioned -

"Now lets hope the hosted-code will not interfere if Wi-Fi is not started, so P4 can do the upgrade"*

could you elaborate a bit more on this concern? Do you mean possible side-effects from the hosted stack initializing Wi-Fi components even when not used?

Thanks again for your feedback — it helps us prioritize real-world cases like this.

[savenlid]

Thank you for you continued support @mantriyogesh

Its the "EN" pin on the C5, that P4 internally will share.

Shared by the wifi-hosted-code and shared by serial-flasher-code.
Shared resource this pin.

During serial-flash-sw use I must be sure that wifi-hosted-sw "backs-off", stands-back.
I assume, disabling the wifi will be enough for it to not touch the "EN" pin ?

GPIO28, RXD0, TXDO the other 3 pins from C5 belongs to the serial-upgrader alone.
So they are fine.

BTW:
Not sure if there is an option in the esptool.py to assert / release the reset "EN".

It would help useful to be able from the "usb-dongle" to manipulate the reset signal without flashing.
there is --before, --after options
they relate to what you do when flashing.

but without doing any flashing at all.

esptool.py reset_assert
esptool.py reset_release

would be nice commands.

also
idf.py monitor (without doing reset ) would be nice
Maybe its possible, I have not double checked.

Thanks again.
/Nicholas

[mantriyogesh]

Oh I now got your question. You had send me an mail. Which I drafted half answer, but I need to verify this at my end what would be stable way that I can propose. Steps for flashing as the same, flash the c5 first but while doing so, P4's EN pin should be in correct state. if for some reason however P4 crahed or reset, it can still reset the C5 on-bootup. but this is corner case anyway. So, holding P4 'slave-reset' pin high, Flashing c5 , unhold the p4 slave reset pin, flash p4 should do the trick. but I need to verify this.

But anyway, there is entry in the serial flashing how to keep P4 not interrupting the slave while flashing (here

I assume, disabling the wifi will be enough for it to not touch the "EN" pin ?

ideally, if this code for SDIO is not run (indirectly through other function calls), the P4 should not manipulate the slave EN.

esp-hosted-mcu/host/drivers/transport/sdio/sdio_drv.c

Lines 1410 to 1420 in a0767ca

	static esp_err_t transport_gpio_reset(void *bus_handle, gpio_pin_t reset_pin)
	{
	g_h.funcs->_h_config_gpio(reset_pin.port, reset_pin.pin, H_GPIO_MODE_DEF_OUTPUT);
	g_h.funcs->_h_write_gpio(reset_pin.port, reset_pin.pin, H_RESET_VAL_ACTIVE);
	g_h.funcs->_h_msleep(1);
	g_h.funcs->_h_write_gpio(reset_pin.port, reset_pin.pin, H_RESET_VAL_INACTIVE);
	g_h.funcs->_h_msleep(1);
	g_h.funcs->_h_write_gpio(reset_pin.port, reset_pin.pin, H_RESET_VAL_ACTIVE);
	g_h.funcs->_h_msleep(1200);
	return ESP_OK;
	}

I am adding the example for slave OTA using the reserved slave image partition inside P4, i will test these as part of this example and let you know next week.

[mantriyogesh]

wifi init is hooked to start the esp-hosted code, if you are aware of.

esp-hosted-mcu/host/api/src/esp_hosted_api.c

Lines 191 to 195 in a0767ca

	esp_err_t esp_wifi_remote_init(const wifi_init_config_t *arg)
	{
	ESP_ERROR_CHECK_WITHOUT_ABORT(esp_hosted_reconfigure());
	check_transport_up();
	return rpc_wifi_init(arg);

the esp_hosted_reconfigure (indirectly executes above code) is responsible for slave reset, so that slave would be in correct state on host loading of esp-hosted.

so if you do not do wifi init, then slave flashing should not be interrupted, IMO. (still i need to test and then confirm on this..)