I haven't had trouble with deadlocks with RTT on nRF52, compared to the Arduino core's Serial1.

On the other hand, anything with Bluetooth (Bluefruit lib; haven't tried anything lower level yet) seems to cause trouble with segfaults during debugging, including RTT.

I haven't had trouble with deadlocks with RTT on nRF52

I think it depends on timing (luck), implementation side they don't have interrupt lock.
https://github.com/NordicSemiconductor/nrfx/blob/4620e7ccfebc08dbd4c039bc7d530b62c4c68ca8/drivers/src/nrfx_uarte.c#L871

Options:

• Remove all logging from ISR.
• Defer ISR logging, should be difficult with va_args.

I think these two options are best.

In my own embedded code, if I really need to log in an IRQ, I use two custom functions that log either a single string or a string with a number, and these fonctions (1) don't use libc and (2) work "optimistically", (i.e. only if there is room in the output buffer). I think a general solution is difficult.

Also I don't think this is a real problem here for embedded systems, but in theory vfprintf() and friends can call malloc() and free() which is very bad practice in an IRQ....

If a tu_printf()-like function really wants to be called in an interrupt, then it would help if a different macro is defined (like tu_printf_irq()) and be overridable differently (CFG_TUSB_DEBUG_PRINTF vs CFG_TUSB_DEBUG_PRINTF_IRQ) so users can implement them in a different way. The context (irq or not) could be determined at runtime of course, but users could save code + IRQ latency by just defining CFG_TUSB_DEBUG_PRINTF_IRQ() a dummy statement.