I guess the iSYSTEM iONE.BT could be something you could use. It supports debugging in Eclipse.
I would put some of these in comments but my reputation is not high enough.
I never (very rarely) use printf debugging. By my experience it has quite an impact on performance and design. E.g. values formatting and serialization over communication interface take their toll. Also you need standard libs and minimal system calls implementation (-lnosys won't do in GCC) which you might not need in your firmware. Additionally the context with debugger is so much richer than with printf.
There is of course the fear of unpredictable peripherals behavior on stop. However, STM has configurable peripherals behavior when CPU is stopped. Each peripheral can be stopped with CPU or left running. iSYSTEM tools support the common configuration of these. I used iSYSTEM's free iTAG debugger with my STM USB reference project and had no problems with USB while stopping the CPU.
Additionally professional tools support scripting which can be used to configure your peripherals when CPU is stopped. E.g. Python script poling run status and apply changes (with memory writes, short monitor executions etc.) on stop and run.
One more thing - you might need to test and/or verify your code. This can't be done with instrumentation. Instrumentation basically means changing your code for debug purposes. But release FW without printfs is not the same as tested debug version with them. Or you could leave printfs in release FW :).
I recommend C over C++ for embedded projects. C++ needs more resources than C.
Compilers need not to know anything about the debugger. It’s the other way around.
You won’t be able to trace over wireless because there is not enough bandwidth. Although, I’d leave trace pins (if available on your package) free in case you'd want to connect trace port analyzer tool sometime in the future.
