In September 2019 one might hope the tools have evolved to understand the requirements of the H7 plumbing.
The criticality here is two fold, a) the plumbing of the swv funnel must be correct, the b) clock and dividers need to be coherent and match reality.
This can be achieved in a number of ways, a) the tools can do it all transparently, b) you can configure it with a Debugger Script, or c) you can do it in-line with C code in your application.
The 0xC7 setting (199, or 200-1) comes from a 400 MHz clock being divided by 2 MHz, if you are running at 480 MHz the divider will need to be different, if your debugger clock is not actually 2 MHz it will also need to be different. But whatever, it needs to match reality, otherwise the gears are going to grind.
Keil reports different frequencies for the ST-LINK V2 vs V3, what CubeIDE does, and how OpenOCD works, I don't know, these are not tools I have chosen to use. Perhaps review the output/connection logs, review the debugger scripts. Perhaps output telemetry via a USART to understand how the board sees the settings internally. In the top post cited, you'll see a screen shot where I was outputting to SWV and USART. Here I made sure my "putchar" function used the USART and ITM_SendChar() function.
Amel or Nawres posted a document and example for the GNU stuff, but the functionality is notionally the same, the syntax might differ. Most of this stuff assumes some level of familiarity with the tools you've chosen to use.
There are two LAR writes because multiple different units of the debug hardware are getting involved, and each has its own locking mechanism.
