STM32F7 device freeze: cannot access registers
If the debugger is locked out, assuming power/clocking is OK, then the most likely outcome is a internal bus deadlock. As an example, if you have external XIP EEPROM and you have mis-configured the device, the peripheral could hang when you hit specific address/data patterns.

You may still be able to read RAM information after reset (or add some tracing to dump something to RAM). The core architectural registers are not reset (unless you have a high-reliability safety specific part), so if you put a B self in the reset handler (assuming the debugger 'halt after reset' doesn't work) then your old state should be preserved.

You can use ETM trace to capture realtime trace, and if you capture trace into the ETB you can just read this out after reset (again, it should be persistent) without needing a probe (but maybe the buffer pointer will be lost, so you might need to manually process the trace). ETM trace will show branches (addresses for any indirect branch) and exceptions (including lockup) - so you should get a reasonably accurate indication of what the last thing was. Speficically, the trace is just 'watching' the core, so it sees instruction retire without being affected by the bus activity. The DWT might give something useful too - depending on what actually fails.

As referenced in one of the comments, at least using MDK, you are able to attach to a 'hot' running target (without reset/halt, without code download), since the debug port is a completely asynchronous bus master embedded in the core. This gives you the ability to probe memory state on a long uptime device (but not core registers) with minimal intrusion, and this might be valuable to confirm a diagnosis. You could even script up a regular polling of memory locations if this is relevant.

Finally, since the debug port 'acts like the core', you are able to mimic quite a lot of bus deadlock failures by just using the debugger memory window.