Spent a little while updating my STM32 peripheral library for the L031 (this was my first design using it) but I now have the PLL active and a blinky running at 16 MHz from flash.

Now to get a serial console up so I can get some more debug output besides a single LED...

Ok, UART is alive. Next step is to bring up a timer, then I'll have enough stuff working on the supervisor that I can begin actual power rail testing.

Can you tell I spend a lot of time in IDA? :P

Timer and logging framework are up. Ready to actually move forward with bringup.

So far the only rails that are active are 12V0_RAW (unregulated 12V prior to the main load switch) and 3V3_SB (3.3V standby for the supervisor), which is *very* in spec - averaging 3.30027V.

Next rail is 12V0, the core 12V power feed for all of the other DC-DC converters. This is driven by a load switch which limits slew rate so that I don't pull too much inrush current.

This is the first rail that's under software control from the supervisor.

It came up just fine and measures 11.9979V. Total power draw from the input climbed to 17 mA which doesn't sound unreasonable for five big DC-DC bricks.

Next is 1V0, the core power supply for the FPGA, QSGMII PHY, and SGMII PHYs. This is a big one with a lot of load on it, so lots of room for something to go wrong.

It came up perfectly as well, sitting at about 1.00015V. Overall input power draw is around 100 mA at 12V so an extra 83 mA. Assuming 90% conversion efficiency this means the board is pulling about 896 mA on 1V0 at idle!

In the interests of limiting potential damage to the expensive prototype if there's a short, the supervisor is pretty aggressive with timing and rail monitoring. If it commands a rail to come up and it fails to give PGOOD after 5 ms, it will automatically panic and shut down all power, then print a diagnostic message to the UART.

Unfortunately, the streak has come to an end with 1V2 which failed to come up within the (admittedly aggressive) 2 ms timeout. The automatic shutdown did its job and I don't think anything fried.

Next step: toss some probes down and see what's going on with that rail.

Looks like the 2ms timeout might just be too aggressive. It seems like the rail (blue) is coming up just fine then the MCU gets antsy and shuts it down before it's come up all the way.

But hey, it was a good test of my protections!

1V8 is next. This is the core rail for the QDR-II+ SRAM and also runs (through a load switch which is currently off) most of the single ended digital I/Os on the board.

It came up fine, measures 1.792V, and the board is pulling 135 mA from the 12V input.

Still performing nominally but I need to be up early-ish tomorrow to do family weekend things so this is probably as far as I'm going to get.

Tomorrow I need to bring up the 1V8_IO, 2V5, 3V3, and Vref/Vtt rails and verify that all of the analog rails filtered off the core ones have correct voltages.

Then I can hook up to the JTAG on the main MCU and the FPGA, load some blinkies, and begin the fun part of the bringup process!

But first, time to open a support case with STMicro for the six datasheet errata I found while bringing up the supervisor firmware.

Just *once* I want to do a design with a new digital chip of nontrivial complexity and not have to do this. Plz?

Time to bring up another rail. 1V8_IO is slightly lower than 1V8 (1.7886V) due to voltage drop across the load switch, but this is well within acceptable limits.

Pulling 188.9 mA (2.3W) on the 12V input.

Tried to bring up Vref / Vtt for the QDR-II+ but I'm seeing 1.8V instead of 900 mV which isn't good.

This is <= VCCIO so I don't think I damaged any of the input buffers on the RAM. (The FPGA is definitely fine since these pins aren't even configured as Vref inputs yet and the bank is powered by 1.8V).

But I either have a PCB assembly problem or something wrong in the schematic. Time to do some digging...

Not great, seeing 1.8V on Vtt even with the Vtt regulator disabled (but with 1V8_IO on).

With 1V8_IO disabled but 1V8 on, I'm also seeing 1.8V on Vtt. But Vref isn't showing much of anything in that state.

Yep, LP2996 datasheet says that AVIN is supposed to come up first.

This is a bit of a conundrum because the FPGA has VCCAUX driven by 1V8 and VCCO driven by 3V3.

And it wants VCCAUX to come up before VCCO.

But we're allowed to do the opposite (VCCO > VCCAUX + 2.625V) for up to Tvvco2vccaux (300-800ms depending on temperature) per power cycle, with a total of 240K power cycles. This might lead to some glitching on 3.3V GPIOs on the FPGA but I think that will be OK in this use case.

