ESP32 Micromod + PoE-Ethernet = no boot. invalid header 0xffffffff

(Important information, more detail at the end of this post - if I do the same thing on the mainboard with 2 function slots, it works in function slot zero).

I run into the exact same issue the user @avsteele descibed in this unsolved thread from 2023:

I have bought both components new in April 2025 and set them up just how it is described in the hookup guide MicroMod Ethernet Function Board - W5500 Hookup Guide

As Board definition I tried:

Initially I used the second board definitions from Espressify Github and flashed the test script from the hookup guide. It did lead to the issue right away.

I’ve tried using the other 2 board definitions, same result.

When I remove the PoE-Ethernet and/or use the Wifi+Bluetooth Micromod Module, everything works fine.

I have attached screenshots of the flash and boot process. Notice that when the flashing fails, the flash memory is not detected properly and set to 4MB (instead of the correct 16MB), maybe that is important. Manually setting 16MB does not help though.

I’ve also tried several variants, like flashing with or without PoE supply, did not help either.

I’ve noticed that in the Ethernet hookup guide, in the hardware overview it says:
" WP OPEN Pulls EEPROM Write Protect pin to 3.3V/HIGH Close to pull this pin to 0V/LOW to disable write protect."
Is that related to the issue?

ALSO I have another mainboard with 2 Micromod ports.
When I insert the ESP32 and the PoE-Ethernet here into Function Zero, IT WORKS.
If I insert the PoE-Ethernet into Function One, I get the same error as described above.




1 Like

Looking at the schematics, the issue is related to using GPIO12- PWM1 on the ESP32. A side note on the MM ESP32 states: Pulling GPIO12 high may prevent flashing and/or booting.
The ESP32 GPIO12 is connected to pin 47 for MM-2222 processor connector.

On a single MM motherboard, the processor pin 47 is used for for PWR-EN0 and connected to the function board MM connector pin 71. On the Ethernet function board this is can be used to DISABLE power (pulling low). It has a pull-up of 10K to 3v3. Hence is does prevent flashing and booting

On a double MM motherboard, the processor PIN 47 is used PWM1 on function board connector FC1. And this is not connected and thus it works.

Just in case you wonder, how is FC0 / pin 71 /PWR-EN0 connected… it is connected to pin 66 on processor MM and on an MM ESP32 this pin is not connected.

“Not much you can do except for cutting a trace on the ESP32MM, the MM motherboard OR Ethernet MM. Easier, best workaround is using double MM mother board.”

  1. double is not an option (very limited space) - what and where exactly do I have to “cut” on the board?

  2. I find it strange that this issue exists at all, doesn’t that mean that every customer with that config would run into that? It sounds like something Sparkfun should take a closer look or provide info in the hookup guide if its just a matter of cutting a trace?

I have taken the BRD-file from the single motherboard and looked up the line that runs from Pin71 on the function board connector to the pin 47 of the processor connector.

it is the line highlighted in RED and Blue (Red runs on one side, Blue on the other side of the motherboard). Looks to me there are places it can be cut in the blue area.. at your own risk.. never tried it.. no warranty..

Point 2 is for Sparkfun to handle / answer.

Essentially, yes…there are several processor + function combos that don’t jive well :-/

If you attempt to cut the trace mentioned above we won’t void the warranty on it

Hi @paulvha and @TS-Russell

Thank you, I confirm, cutting at the blue position solves the problem.

Maybe add this info to the PoE hookup guide?

How likely is it that the board is updated to a newer revision? Because we want to build several devices (at least 40) based on this combo and can either apply this workaround or wait for a revision.

1 Like

thanks for sharing the positive result Michael.

The questions are of course for Sparkfun to answer.

1 Like

Excellent! Very unlikely for a revision, I’d just go with the workaround (and similarly, we’ll honor the warranties)

I’ll suggest adding it to the guide! In the meantime hopefully they can find the info here on the forums