Update IDF Version Problem

[BotondColop]

Hi,

We have some trouble switching between IDF version with an update process. (IDF 4.4.2 -> 4.4.5)

I am using IDF-Version 4.4.2 with ESP32 Wrover Module.

The Flash is encrypted and some different part of Partition too. USB downloading on the release / costumer devices is disabled.
To Update the device, we are using the OTA update function from ESP Standard library. We have two OTA Partitions and no Factory Firmware Partition.

We are planning to use the new IDF Version 4.4.5.

When we update (with OTA Update function) the device with IDF 4.4.5 builded version, we get some troubles.
The bootloader and the partition table are not updated, only the user Firmware.

1. PWM Out is not working. (No error will be generated during initialization - only after activation no PWM Output)
2. NVS Ram some parameters are lost or changed - this is only on very few devices
3. Get some wired logs from efuse:
#

Code: Select all

D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 7 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 8 bit
D (9679) efuse: In EFUSE_BLK0__DATA0_REG is used 1 bits starting with 2 bit
D (9679) efuse: In EFUSE_BLK0__DATA0_REG is used 7 bits starting with 20 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 9 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 7 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 8 bit
D (9679) efuse: In EFUSE_BLK0__DATA0_REG is used 1 bits starting with 2 bit
D (9679) efuse: In EFUSE_BLK0__DATA0_REG is used 7 bits starting with 20 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 9 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 7 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 8 bit
D (9679) efuse: In EFUSE_BLK0__DATA0_REG is used 1 bits starting with 2 bit
D (9679) efuse: In EFUSE_BLK0__DATA0_REG is used 7 bits starting with 20 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 9 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 7 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 8 bit
D (9679) efuse: In EFUSE_BLK0__DATA0_REG is used 1 bits starting with 2 bit
D (9679) efuse: In EFUSE_BLK0__DATA0_REG is used 7 bits starting with 20 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 9 bit
D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 7 bit
D (9689) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 8 bit
D (9689) efuse: In EFUSE_BLK0__DATA0_REG is used 1 bits starting with 2 bit

4. Reading back the push button status. We have a long, short button press evaluation. With IDF 4.4.5, a short keypress always evaluated as a long one. It looks like the

Code: Select all

esp_log_timestamp()

is counting incorrect.

A lot of small problem occur, and they are always different on different devices.

We have been making regular updates with IDF version 4.4.2 for more than a year, and so far we have never had a problem. So, this error only occurs when switching between IDF versions. If we re-flash a firmware that was generated with IDF 4.4.2, all errors will disappear. (except lost data on nvs)

I tested this update on the Development Device - with ota update too - without Flash encryption, I have no troubles till now.

For me ist look like somting with a mix flash encryption and idf version.

Has anyone tried to update IDF version using encrypted firmware? (using esp OTA Update)
Does anyone have experience with how to do this update in a safe way?

Thank you in advance.

Best regards,
Boti

[martins]

Hi, I'm still hestitant to do the update from v4.4.4 to v4.4.5 where one of major changes is chip revision check in bootloader and I have no idea what happens when I OTA update the app on secured devices, that are stuck with v4.4.4 bootloader. And there may be more major changes sice v4.4.2

I'll probably start working on this in upcoming days/weeks, currently just subscribing to this topic.

[BotondColop]

Hi Martins,

I compared the two IDF Versions 4.4.2. - 4.4.5. and it looks like on every bootloader changes was considered the compatibility.

This is the reason why i don't understand why my device getting sometimes crazy.

If I understanding right, you dont need to update "Bootloader" and "Partiontable" and "OTA data init" to change between the 4.4.x to 4.4.y IDF Version. Which is completely clear, there is no major version jump. Only bug fixes were included in the new version.

I have never had a trouble on a not encrypted device (developer devices if i do the smae update process with OTA update)

I'm still looking for this problem, but so far I can't find much.

[martins]

If I understanding right, you dont need to update "Bootloader" and "Partiontable" and "OTA data init" to change between the 4.4.x to 4.4.y IDF Version.

I take it as that if you have fully secured and locked device (secure boot, encryption, uart bootloader disable etc.) you even CAN'T do that, at least not by standard means. But there is usually no need to update the bootloader, and updating parition table is not the best idea unless you really have to. OTA data partition gets updated automatically during OTA process.

Which is completely clear, there is no major version jump. Only bug fixes were included in the new version.

Yea, unless someone optimizes some task size in minor update, which works for examples, but not for your custom app. That happened, now I take even bugfix versions as possibly breaking.

Anyways, just tried quick OTA update of one secured device (flashed with v4.4.4 bootoloader) with v4.4.5 build app and whole process went without issues, device seems to be operating as ussual.

[BotondColop]

Anyways, just tried quick OTA update of one secured device (flashed with v4.4.4 bootoloader) with v4.4.5 build app and whole process went without issues, device seems to be operating as ussual.

We have a defined test process to release a firmware, with different devices. We had no issue at the Company during test and production (only on my release device). Some of our customer from 800-1000 selled product have troubles.

That you have no troubles, that's mean that is not a problem at all.

[BotondColop]

I found this problem, it is an ESP-LOG output when esp_get_flash_encryption_mode() is queried in encrypted release Firmware.

Code: Select all

D (9679) efuse: In EFUSE_BLK0__DATA6_REG is used 1 bits starting with 8 bit