Yay for fixing hardware problems in software! I'll just bring up 3.3V before 1.8 and we should be OK.

For LATENTRED I'll switch AVIN to run on 3V3_SB at which point everything should be OK.

With this sequencing fix, 3V3 comes up fine (slightly low, 3.2804V, but that's acceptable) and the board is now drawing 207 mA / 2.5W at the input.

And Vtt is now showing zero volts with the regulator disabled, which is what we expect.

With the regulator enabled (and 1V8_IO enabled) we show 900.39 mV on Vtt and 897.33 mV on Vref, while drawing 227 mA (2.7W) at the input).

This is a bit more of a Vref-Vtt delta than I'd like but it shouldn't be enough to cause problems.

Final power rail is 2V5, which runs a lot of analog stuff in the PHY.

This came up fine as well, although also a bit low: 2.4834V.

Now pulling 293 mA (3.5W) at the input.

This is all of the core power rails done. Now I just have to add a few lines of code to release the FPGA and MCU resets and I'll be ready to start bringup of them.

This was a close shave. Almost couldn't fit both JTAG cables next to each other.

I verified non-interference of the board side male connector but forgot the female IDC connectkr overhung on the sides.

Bringup is going pretty well I think.

Maybe could use a bit more kapton tape?

Gradually bringing up firmware on the main MCU. UART, uptime timer, and config variable database are running, about to work on the link to the FPGA.

But first I need to do a bit of independent testing on the FPGA.

Just loaded a test bitstream on the FPGA and verified the LEDs all work. And the supervisor is able to see when the FPGA is up.

Next step, I think, will be getting the MCU and FPGA to talk to each other.

Got a stripped down version of the base FPGA bitstream running.

It's super nice having all of the data from different instrumentation all coming to one place in ngscopeclient so I can have a single dashboard to look at everything.

After fixing a few PEBKAC issues, MCU and FPGA are talking over quad SPI.

But the data coming back is shifted by a nibble or two from what I expect. Not yet sure if timing or logic issue.

Should have put test points on the QSPI bus but silly me thought that since it worked last time, I'd be fine with PHY layer stuff and could just use an ILA on the FPGA...

And they're talking properly! That's it for tonight, I have to be awake in five hours...

I'll probably work on thermal stuff after work, since that affects the health of the rest of the board. The tachometer output of the fan goes to the FPGA (for... reasons) so I need to implement a speed monitoring block and make it output RPM values over QSPI to the MCU.

Then I need to add a PWM generator on the MCU, and bring up an I2C bus to poll the four temperature sensors around the PCB.

Also I found a new design oversight.

I have monitors for the supervisor on every regulator PGOOD pin so I can detect and shut down if a rail starts sagging due to overcurrent etc.

But I don't have an ADC pin on the 12V input so I can't detect a failure of input power and sequence rails off properly. All I can do is wait until one rail trips out of regulation then panic shutdown the rest (without proper sequencing delays since this is indistinguishable from a short).

I2C4 isn't happy. Trying to read the MAC address EEPROM and getting hung up sending an I2C start bit. The register is supposed to be self cleared in hardware and I'm not seeing it ever clear.

So either there's a peripheral setup issue (nothing jumps out at me in a quick register dump) or something is wrong in hardware (SDA or SCL stuck/open).

Unfortunately this bus is on internal and back side routing exclusively (again, should have put a top side test point on... Derp). So I'm gonna have to rip off some tape and invert the board when I get home from work and see what's really going on.

Started a google doc with a live "things to do better next time" list. So far all are minor annoyances or things I can work around without having to bodge the board. (Anyone have a self hosted, lightweight suggestion for this kind of thing? Etherpad or something?)

https://docs.google.com/document/d/10j4HWuMBLfLvX5Notvezs26lcIxuNnWbeJlv_JciUEA/edit?usp=drivesdk

The I2C4 issue smells like a soldering issue so far, but I'll know more when I get home and land probes on the bus.

My main bench scope is out for service still so I'll need to use the 16 GHz monster to troubleshoot my I2C. Miiiiiight be slight overkill...

(I could also use the PicoScope but it's on the other side of the bench, not sure if probes will reach all the way over here)