devlat wrote: ↑

Sun Jan 14, 2024 9:03 am

Can you please describe in more details your OTA procedure?
I agree with you that Espressif pre-encrypted method is overkill if you already have generated own flash encryption keys.

You can duplicate the OTA procedure and switch to use esp_partition_write_raw to write the encrypted data.

Instead of input mode with pull up, just before reset, I set it to output mode and set 0 to high. That seems to solve the false detection.

Well, I switched back to factory detection, since the app wouldn't programmatically switch to the test partition for booting. Now I am getting false positive on factory condition detected. I also noticed it happens consistently when doing a reboot from within app, which is calling "ESP.restart()". I...

Since I changed to the boot to trigger the test app partition, I changed the corresponding code in my app to allow the user to manually change to this as the boot partition. The operation reports success, but on reboot, it continues to boot my app0 partition. So after a successful change, I tried to...

Enabled the pull up, and it seems to have helped. Recent crashes did not affect the boot process.

The two boards are not the same. On the custom board with ESP-WROOM-32E, IO0 is only exposed to serial header as DTR for programming. I do have that hooked up via Serial2USB module during development for these runs. On the board with the NodeMCU Devkit with 32E, IO0 goes to level shifter input so it...

In case of application problems, I want the user to be able to boot to a factory application, where application firmware can be updated. I thought I may as well re-use the button already on IO0, but have been getting spurious detection. I first tried the factory configuration, and now switched to th...

having flash as a source is an uncommon enough scenario Huh? Where else would a pixmap image come from? It would always originate in flash. Yeah, I was surprised to see how the lower level SPI routines are implemented when I investigated further. It seems naive to me, but I guess it's up to the end...

It looks like setup_priv_desc will malloc dma'able memory, because my image comes from FLASH. That appears to be where the likely failure occurs. I decided to do a test, and I set up a single frame buffer in dma'able memory and copied from my image in FLASH to my own buffer, and then called pushImag...

I output the minimum and current heap size available before each invocation, and there is 60K free. I thought it might be 8-bit accessible related, but checked heap_caps_get_free_size(MALLOC_CAP_8BIT) and it is also 60K. Is the SPI API doing something unusual with memory usage that causes this? It s...