Much progress has happened, here's a recap:

CircuitPython troubles

I previously reported that I had successfully tested compatibility with CircuitPython.  Seems I wasn't thorough enough: this had proven compatibility from a software standpoint, that the W5500 CircuitPython driver worked correctly with the PoE-FeatherWing.  Problem was: to see what was going on by console prints, I also had the USB connected.

A problem became obvious when I was building the test fixture, which I'm basing on a Feather M4 running CircuitPython.  It would not run my test code with powered from the PoE-FeatherWing.  I adjusted my demo code to light up some LEDs and confirmed that my demo code also didn't run when powered from the PoE-FeatherWing, without USB connected.

The system kept ending up in "safe mode", which meant it would not run my Python code.  After some diffing through the CircuitPython source code, I found out that safe mode was in this case being triggered by a brown out detector (BOD) reset.  Did my power supply really brown out?

Turns out, the problem was because of the pretty slow ramp up of the PoE power.  CircuitPython sets the BOD level to a pretty high 2.77V in its initialization code, to make sure the system voltage stays within the safe range for SPI flash chips.  Power on reset would release at 1.7V, the micro would start initializing and get to the point where the BOD level was set to 2.77V before the power supply had time to reach this level!  This would cause a BOD reset, the chip would start initializing again, and by the time the BOD level change was reached, it would the power supply was high enough and the system would run.  But, because of the BOD reset, it would run in safe mode, not loading any Python code.

It was obvious this could be fixed with a software change, but because I really did not want to start maintaining a separate CircuitPython branch for PoE-FeatherWing compatibility, I filed an issue with CircuitPython and simultaneously started to see if I could do anything in hardware.

I found that I could make the code run if I added a 4.7 uF capacitor from the EN pin to GND.  In combination with the pull-up on the Feather, this would delay the turn-on of the 3.3V regulator on the Feather, enough to give the input voltage time to ramp up before the BOD level was changed to 2.77V.

While it would be possible to add this to my PoE-FeatherWing, it still felt like a hack.  It depended too much on the exact implementation of the EN pin on the Feather, something out of my control.  And a quick check showed that various Feathers used different values of pull-up resistors, and different 3.3V regulators that may have different enable thresholds.  There was always the risk that even if I tested that it would work with every Feather currently on the market, it could still fail on a Feather released in the future that used some different arrangement on EN.

Luckily it turned out to not be necessary.  In a prompt response to the issue I had submitted, I was told that this had been solved in the UF2 bootloader.  They had already added code to wait for the voltage to reach 2.77V before loading CircuitPython in bootloader version 3.9.0.  Although I had updated the CircuitPython on both my test boards, I had failed to also update the bootloader.  Moral of the story: update both the CircuitPython image and the bootloader on every Feather you buy before use!  Oh, the joys of modern software development.

So, this turned out to be a tempest in a teapot.  I'm glad there is a software solution already in place, as it is the best way to solve this.  With this unblocked I could also continue on my test fixture.

Flyback change

On the #wESP32 I had used a Hanrun HR861153C PoE Ethernet jack, but I had tested and confirmed that equivalents from other manufacturers such as Link-PP worked just as well.  Link-PP made me an offer I couldn't refuse to use their LPJ0284GDNL on the PoE-FeatherWing, so that's what I went with.  But on my first prototypes I was still using a Hanrun HR051067 flyback transformer.

Link-PP offered to supply a lower cost, equivalent substitute for this part as well, so I agreed to have them supply this part for the first 100 units built by KingTop.

Turns out it's working well, but isn't exactly equivalent to the Hanrun part.  The main difference I see is in the ringing on the secondary side winding.  While the Hanrun part had very little ringing, making a snubber unnecessary, the Link-PP part shows more ringing, indicating it must have more parasitic self-inductance.

Link-PP offered to analyze what's going on and adjust their design to match Hanrun's performance closer, but since it's so late in the game and I'd like to start production, I decided to reduce risk and source the remaining flyback transformers from Hanrun instead, since that's what I did all testing with my initial prototypes on.  It's not that there's anything wrong with the Link-PP parts per se, but the Hanrun ones seem to behave a little better.  These are details and it is unlikely that users will see any difference between them, it's more a risk reduction strategy than anything else.

The flybacks have now been ordered from Hanrun and should be on the way to KingTop shortly.  The early bird rewards in my Crowd Supply campaign will be filled from the 100 units with Link-PP flyback, since they can be shipped immediately when the campaign ends.  The remaining units will be built with Hanrun flybacks.