VCORE supply configuration on STM32H755XIH6 and MEM corruption correlation

[Engineer29]

Hi, 
I am using an STM32H755XIH6 MCU in a custom design. I want to use only LDO supply configuration for the internal power regulator that provides the VCORE and I don't really intend to use the SMPS configuration. My schematic has some hardware mistakes, just want to understand their impact before doing a rev. 

1. According to RM0399, Section 7.4 - Figure 22, when using LDO supply, do we still need the cap (mentioned) on the VCAP pin? Is it recommended or mandatory? Would it cause major issues if its left floating for example? 

1.1. Follow up question on this, is if we plan to use LDO only, does the VDDSMPS and VFBSMPS pin state matter? I have mistakenly left VFBSMPS floating and it's impossible to access it without revving the board. 

2. If we don't plan to use VBAT (backup battery), it is given in RM0399, Section 7.4 that VBAT must be connected to VDD if battery is not used and needs a 100nF ceramic decoupling cap on VBAT pin (mentioned in RM0399 Section 7.4.4). But I have it floating, just wanted to understand the issues this may cause for example when we remove power abruptly. 

To be honest, the MCU is running fine, but I am seeing long term mem corruption (meaning either the stack or heap is getting corrupted heavily after a couple of days of continuous running), I am just trying to corelate if any of these hardware mistakes might be causing this. of course, there might be issues on the firmware end as well for the mem corruption, but I want to leave no stones unturned.  

Any insights would be greatly appreciated. 

[TDK]

Caps on VCAP are required. It may show activity but will not function correctly without them, especially at high frequencies or extreme temperatures. This one is firmly in the mandatory camp.

VBAT needs to be powered as some of the onboard peripherals are powered from this. Also mandatory.

On the other points: recommendations are given in the datasheet for a reason however the specifics are not always spelled out. ST isn't going to guarantee the chip will function correctly, although it might.

If the application matters, it's best to follow the recommendations. Otherwise do your own testing and accept the risk.

At a guess, if the chip runs, I expect the memory issues are due to code bugs rather than hardware issues.