S3 boot log - with fuse??

[penguin42]

Hi,
(S3 mini )
I'm trying to do a serial reflash for the first time and can't get GPIO0 to change the boot mode; could this be a fuse issue? and if so what would a boot log look like if it was a fuse issue?
I'm always getting exactly the same boot messages (below) with the boot type 0f 0x8, but I can see the pin labelled as GPIO0 on the PCB (which apparently goes to pin 4) seems to have a diode drop to ground if I measure it with a meter; so it's connected to *something*.

(I'm trying to recover after having programmed my 2nd attempt at Rust which just instantiated it's own usb-serial device but has ended up not enumerating at all any more on USB, hence why I'm trying to GPIO0 it)

Thanks,

Dave

Other suggestions?

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fce2810,len:0x15a0
load:0x403c8700,len:0x4
load:0x403c8704,len:0xd24
load:0x403cb700,len:0x2f04
entry 0x403c8928
I (30) boot: ESP-IDF v5.4.1-426-g3ad36321ea 2nd stage bootloader
I (30) boot: compile time Apr 24 2025 15:55:11
I (30) boot: Multicore bootloader
I (32) boot: chip revision: v0.1
I (34) boot: efuse block revision: v1.2
I (38) boot.esp32s3: Boot SPI Speed : 40MHz
I (42) boot.esp32s3: SPI Mode : DIO
I (46) boot.esp32s3: SPI Flash Size : 4MB
I (49) boot: Enabling RNG early entropy source...
I (54) boot: Partition Table:
I (56) boot: ## Label Usage Type ST Offset Length
I (63) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (69) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (76) boot: 2 factory factory app 00 00 00010000 003f0000
I (82) boot: End of partition table
I (86) esp_image: segment 0: paddr=00010020 vaddr=3c000020 size=0bfd4h ( 49108) map
I (105) esp_image: segment 1: paddr=0001bffc vaddr=3fc96148 size=027c4h ( 10180) load
I (108) esp_image: segment 2: paddr=0001e7c8 vaddr=40378000 size=01850h ( 6224) load
I (111) esp_image: segment 3: paddr=00020020 vaddr=42010020 size=4f8f4h (325876) map
I (196) esp_image: segment 4: paddr=0006f91c vaddr=40379850 size=0c8f4h ( 51444) load
I (222) boot: Loaded app from partition at offset 0x10000
I (222) boot: Disabling RNG early entropy source...

[MicroController]

can't get GPIO0 to change the boot mode;

The chip just boots normally when you keep GPIO0 pulled to GND during power up/reset?

[penguin42]

can't get GPIO0 to change the boot mode;

The chip just boots normally when you keep GPIO0 pulled to GND during power up/reset?

Yep, no change in the boot log output at all. Still says boot mode 0x8.
Which made me wonder if it's a fuse that's been blown, since I'm out of other ideas.

[Sprite]

You say 's3 mini', but that's a module, not a board. What board are you using, and are you sure the line you picked indeed goes to GPIO0?

[penguin42]

You say 's3 mini', but that's a module, not a board. What board are you using, and are you sure the line you picked indeed goes to GPIO0?

It's an obscure board someone made as an epaper sign (EPD75); just the S3 module, a bunch of LEDs, USB connector and a DC converter to get the 3.3v.
Am I sure it's connected to GPIO0....well, I've got a PCB design for it and it sure looks like the connector pin I'm looking at (which is labelled '0') goes to pin 4 of the module, and I can measure a diode between the connector pin and the ground, so it's connected to _something_.
And as you see I'm getting the serial log, so the other pins look OK (and the USB was working to start with).

So, that brings me back to my question - if it was connected properly, and my problem was a fuse, would I get a different serial message to indicate it was ignoring me because of the fuse?

[Sprite]

I'm not 100% on this, but the only eFuse that I recall that would affect download mode is the one that disables download mode. That, however, would simply give you a message that says that download mode is disabled, not ignore GPIO0 all together.

[penguin42]

I'm not 100% on this, but the only eFuse that I recall that would affect download mode is the one that disables download mode. That, however, would simply give you a message that says that download mode is disabled, not ignore GPIO0 all together.

OK, thanks, so something else must be going on somewhere.
Hmmm.

[summat]

What about GPIO46?, that is also indicated within the S3 Datasheet as being involved with Boot Mode determination.

[penguin42]

What about GPIO46?, that is also indicated within the S3 Datasheet as being involved with Boot Mode determination.

It's marked as disconnected and having a pull down.

[penguin42]

FYI, I managed to sort this out by taking GPIO0 to ground on the S3 chip itself having taken the can off
So something on the PCB it's mounted on must have screwed up the GPIO0 connection to the PCB pin apparently marked as GPIO0.
Shrug; a Scalpel wired to ground works nicely