ESP32 Forum

Posted: **Thu May 30, 2024 6:36 pm**

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 the test configuration. Both configurations I occasionally get false detections and the system boots into factory.

I've had the same symptoms on my custom board based on ESP32E, and the NodeMCU devkits with ESP32E. I am using IDF4.4.7.

I seemed to get it regularly when there's an exception / panic reset in the application, it always falsely detects. I've even watched the boot info logs, and it really is pausing as if its seeing the button pressed when it isn't, and then get the false detection:

Code: Select all

I (52) boot: ESP-IDF v4.4.7-dirty 2nd stage bootloader
I (52) boot: compile time 14:34:23
I (52) boot: Multicore bootloader
I (56) boot: chip revision: v3.1
I (60) qio_mode: Enabling default flash chip QIO
I (66) boot.esp32: SPI Speed      : 80MHz
I (70) boot.esp32: SPI Mode       : QIO
I (75) boot.esp32: SPI Flash Size : 4MB
I (79) boot: Enabling RNG early entropy source...
I (85) boot: Partition Table:
I (88) boot: ## Label            Usage          Type ST Offset   Length
I (96) boot:  0 nvs              WiFi data        01 02 0000f000 00004000
I (103) boot:  1 otadata          OTA data         01 00 00013000 00002000
I (111) boot:  2 coredump         Unknown data     01 03 00015000 00010000
I (118) boot:  3 factory          test app         00 20 00030000 00100000
I (126) boot:  4 app0             OTA app          00 10 00130000 002b0000
I (133) boot:  5 spiffs           Unknown data     01 82 003e0000 00020000
I (141) boot: End of partition table
I (3145) boot: Detect a boot condition of the test firmware

Since I got it consistently on the exceptions, thought I better check if that's an undocumented "feature", but peeking at the code, looks like it's strictly the button.

Is there some reason IO0 can't be used for this, or any thoughts what could cause this?

Posted: **Fri May 31, 2024 1:38 am**

Any chance you pull down IO0 during your program?

Posted: **Fri May 31, 2024 6:35 am**

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 can be used to drive WS2812B LED string if configured to do so by config file. I don't have it configured to do so.

The regular application, which runs on both boards, also probes IO0 at start up for an application-level safe mode, which will start a WiFi task only. This check happens at the application start, as outlined below.

Code: Select all

pinmode(0,INPUT)

; safe mode check
digitalRead(0)

pinmode(0,OUTPUT)

Currently running the second board, at start up, I see the below...

Code: Select all

I (1084) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (1100) gpio: GPIO[2]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
I (1109) gpio: GPIO[0]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
I (1118) uart: ESP_INTR_FLAG_IRAmain on core 0
Start, Heap: 162404 min / 162404 current
Reset reason: Power up, counts: 0
I (1657) gpio: GPIO[0]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0

Posted: **Fri May 31, 2024 11:04 am**

Do you have a pullup enabled on IO0? If not, suggest you do that.

Posted: **Tue Jun 04, 2024 6:06 pm**

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

Posted: **Tue Jun 04, 2024 10:52 pm**

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 read back with esp_ota_get_boot_partition(), and it hasn't changed at all. Can subtype "test" not be set as a boot partition?

Posted: **Wed Jun 05, 2024 1:35 am**

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()".

If I press the hardware reset button, it consistently boots properly. If the app calls "ESP.restart()" it consistently falsely switches to factory boot.

This is with pull-up enabled on a NodeMCU devkit board.

Posted: **Wed Jun 05, 2024 1:49 am**

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.

ESP32 Forum

Spurious ( False Positive ) factory / test boot condition detection

Spurious ( False Positive ) factory / test boot condition detection

Re: Spurious ( False Positive ) factory / test boot condition detection

Re: Spurious ( False Positive ) factory / test boot condition detection

Re: Spurious ( False Positive ) factory / test boot condition detection

Re: Spurious ( False Positive ) factory / test boot condition detection

Re: Spurious ( False Positive ) factory / test boot condition detection

Re: Spurious ( False Positive ) factory / test boot condition detection

Re: Spurious ( False Positive ) factory / test boot condition detection