[Stabilizer v1.1] Configuring RMII interface pins causes a CPU reset

[ryan-summers]

When the RMII TXD1 pin (PG14) is configured to AF11 (RMII_TXD1), the MCU appears to undergo a reset.

When identical code is uploaded to the STM32 NUCLEO-H743ZI2, the CPU does not appear to reset and continues normally, indicating that the issue may be with Stabilizer hardware as opposed to firmware.

I additionally probed the 3V3 rail on Stabilizer while the reset occurred using an oscilloscope and did not witness any brown-out conditions.

Probing the RMII_TXD1 during this condition shows a small spike on the line pulling down to ground right as the initialization occurs.

[jordens]

@gkasprow Could you advise what the best way forward is? Do you have a v1.1 board? TS mentiones that new boards are about 1 week out.

From what @ryan-summers describes this is now permanent and the other symptoms are:

• the CPU getting very hot
• drawing 1A at 12V from the barrel connector (no PoE)
• happens even with minimal firmware or in reset (all pins high impedance) and with no debugger connected
• 3.5 V CPU voltage (instead of 3.3) indicated by the JTAG programmer

If I had the board I'd poke around and check power supplies but I don't have it and shipping it back and forth is slow these days.

[ryan-summers]

I probed all the voltages on the bottom contacts and they all seem to be appropriate (e.g. report as labeled)

[dtcallcock]

I can possibly send you one in a week or so if TS hit problems.

[gkasprow]

Does the CPU get hot after configuring RMII ? How can I recreate it? Does it happen on other boards, too?

[dnadlinger]

I've got access to a v1.1 board as well, and a scope/multimeter, but currently not much in the way of current-limited supplies, etc.

[jordens]

@dtcallcock Berlin <-> Dresden is still faster than Oregon <-> Dresden. @dnadlinger If you can get your finger onto the CPU you don't need a special supply. A non-PoE+ switch will show the problem by power cycling.

[ryan-summers]

@gkasprow

To clarify this issue:

• I initially created this issue because configuring the TXD1 pin on the CPU for the RMII interface would cause the CPU to reset.

• During debugging of the CPU resetting, my Stabilizer hardware appears to have had an event that now causes the CPU to get excessively hot when powered and my debug probe cannot remain connected to the CPU target. This is what @jordens is referring to in his post.

  This issue came up seemingly randomly during firmware development. I cannot confirm that this is related to a specific firmware image, as the problem initially appeared right as I probed the nRST signal on the Stabilizer hardware with an oscilloscope probe (while powered via PoE). Seemingly immediately after touching the board, the PoE switch cut power.

After the initial event, my PoE switch then began to fail to power the device (power LEDs would indicate, dim, and then switch off at a 1 second interval, indicating the switch was terminating power to the device). Upon replacing the PoE with a bench power supply configured for 12V, I began measuring an initial draw of 500-700mA, which then raised to approximately 1.5A (~17W) after operating for a few seconds.

I can momentarily attach to the CPU target via a SWD probe and halt the CPU, but single stepping fails shortly after as my probe loses communication with the device.

My suspicion is that this is specifically related to this board (as I was developing firmware on this hardware for 2 weeks without any issues), but I haven't been able to determine why yet.

[gkasprow]

does Ethernet work correctly? Once it happened that PHY died and shorted the supply. Is this the same board that has I2C issues?

[ryan-summers]

does Ethernet work correctly? Once it happened that PHY died and shorted the supply. Is this the same board that has I2C issues?

Correct, this is the same board. I haven't noticed the PHY heating excessively, and note that I probed all of the voltages by the voltage LEDs and they appeared to be nominal.

[jordens]

Same board as #73 . Note that 12V is right next to the I2C pins on the EEM connector.

[gkasprow]

can you check if this issue happens on other boards? Then I can try to recreate it on mine

[dnadlinger]

Which firmware version(s) would you like me to test, and what is the respective expected behaviour?

[jordens]

• TS 561/19 0009
• C136 removed manually and rotated to the side. All later boards seem to have this done in the BOM.
• EEM connector mounted the wrong way
• UART3 pin header and BOOT pin headers were missing. I added BOOT header
• The CPU gets really hot, the big 3.3V inductor a bit, the PHY doesn't get warm
• The voltages look ok (apart from P3V3 being 3.44 V but that's also the case on other boards, we may want to lower it a bit though)
• Rail ramps are OK, apart from P5V0A staying at 1.8 V for 500 ms and then RC-ing up to 5 V within 5 s. I guess that's #68. After power that rail also discharges very slowly below 0.7 V.
• CPU doesn't show up properly on SWD/JTAG anymore.
• Resistance to GND on the P3V3 rail is about 5 Ohm.

I had a look at the board and will send to to TS/Greg unless there is something worth checking before that.

[gkasprow]

@jordens what's the conclusion? Did you send this board to TS?

[gkasprow]

to make sure that it is not an issue with the stability of 3V3 rail, I did a step load response measurement. With 300mA step, the response is very good, with roughly 100mV overshoot lasting 200us. The response is symmetrical.

[jordens]

Board went back to TS and filed under "likely PCB short".

@gkasprow Did you measure 3.44 V as well? Could we lower that to 3.3?

[gkasprow]

sure, let's do that. The v1.1 stabilizer I have has permanent short between PoE + /- lines. So it's likely that the PCB vendor did not perform the electrical check.

[gkasprow]

nothing to do here, closing