Support alloc caps in esp_encrypted_img (IEC-415) #612
Description
Is your feature request related to a problem?
I am experiencing some kind of memory corruption when using esp_encrypted_img on esp32s3 with SPIRAM.
In a nutshell, it happens randomly that the decryption produces incorrect bytes. For the following code:
esp_encrypted_img_decrypt_data(self->m_decrypt_handle, &pargs);if we inspect the decrypted bytes in pargs.data_out and compare that with the original plaintext firmware, we will see the following example discrepancies randomly.
# 1st column = address in file, 2nd+ columns = corresponding bytes
# original plaintext firmware
- 0079620 0710 0460 0122 048a 0136 04c1 010e 04cf
- 0079630 0001 04c0 04d0 0144 0561 0426 0000 0000
# decrypted firmware
+ 0079620 0027 0000 0027 0000 0026 0000 0026 0000
+ 0079630 0026 0000 0026 0000 0025 0000 0025 0000and thus at the end of the OTA update that will result in a esp_image: Checksum failed. error.
Describe the solution you'd like.
After some investigation I suspect it is related to a bug in SPIRAM, and people suggest using internal RAM to workaround the issue. So I went on replacing all malloc, realloc & calloc calls in esp_encrypted_img.c with the heap_caps_* counterpart and MALLOC_CAP_INTERNAL, and that seems to fix the issue as it has been working perfectly for me so far.
So, I would like to suggest exposing a configuration to control where the memory should be allocated.
Describe alternatives you've considered.
No response
Additional context.
No response