Issue with VCAP voltage

[genesis78]

I am currently working on a board designed around the STM32H725RGV6 and have encountered issues with it being recognised by STM32CubeProgrammer as I get the message "target not found" when connecting it to a STLINK-v3-minie. With my previous experience using H7 or F7 MCUs, they get pretty warm even while idling which mine does not.

VDD is 3.3V and supplied from a LDO regulator, TPS73633. With the board fully populated except the bluetooth module, RN4871, I have verified that the MCU is receiving 3.3V through the VDD pins.

I have also checked that BOOT0 is pulled low and NRST is pulled high.
2 of the 3 VCAP pins have 2.2uF caps placed nearby and the third is connected to the other 2.
I have used a multimeter and continuity tested the majority of the pins to their adjacent pins and GND to check for shorts. None were found.
The board was assembled by JLC except for the MCU which I had to reflow myself. I had to reflow it 3 times until I was satisfied with how the joints looked. The board was also cleaned thoroughly with IPA.

I have read that I have to choose the correct power configuration in CubeIDE but I don't get how I would be able to do this without connecting the STLINK first.No code has been uploaded to the MCU yet anyways.
I realised that I have added an extra capacitor to the VDDA pins but I don't believe this would prevent the H7 from working.
Hence I have narrowed it down to the VCAP pin which had a steady output of 0.08V. I immediately believed that I had fried the MCU by reflowing it too many times so I replaced it with another one which only took 2 tries to reflow. After checking for shorts, the voltage at the VCAP pins now seems to oscillating from 0V to 0.12V slowly. I don't have access to a oscilloscope currently but my multimeter still picks up on this oscillation. I only have one more MCU on hand so I don't want to try with my last one.

Any advice is very welcome. I have attached my schematic, PCB layout and photos of the MCU's solder joints. The board is very space constrained.

[genesis78]

I am replying to my message to include morea attachments since I reached the limit in my previous message.

[Tesla DeLorean]

Presumably you don't have access to an X-Ray inspection machine to confirm there's not an issue with the soldering.

Orientation looks Ok.

You'll likely need be triple checking the footprint, and the netlist, and the SMPS / LDO connectivity expectations.

Just ONE board?

The internal boot-loader (blank FLASH or BOOT0=HIGH) should be able to bring up in LDO / SMPS sufficiently, allowing for ST-LINK to work. ST-LINK will expect VTarget to be supplied, and able to report the voltage it sees.

On your initialization code needs to get the VOS and LDO settings right.

There's not a PDR_ON pin involved here.

[genesis78]

Thanks for the response. 
I unfortunately don't have access to an X-Ray inspection machine though the rest of the board has passed an X-Ray inspection. 

I have made another board in the meantime but it also doesn't work.
Could you elaborate on what you mean about bringing up the LDO sufficiently?

[Tesla DeLorean]

>>..bringing up the LDO sufficiently

The ROM based loader is capable of bring up devices in a suitable mode wrt to LDO / SMPS regardless of what code you have in FLASH. There are a lot of topics on the forum regarding bricking H7 boards by getting the settings wrong, and the BOOT=1 Power Cycling methods of recovery.

Those presumably are a different issue from not getting 1.2V on VCAP. Even with the wrong capacitors, which could cause issues in stability, it would still limp along.

I suspect this is a power supply related issue, perhaps where the GND plane lacks continuity.

Or perhaps the pin designations have shifted. Might be easier to test/probe on a partial PCB where you can touch the pads, and don't have conductance through the IC

[genesis78]

By partial PCB do you mean a PCB that doesn't have the STM32 IC soldered?

 

[Tesla DeLorean]

Yes, that's how you indicated you received them from JLC. Or the bare / solder-test article.

That you can check the netlist and voltages presented at the pads. Rationalize those directly with the datasheet tables.

That the exposed pad is ground. That you've got no shorts to that

[Tesla DeLorean]

Per data sheet

Embedded DCDC and LDO regulator
(*)VFQFPN68 variant is DCDC only

[genesis78]

I'm really leaning towards the fact that I caused some sort of heating damage while soldering the MCU. 

[Tesla DeLorean]

No, more probably that VDDSMPS is grounded on your layout

https://community.st.com/t5/stm32-mcus-boards-and-hardware/what-s-the-correct-power-supply-scheme-for-h725-735-vfqfpn68/td-p/644714

https://www.st.com/content/ccc/resource/technical/document/application_note/group1/2d/c2/ab/ef/79/04/47/0f/DM00663674/files/DM00663674.pdf/jcr:content/translations/en.DM00663674.pdf

You might be able to recover in BYPASS mode by injecting voltage into VCAP, 1.35 V for max speed, as I recall

[genesis78]

Thank you for spotting that. I initially discounted the LDO not being present because of this line in AN5419,
"When LDO is available but VDDLDO pin is not present on the package, VDDLDO is internally connected to VDD," but I must've ignored "available" being a keyword. 
I'm guessing that the PCB isn't recoverable since I would need another voltage regulator to continuously supply 1.35V to the VCAP pins. I'm also going to assume that the 2 MCUs I have used until now are fried since the core was probably being supplied with 3.3V.
The documentation for this specific variant is so lacklustre and confusing that its frustrating especially for a first time user. I guess I'll have to order another PCB and more components now which could've been so preventable.

Anyways, for future reference apparently the first picture is the correct direct SMPS supply, for STM32H725RGV6 in the VFQFPN68 package which aligns with AN5419's diagram (2nd) as VDDLDO is internally connected to VDD.