ESP32 on Zephyr: Writing firmware chunks to flash for FOTA causes hard faults (using MCUBoot and wifi TCP connection)
Posted: Tue Jul 02, 2024 7:57 am
Hi all,
We're trying to do FOTA over Wi-Fi using an ESP32 with Zephyr. The firmware chunks are received over Wi-Fi from a TCP connection. This firmware is received in messages of 512 bytes of which there are about 1300 in a firmware package.
Directly after receiving a package, the received bytes are stored into flash using the flash_img_buffered_write() zephyr api.
What we have seen is that the system sometimes suffers from a hard-fault during this process. After a seemingly random number of messages, the hard-fault handler is triggered with an invalid program counter (PC) and invalid stack trace. This happens about every 1 in 3 times of trying to perform FOTA.
It looks like that if the 'flash_img_buffered_write' line is commented out, the downloading and processing (up until the writing to flash) the FOTA process works as it is supposed to work and finishes every time. It is however not certain this command is the problem. We're using MCUBoot to handle the firmware update.
Can somebody help us to find our issue?
We're trying to do FOTA over Wi-Fi using an ESP32 with Zephyr. The firmware chunks are received over Wi-Fi from a TCP connection. This firmware is received in messages of 512 bytes of which there are about 1300 in a firmware package.
Directly after receiving a package, the received bytes are stored into flash using the flash_img_buffered_write() zephyr api.
What we have seen is that the system sometimes suffers from a hard-fault during this process. After a seemingly random number of messages, the hard-fault handler is triggered with an invalid program counter (PC) and invalid stack trace. This happens about every 1 in 3 times of trying to perform FOTA.
It looks like that if the 'flash_img_buffered_write' line is commented out, the downloading and processing (up until the writing to flash) the FOTA process works as it is supposed to work and finishes every time. It is however not certain this command is the problem. We're using MCUBoot to handle the firmware update.
Can somebody help us to find our issue?