That does look like an impressive board.
We do not need to know what the board is intended to do, but please tell us more about the timing or other requirements for debugging.
For example, if the board controls a high-power motor, where momentarily freezing execution could lead to burned-out windings, then conventional JTAG / ST-Link debugging is difficult. This is because the way JTAG works is that it momentarily freezes the stm32 and instead reads/writes debug information from the internal processor buses. That freezing is extremely quick on a "human" timescale, but could be thousands of processor-clock-cycles.
And your desire for wireless debugging e.g. Bluetooth suggests there might be high voltages present and that you want electrical isolation to protect your PC. If this is the only worry, I seem to remember that ST had an opto-isolated ST-Link.
Years back, people would do "burn-and-crash" debugging - burning fresh code into an eprom, then letting it run - observing the execution and outputs on an oscilloscope or logic-analyser. Then trying to guess where the outputs did not match what was intended and from that deducing what might be wrong with the code. Not easy, but it was all we had.
Things are much easier if you can send debugging information out, but all interfaces (other than direct-writes to LEDs) are also very slow compared with the stm32. Even with a handy JTAG for getting the exact processor state, memory-contents etc at a breakpoint, I like to have a UART for logging near-real-time diagnostics at various points in my code without having to freeze execution. But UARTs are slow, so I have to code a FIFO for my UART.
Hope this helps,
Danish
