ESP32_WROOM firmware boot loop

[aual1780]

Details about Problem

Target: ESP32_WROOM_32

Firmware image version: 1.6.1-preview.24

nanoff version: 1.15.0

Worked before? If so, with which nanoFramework image version:

• Yes, this device has worked before. Version unknown. I last updated everything about 6 months ago

Device capabilities output:

Device capabilities are not available from the VS extension because the device is in a bootloop and cannot communicate with the tool.

The device is a Sparkfun Thing Plus. Capabilities are visible in the nanoff screenshot below

Description

Device is not booting properly with the latest firmware version. The device is stuck in a bootloop and cannot do interact with the nanoframework VS extension. The device does not appear in Device Explorer with 1.6.1-preview.24.

Downgrading to the latest stable version (1.5.0.104) makes the device appear in Device Explorer, however, that fw version is not
fully compatible with the latest VS extension and ping, reboot, deploy, etc all fail

Detailed repro steps so we can see the same problem

1. Flash latest firmware preview onto Sparkfun Thing Plus with nanoff --update --target ESP32_WROOM_32 --serialport COM#

The board will enter a bootloop. This can be seen by watching the device output on a serial terminal

Expected behaviour

Device should successfully boot when powered

Screenshot

Here is the verbose output when flashing the device:

Here is the serial output from the device via putty:

The bootloader gets to this line, hangs for 10 seconds, then restarts:

Here is a preliminary suggestion from José after discussing on Discord:

[aual1780]

Tested on new 16mb device Beetle ESP32 to confirm that it is not a one-off issue. The new device has the same boot loop problem

I have also tested a different capacity device (4mb) and it worked fine, so I am reasonably sure its not an environment issue

[aual1780]

Could be related to this change

[aual1780]

The above change to the partition file was made on Nov 26, 2020. The last FW version before that works on the 16mb device, but the FW versions after that change fail

Working: 1.6.0-preview.66 (released Nov 24)

Not working: 1.6.0-preview.68 (released Nov 26)

This indicates that the changes to the partition table are likely the cause of the issue

[josesimoes]

@aual1780 reported on Discord that forcing the device to use the 4M partition table makes the device usable,

[josesimoes]

@aual1780 please give it a go with the fw published today. There were some potential issues with the partition tables calculation and definitions that could be causing this.

[aual1780]

@josesimoes I just tried fw 1.6.1-preview.43. There is no change. The device still gets stuck in a bootloop

[josesimoes]

@aual1780 a few clarifications please:

• Are you using nanoff to flash it, correct?
• If you do it manually with the ESP32 CLI, still using the 16M table, the problem remains?

I'm trying to understand if this could be caused by a bug on nanoff.

[aual1780]

1
I am using nanoff nanoff --update --target ESP32_WROOM_32 --serialport COM4 -v diag. The upload shows ok, but Putty still shows a bootloop

2
I dont know what ESP32 CLI you are referring to. Can you point me in the right direction?

[josesimoes]

I'm referring to the esptool.py. This would be something similliar to (please adjust to you setup):
esptool.py --chip esp32 --port "COM000" --baud 1500000 --before "default_reset" --after "hard_reset" write_flash -z --flash_mode "dio" --flash_freq "40m" --flash_size detect 0x1000 E:/nftools/libs-v3.3.1/bootloader.bin 0x10000 E:/Github/nf-interpreter/build/nanoCLR.bin 0x8000 E:/Github/nf-interpreter/build/partitions_16M.bin

[AdrianSoundy]

I have looked in to this and found the problem is related to the size of the deployment area in the partition table.
When over 4Mb the mapping of partition into memory hangs and the board resets due to watch dog.

bool Esp32FlashDriver_InitializeDevice(void* context) calling esp_partition_mmap()

When depolement size is 4Mb if runs but gives an out of memory error
3Mb is ok

For now we should set the Deployment size to 3MB for partition tables for 8mb & 16Mb

This may be something that is fixed in later IDF or it may be a limit we have hit.

[josesimoes]

@AdrianSoundy nice finding! 👏🏻

Could something similar be happening with 2MB partition devices?
The W102 from ublox, for example, doesn't boot because of a "guru meditation error".

[AdrianSoundy]

I can't see any problem with 2Mb partition size. Tried flashing 2mb partition layout on 8mb flash but seems to works ok.
Would have to test with actual board or get some more info.

[AdrianSoundy]

Updated 8Mb & 16Mb partitions
Tested 8Mb partition

[josesimoes]

For reference this is most likely related with espressif/esp-idf#1184.